The Old World

There’s no single dramatic commit that marks “the decision” to leave Proxmox. The talos repository’s very first commit — 1 April 2026 — already assumes the choice had been made. So before the story of the cluster starts, it’s worth being honest about what it was replacing, because that “before” picture is scattered across several old repos rather than written down anywhere as one system.

Proxmox: a burst, then silence

The proxmox Ansible repo tells its own story just from its commit dates. Real work happened in a five-week burst from 31 March 2024 to 6 May 2024 — kvm-create.yml and kvm-create-cloudinit-PXE.yml for provisioning KVM guests, lxc-create.yml for lightweight containers, pve1.proxmox.yml as the dynamic inventory source pointed at the actual hypervisor, pve1.turnbull.uk. One concrete artifact survives from that period: an example LXC task provisioning a wireguard container.

After that burst, the repo goes quiet for almost two years. It doesn’t have a single commit recording “Proxmox decommissioned” or “last VM migrated off” — whatever wound it down happened outside of git, on the box itself, not as a tracked change. The only commits after that gap (August 2026) are CI housekeeping — moving the pipeline off a Docker Hub base image, then onto gitlab.com — not infrastructure changes. By the time the Kubernetes cluster existed, Proxmox had already faded out rather than being formally cut over.

What was actually running

The clearer picture of “the old world” comes from two VMs that were still very much alive when the k8s work began:

• debian-dev01 (Debian 11, 172.31.99.11) — a general-purpose services box running the GivEnergy inverter poller, the Magrathea CDR downloader, the Wooden Daisy image pipeline, Kanboard, ddclient for dynamic DNS, and — tellingly for what’s coming — an already-sealed HashiCorp Vault instance and a GitLab Runner on the old v15.7.0. Cacti, TFTP and RANCID also lived here, and as of this writing still do — this VM’s migration to Kubernetes was never fully closed out.
• debian-gitrunner — the VM behind gitlab.turnbull.uk, the self-hosted GitLab instance the talos repository itself originally lived in (awxgit/talos, over SSH). It doubled as the Raft leader for that early Vault cluster, spread across srv2.8p.uk and cp03.abt.me over a dedicated WireGuard mesh (100.65.20.0/24). This machine is still powered off today, untouched, a relic of the pre-cluster secrets story.

Vault itself predates the Kubernetes cluster entirely — it wasn’t stood up as part of this migration, it was inherited. The very first meaningful platform commit in the new cluster, four working days in, is “Replace sealed-secrets with External Secrets Operator backed by Vault” — reusing infrastructure that already existed, not building new secrets tooling from scratch. A few days later, on 13 April 2026, comes “Add Vault HA migration docs: file to 3-node Raft cluster” — hardening that inherited single point of failure into something the new cluster could actually depend on.

The shape of the problem

None of this was written down as a plan at the time, but the shape of it is clear in hindsight: a Proxmox hypervisor nobody was actively managing anymore, a handful of standalone VMs each running one or two services with their own ad-hoc Ansible playbooks, a secrets story held together by a single Vault Raft leader on a box called debian-gitrunner, and a self-hosted GitLab instance that was itself a single point of failure for every other piece of automation.

Nothing here was on fire. It worked. But there was no shared platform underneath any of it — no unified way to deploy, no unified way to store secrets, no unified way to recover if one VM died. That’s the gap the next five months of work fills in.