Day Zero: Bootstrapping Talos

The talos repository’s first two commits, both on 1 April 2026, are blunt about what this was: Initial commit, immediately followed by Initial cluster configuration. No ceremony, no design doc committed alongside it — the repository starts exactly where the decision to build a real Kubernetes cluster on Talos Linux, managed end-to-end through GitOps, had already been taken.

Nineteen commits in one day

What follows over the next five days is not a smooth rollout. It’s 19 commits on day one, 20 on day two, 16 on day three — and a striking number of them are simply titled get it working. That’s not a euphemism for something else; it’s the literal, repeated commit message across dozens of small fixes as talconfig.yaml, the ArgoCD app-of-apps root, and the GitLab CI pipeline were all being wired together for the first time, with real hardware underneath.

That honesty is worth keeping in the record rather than editing out in hindsight: standing up etcd, getting talhelper generating valid machine configs, and getting the very first ArgoCD sync green all happened through trial and error, not a single clean apply.

What actually stuck from week one

A handful of decisions from these first five days turned out to matter for the rest of the project’s life:

• ArgoCD app-of-apps from commit one. Every workload since — platform and application alike — has been declared as an ArgoCD Application pointed at this repo. There was never a phase where things were deployed by hand and “GitOps’d later.”
• ArgoCD’s own operational quirks got fixed immediately, not patched around later. The Helm chart was bumped to 9.4.17 and the server set to insecure mode specifically so that setting would survive future chart upgrades — a small decision, but one that stopped a whole class of “ArgoCD broke itself on upgrade” incidents before they could start.
• Cilium’s runtime-managed resources were excluded from ArgoCD’s diffing almost immediately (Ignore Cilium runtime-managed resources to fix OutOfSync), and Hubble’s TLS certs were put behind a cert-manager self-signed issuer for the same reason. This is the first appearance of a pattern that recurs constantly for the rest of the project: a controller mutates its own resources at runtime, ArgoCD sees drift, and the fix is an explicit ignoreDifferences block rather than fighting the controller.
• GitLab Runner landed in the cluster on day one too — Kubernetes executor, Docker-in-Docker — because the CI pipeline building and applying every change afterward needed somewhere to run that wasn’t a laptop.

The state at the end of day five

By 5 April, the cluster wasn’t finished — it was barely a platform yet. But the two things that would end up mattering more than any single app were already true: everything lived in git, and ArgoCD was reconciling it. Everything built in the following eighteen weeks — storage, secrets, identity, every application eventually moved off the old VMs — landed on top of that same foundation, unchanged in shape from what was true on day five.