1. Why I modernized my homelab instead of upgrading it (this post)

This is the start of a new series about rebuilding my homelab from the ground up. Later posts will cover the platform, applications, data and lessons from the journey. This first part is about the decision that shaped everything afterwards: I was not looking for a like-for-like upgrade. I wanted a full-scale modernization .

I have written about my tiny yet powerful homelab before. It started with four Raspberry Pis, a QNAP NAS and a small Lenovo PC. It grew into a useful collection of home applications and a playground where I could learn Kubernetes, networking and storage.

It also grew one experiment at a time. I would get an application running and then move on to the next idea. After a few years, some applications were stuck on old dependencies, deployment instructions existed only in my head, and documentation had drifted away from reality. A change in one place could have consequences somewhere completely unexpected.

My Dependabot page told the same story. I had accumulated update pull requests that I simply had no idea how to resolve safely. The backlog had grown to the point where it became easier to ignore the list than to work out where to begin.

A small but satisfying footnote: I asked Amp to close the entire legacy batch in one go. When Dependabot opened another batch, I came back today and asked Amp to decline all of those too—the modernization meant I no longer needed them.

A power trip that took down my homelab network provided another warning. Amp helped trace the failure across the network and Kubernetes, but the incident reminded me how difficult an organically grown system can be to reason about when something goes wrong.

I could have installed a newer Kubernetes version, restored all the old workloads and called the job complete. That would have been faster at the beginning, but it would also have preserved every outdated dependency, hidden assumption and awkward workflow. I would have ended up with a newer cluster carrying exactly the same baggage.

So I decided to treat the old homelab as a source of requirements, not as a template.

The useful applications and important data would stay. Everything else had to justify its place. Old dependencies would be upgraded or removed, applications could be rebuilt when incremental upgrades no longer made sense, and important operational knowledge would move out of my head and into the repository.

This finally gave me a way to clear the legacy Dependabot backlog. Closing that old batch was a satisfying sign that this was real modernization rather than a cosmetic upgrade. New updates will always arrive, but now I have a much better foundation for dealing with them.

I also wanted the repository to be friendly to AI coding agents. That does not mean allowing an AI to make uncontrolled infrastructure changes. It means creating an environment where an agent can understand the system, follow paved paths, run the right checks and know when it must stop and ask me.

This closely matches Amp’s article about putting an agent in an Orb: an effective development environment should be designed for agents from the start, not adapted as an afterthought. Agents in Orbs and agent-to-agent communication arrived at the right time. They made it practical to divide the rebuild into focused pieces and involve the real homelab only when verification required it.

Amp did much of the heavy lifting, but it did not replace engineering judgment . I still chose the direction, decided which risks were acceptable and approved operations affecting real services or data. The agents investigated, implemented, tested and kept detailed records. That combination let me move faster without lowering the quality bar.

More importantly, it changed what felt possible. Instead of spending my time keeping old components alive, I could improve existing applications and try new ideas. The homelab was becoming a platform for experimentation again, rather than a collection of dependencies I was afraid to touch.

In the next post I will start with the foundation of the rebuild: the new Kubernetes control plane and the decisions that went into building it safely.

Originally published on V for Vincent.

This time the trouble started with an unexpected power trip. After I restored the power, the homelab network did not come back. There was no obvious error anywhere. My routers were online, the modem had reconnected and all the usual lights looked normal. But services were still unreachable and my Kubernetes control plane could not start properly.

I started spot-checking the network configuration and noticed that the DHCP advertisement was wrong. One of my Ubuntu VMs had received a completely different IP address, gateway and DNS server. That was a useful clue, but I still had no idea which device was sending it or why.

So I asked Amp to investigate.

Amp connected to the VM over SSH and checked its addresses, routes and DHCP lease. It then went through the old system logs and found a very clear before and after. Before the power trip, the VM always received its reserved address from my main router. After the power came back, another device started giving it two-minute leases with the wrong gateway and DNS server.

At first I suspected Pi-hole, because it can also run a DHCP server. Amp checked its configuration and backups and ruled that out. It then identified the unexpected DHCP server as one of my TP-Link powerline extenders.

It turned out that the extender has a feature called Smart DHCP. If it cannot find another DHCP server, it starts one by itself to make initial setup easier. During the recovery from the power trip it could not see the router’s DHCP service, so it began handing out its own network configuration. Everything looked online, but devices were quietly being told to use the wrong gateway and DNS server.

Amp also worked out that the Kubernetes failure was not a separate problem. The control plane was configured with the VM’s reserved address, but that address no longer existed on the VM. Kubernetes quite rightly refused to start its networking.

After I disabled Smart DHCP on the powerline extender and rebooted the VM, Amp checked everything again. The lease was coming from the correct router, the VM had its reserved address and gateway, Pi-hole was resolving DNS, and every Kubernetes node was healthy again.

Without Amp, I would probably have spent hours rebooting devices and changing settings one by one. Instead, it followed the evidence from DHCP to Linux networking, Pi-hole and finally Kubernetes, then made sure the fix really worked.

What a gem! This is exactly the sort of problem where an AI coding agent is surprisingly useful. It did not just give me a list of commands to try. It investigated the actual machines, connected all the symptoms and stayed with the problem until my homelab was back.

Also, stay tuned! A version 2 build of my homelab is already in progress. I will write more about the new setup, what I am changing and everything I learn from rebuilding it from scratch.

Originally published on V for Vincent.