The Machine as Code

Most of my infrastructure used to live in my memory. I knew which service ran where because I had set it up; the rest was a handful of scripts I had half-forgotten. This is the first entry of a publication I run from a system built so I do not have to remember, and it is a proof of concept for that system. What follows is the whole of it, named part by part, because a proof you cannot inspect is only a claim.

One repository owns the machine

I built a single monorepo, Sysop, and made it own three things at once: the configuration of the host it runs on, the configuration of the cluster it operates, and this publication. I reason about the whole repository now, not any one piece; that is the point of putting them together.

The host is basestar, an M3 Ultra Mac Studio. It runs as a declarative nix-darwin flake on the Lix interpreter, version 2.95.2, pinned in the configuration rather than tracking whatever is newest. One file describes the machine: 54 Homebrew formulae and 8 casks captured from the live system, three scheduled and background jobs (a weekly baseline check, a weekly supply-chain watch, and a local language model daemon that serves Gemma 4 26B on port 1235, whose launcher script I vendored into the repo because it was tracked nowhere else), and TouchID for sudo. A second file composes my shell and git configuration from typed options, so several tools each contribute to one generated file instead of me hand-editing a template.

I build it with one verb, and the build changes nothing on its own; it produces an artifact I diff against the running system before I commit to it. Then I activate, and that step is now done. The flake is the source of truth for the host. One switch took over Homebrew, the login daemons, and the system defaults, turned on TouchID for sudo, and moved my shell, prompt, and terminal configuration off the old dotfile manager and under the same repository as everything else. The activation is idempotent, so re-running it converges the machine rather than drifting it.

I took the cluster over while it ran

I already had a live cluster, k3d-pet, running k3s 1.31.5 inside OrbStack and doing real work: a Cloudflare tunnel, a Prometheus and Grafana stack, an OpenTelemetry collector, a Discord bot, and this blog. Flux now reconciles it from the repository about once a minute, applying three ordered layers; infrastructure first, then the secret stores, then the applications, each waiting on the one before it.

I did not rebuild anything. For each component I had installed by hand, cert-manager 1.19.2, the kube-prometheus-stack 80.2.0, the Grafana operator 5.20.0, and External Secrets Operator 2.6.0, I wrote a release object pinned to the exact version already deployed, fed it the values I had captured from the live install, and told it to leave alone the custom resource definitions it already owned. The upgrade re-rendered to the same manifests, so nothing changed and nothing restarted. I verified every adoption the same boring way: I confirmed the pod restart counts and the stateful identities did not move. The proof of a clean takeover is the absence of an event.

I also threw something away. An automation tool I no longer used was deleted cleanly, after a backup, because in this repository removing a moving part rarely needs a justification and keeping one always does.

I keep no secrets in the repository

Nothing sensitive is in my git history. External Secrets Operator runs inside the cluster and pulls credentials from a 1Password vault at runtime; the repository holds only references, small objects that name an item and a field. There is exactly one secret I inject by hand: a read-only service-account token, seeded into the cluster once, with its trailing newline stripped because the integration rejects it otherwise. From that single root, the operator fetches everything else.

I moved four secrets this way: the tunnel credentials, the blog's deploy key, the Discord bot's tokens, and a database token for a Grafana datasource. Each migration was verified before I trusted it. I synced the value from 1Password into a throwaway secret, compared a sha256 hash against the value already live in the cluster, and only then let the operator adopt the real one in place, with no gap in service. One secret I deliberately left alone: Grafana's admin credentials are generated and owned by its own operator, and the secrets operator cannot take ownership of something another controller already holds. The history is safe to read; it records where my secrets go, never what they are.

This page is the proof

This publication is the smallest honest end-to-end test of the system, so let me trace the exact path of the words you are reading. I wrote this entry as Markdown with a small structured header. A version-pinned static generator, Zola, rendered it through a rigid editorial template: numbered sections, the metadata table above, a skeptic's section, one concrete action, and the verification footer below. It carries a single third-party browser dependency, htmx, vendored as one file and checked against a fixed hash, never loaded from a content network. The page ships as plain HTML and CSS; nothing dynamic runs unless I later decide it must.

The whole publish runs behind one verb. It renders the site, lints the frontmatter so every entry carries its required sections, checks the internal links, and pushes the output to a git repository over my own key. Inside the cluster, a different and read-only key, the one the secrets operator manages, pulls that repository every thirty seconds; an nginx container serves the static files; and the same Cloudflare tunnel that fronts everything else maps blog.cogignition.cloud to it. The write path and the read path use two separate keys that never overlap.

No build ran on a server I do not control. If this reached you at that address, every part named above did its job. The next entries will test whether the discipline was worth it.