In this series
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 .
Amp let me coordinate different parts of the rebuild across devices and environments.
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.
I closed 33 legacy Dependabot pull requests on 17 August. Dependabot opened a fresh batch three days later, as automation should.
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.