Why I Started Writing About My Homelab

Why this exists

I started this because I kept solving the same problems twice.

I would get Proxmox behaving, fix some weird networking issue, tune a VM, or finally remember the exact Ansible pattern that worked, then a month later I would be digging through shell history and old notes trying to reconstruct what I did. That is a bad system.

So this blog is partly public notes and partly a forcing function. If I have to explain the work clearly enough for someone else to follow, I usually find the weak spots in my own setup too.

What I am actually running into

Most of the things I want to write about are not glamorous. They are the parts of a homelab that either quietly work for months or waste an entire evening:

• Proxmox changes that need a rollback plan before I touch them
• Ansible roles that started as one-off commands and slowly became reusable
• GPU passthrough issues where the fix is usually one boring firmware, kernel, or IOMMU detail
• Self-hosted services that are easy to deploy and annoying to keep healthy
• Cloud gaming experiments where latency, drivers, and storage all matter more than the screenshot

That is the useful stuff to me. Not a perfect architecture diagram pretending everything was obvious from the start.

How I want these posts to feel

I am not trying to write vendor-style tutorials. I want the posts to read more like field notes: what I tried, what broke, what I changed, and what I would do differently next time.

Some posts will be runbooks. Some will be postmortems. Some will just be a clean version of notes I wish I had before I started.

The main rule is that the content should be tied to something real in my lab. If I did not run it, break it, fix it, or at least test it properly, it probably does not belong here.

What I will cover next

The next few topics will probably come from the work already sitting in front of me:

• where Terraform stops and Ansible starts in my setup
• how I want to handle secrets without making local development miserable
• basic observability for a mix of bare metal, VMs, and containers
• GPU passthrough notes that are specific enough to be useful later

That is the point of the site: keep the notes honest, keep them searchable, and make the next rebuild less painful than the last one.