About vLuwte's Homelab Journey
From answering support calls in 1998 to architecting global telecom infrastructure, I’ve spent 25 years obsessed with how the internet works. Now, I’m building a production-ready homelab from scratch using TuringPi, Talos Linux, and Kubernetes. Follow my journey of learning in public.
Who I Am
Hi, I'm Igor. I've spent over 25 years working in infrastructure and operations for an international telecom operator, and now I'm bringing that experience home to build a production-ready homelab from scratch.
My professional journey started in January 1998 as a support engineer answering calls for business internet customers. That first year was intense - I learned TCP/IP, DNS, SMTP, and everything about how the internet actually works through formal training courses provided by our partners and daily hands-on troubleshooting. I even took a C programming course since we occasionally needed to modify source code. By December 1998, I moved to server operations, eventually becoming the news master, setting up NNTP peering with other providers across Europe.
As our company merged from a local ISP to an international operation with teams in the Netherlands (where I'm based), Germany, United Kingdom and individuals in other countries - serving customers across Europe and even Asia-Pacific - I moved into more senior roles focused on design and service architecture. When the explosion of binary content made NNTP service unsustainable for a business ISP, I pivoted to building a comprehensive statistics platform. I created a system that collected performance metrics from all our servers, stored them in RRD files, and used a YAML-like syntax before YAML existed to generate configurations that integrated with our inventory database and SNMP polling to create MRTG configurations. Later, I expanded this to collect application-level statistics from DNS, mail systems, and other services - capturing queue sizes, performance metrics, and operational data.
After several years on that team, I took on hardware lifecycle management - planning refreshes, managing end-of-life transitions, and tracking market changes. This was during our transition from primarily Solaris systems to a more diverse environment. When our Unix and Windows groups merged, my responsibilities expanded to include ESXi platform planning.
About ten years ago, my team took on an additional role creating bespoke customer solutions, operating like an internal professional services group. We could build custom infrastructure and services without the overhead of formal product development. This allowed us to move fast and serve the organization's needs without the time and budget constraints of creating standard products. I worked in this capacity until three years ago when that function was outsourced.
Now I'm responsible for hardware strategy, planning, and financials - including managing OEM vendor relationships and third-party support contracts. After decades of building infrastructure at enterprise scale, I want to apply that knowledge to something personal: a homelab where I control every detail.
This blog is my public learning journal - a place where I share the successes, the failures, the "aha!" moments, and the frustrating debugging sessions that come with building complex infrastructure. But this time, it's all mine.
Why This Blog Exists
I started this blog for two reasons:
First, to document my own learning. There's something powerful about writing down what you're learning. It forces you to truly understand concepts, and it creates a reference I can return to when I inevitably forget how I solved a particular problem six months from now.
Second, to help others on similar journeys. When I search for solutions online, I often find tutorials that skip the messy parts - the troubleshooting, the version conflicts, the "why did that work?" moments. This blog includes all of that. If you're building your own homelab, I want you to see the real process, not just the polished result.
The Homelab Project
I'm building a Kubernetes cluster on a TuringPi board with 4 RK1 nodes running Talos Linux. The goal is to create a self-hosted infrastructure for:
- Git repositories - Own my code and configurations
- Monitoring and observability - Prometheus, Grafana, and log aggregation
- Note-taking and knowledge management - A second brain for technical learning
- Eventually, much more - As I learn and experiment
What I'm Learning
This project is my hands-on education in:
- Kubernetes - Container orchestration at scale
- Talos Linux - Immutable infrastructure and API-driven management
- Ansible - Infrastructure automation and configuration management
- Self-hosting - Running services without cloud providers
- ARM64 architecture - Working with RK1 nodes instead of traditional x86
- GitOps workflows - Infrastructure as code best practices
I'm not an expert in any of these technologies (yet). This blog documents me learning them in real-time.
My Philosophy
Document everything. Good and bad. If something breaks, I write about how I fixed it. If I make a mistake, I share what I learned from it.
Show the real commands. Every command I run, every configuration file I create, every error message I encounter - it's all here. No sanitized, perfect tutorials. Just the actual process.
Learn in public. Sharing my learning journey helps me understand things more deeply, and hopefully helps others avoid the pitfalls I fall into.
Build for the long term. This isn't about quick hacks or temporary solutions. I'm building infrastructure that will grow and evolve over time.
The Technical Setup
Current Infrastructure:
- Red Hat Enterprise Linux 9.7 web server (sulu.luwte.net)
- Remote MariaDB database server (data.luwte.net)
- Ghost blog platform (what you're reading now)
- Apache with SSL for hosting multiple sites
Planned Homelab:
- TuringPi 2.5 board
- 4x RK1 compute modules (ARM64)
- Talos Linux (immutable Kubernetes OS)
- Self-hosted services managed via Kubernetes
- Ansible for automation
- Web-based GUI for cluster management
What You'll Find Here
Installation guides - Step-by-step instructions with real commands and output
Troubleshooting chronicles - Problems I encounter and how I solve them
Architecture decisions - Why I chose specific technologies and approaches
Lessons learned - What worked, what didn't, and what I'd do differently
Planning and research - My thought process as I design the homelab
Progress updates - Regular posts as the project evolves
What's Already Built
The foundation is in place:
- Blog platform - Ghost CMS with syntax highlighting for code
- Comments system - GitHub-based discussions via Giscus
- Analytics - Self-hosted Umami for privacy-friendly tracking
- SEO configured - Google Search Console and sitemap submitted
The Road Ahead
Here's what's coming:
- Planning the cluster - Researching hardware, architecture, and costs
- Learning Talos - Understanding the OS before installation
- Building the cluster - Unboxing, assembly, and initial setup
- Deploying services - Getting self-hosted apps running
- Automation - Making everything manageable with Ansible
- GUI management - Accessible cluster control without constant CLI work
Future Plans
Down the road, I may offer premium content for readers who want to go deeper - exclusive tutorials, ready-to-use configuration files, Ansible playbooks, and walkthroughs. But that's a future consideration. Right now, it's all about building, learning, and sharing.
Connect With Me
I'd love to hear from you, especially if you're building something similar or have advice to share.
Email: igor@vluwte.nl
Comments: You can comment on any post using GitHub (via Giscus). Just sign in with your GitHub account to join the discussion.
Following Along
New posts are published as I make progress. No fixed schedule - I write when there's something meaningful to share. You can subscribe via RSS or check back regularly.
If you're building your own homelab, I hope this blog becomes a useful resource. If you're just curious about the process, I hope it's an interesting read.
Let's build something great.
— Igor
This blog is self-hosted on infrastructure I manage. If something breaks, I'll write about fixing it.