CI/CD
CI/CD is split cleanly along one line: app repos only build their own container image; a separate infrastructure repo owns every deploy. No app repo applies its own Kubernetes changes, and there’s no single command that deploys the whole fleet at once.
Build: automatic
Every app repo builds and publishes its own container image automatically on every push, on a shared build runner. No app needs its own separate setup for this — any repo in the org can use the same shared runner.
Deploy: deliberately manual
A person deliberately reviews and pins each new version before it goes live, one app at a time — never the whole fleet at once. Rolling back is a one-line change.
Why deploys aren’t automated
An earlier attempt at fully automatic deploys caused a real incident — a large backlog of queued deploy runs all fired at once and replayed old, stale infrastructure changes onto the live cluster. Automatic deploys have been switched off since, and deploys go through the manual, one-app-at-a-time path instead. Re-enabling automation would need a real rework, not just flipping a switch back on.
A known, accepted tradeoff
The build runner effectively has full administrative access to the cluster and the machine it runs on — a deliberate, accepted tradeoff for a single-operator org rather than an oversight. Tightening this (scoped permissions, a more restricted build sandbox) is the natural next step if this ever grows beyond one operator.