Today my homelab does real work. A sandbox server is where I build an application. A k3s cluster is where I plan to deploy it. Prometheus and Grafana Alloy feed a live telemetry display on my portfolio site. Not long ago, none of that was true. For a couple of years, I had a homelab that mostly sat there.
This is the story of how it went from a place I could practice to infrastructure I actually use, and what that taught me about learning by building.
A place to practice, without a reason to
A couple of years ago, I built my homelab because I wanted to practice. I was studying cloud computing at WGU, and I wanted somewhere to work with the technologies I was learning about. Somewhere I could install services, experiment, and develop experience beyond the curriculum.
I tinkered from time to time, but for a long stretch, WGU got the bulk of my attention. The lab was there. The intention was there. There was always something I could practice.
But if I’m being honest with myself, nothing in particular was waiting for me to finish it. I could get back to it when I had time, and school usually had a more immediate claim on that time. I had built a place to practice, but having it hadn’t created a reason to practice consistently.
Choosing tools for exposure
When I started choosing services, some had an appeal I could connect to my everyday life. Pi-hole and Unbound sounded attractive because I wanted ad blocking and more control over DNS. Running my own recursive resolver would reduce my reliance on a corporate upstream DNS provider. It wouldn’t hide all of my browsing, but I liked the idea of taking more control of that part of my network.
Other choices came from the tools that kept showing up in cloud and DevOps conversations. Prometheus and Grafana for monitoring and observability. If I wanted to work in that field, I should get hands-on experience with them, so I installed them.
Then there was Traefik. Both Traefik and Nginx can serve as reverse proxies. What drew me to Traefik was its cloud native approach, automatic service discovery, and support for automated certificate management. It also connected to something I wanted to learn: Traefik is the ingress controller bundled by default with k3s, which is what I now run in my lab.
There were good reasons behind those choices, and exposure to relevant tools has real value. But exposure was only the beginning. Installing a tool gives you the chance to learn it. It doesn’t give you something you need to accomplish with it, and that turned out to be the missing ingredient.
What changed when I graduated
Between school and everything else in my life, the homelab stayed in the background for a long time. That changed when I finished my degree.
With WGU behind me, I could give projects much more of my attention. I still have plenty to learn, but I finally had room to follow that learning into things I wanted to build. And building things requires infrastructure.
Suddenly, the servers and services I had set up had somewhere to fit. My sandbox gives me a place to develop an application. My k3s cluster gives me somewhere to deploy it when it’s ready. Monitoring has a more concrete purpose when there’s something I’m working on and want to understand.
The telemetry feed that gave monitoring a job
A recent addition to my portfolio site brought that change into focus. I wanted a live telemetry feed on the site. I already had Prometheus in the lab, but getting metrics from my home environment onto a public website meant connecting several pieces.
I collected sanitized metrics through Prometheus and installed Grafana Alloy to forward them to Grafana Cloud. From there, I set up read-only access and connected the metrics to a custom dashboard on my site. Embedding a Grafana panel through an iframe wasn’t straightforward for my setup, so I used the metrics to build the display into the site itself.
That gave the monitoring stack a job. I had a result I wanted to see, and getting there meant working through collection, forwarding, access, and presentation of the data. Alloy entered the lab because the project called for it. There was a reason to install it, configure it, and get the pieces working together, and once the feed was live, I could see the result of that work.
That is the connection I had been missing.
Somewhere to build, somewhere to deploy
The telemetry feed is one example. I’m also building a new application on my sandbox server. When it’s ready, I plan to deploy it to my k3s cluster.
That deployment is still ahead of me, but it gives the cluster a purpose I can work toward. The application needs somewhere to run, and the lab gives me an environment where I can learn how to get it there.
The projects are starting to connect the things I wanted to practice. Development leads into deployment. Deployment gives routing and monitoring something to support. Each piece has a reason to be there, and working on one gives me a reason to return to another.
What I’d tell someone building their first lab
I don’t regret setting up the homelab before I had a purpose for it. I wanted a place to learn, and it has been there as my time and interests allowed. But if I were starting over, I would build a project first, even a small one, and let the project decide which tools earn a place in the lab.
Tools you install out of curiosity teach you what they are. Tools you install because a project needs them teach you how they work.
I built the homelab to practice. The projects are finally giving me a reason to keep practicing.
Technical references: Pi-hole's guide to Unbound, K3s networking services and its bundled Traefik controller, and Grafana Alloy's Prometheus remote-write component.