By Andy Boura🪶 A note on how this was written. This article was co-authored with the support of Claude, Anthropic's AI assistant. It draws on the principles and documentation developed while building and running the real-world working examples it describes.
In part 1 I argued that AI has made building software cheap but left running it as expensive as ever. The first principle of Governed NoOps is that the platform, not each application, carries that weight. This part covers the path every change takes, what the shared platform does, and how fast it applies updates, and why.
From idea to live: dev → staging → production
Every change travels the same three steps, and each step is a separate piece of the architecture, not just a label:
The link to the architecture is that staging and production are built from the same code, so staging is a faithful rehearsal rather than an approximation. They're separate stacks with separate roles, so a mistake or a compromise in one stays there. The guard rails sit outside this path altogether: they're never deployed by the pipeline at either stage.
⚠️ The production gate is me starting the run, because GitHub's built-in approval step isn't available for private repositories on the free plan. And dependency updates are the one exception to "I confirm staging": the update round takes them to production on their severity clock unless I hold one, because waiting on me would leave known vulnerabilities open for longer.
The platform does the heavy lifting
Each application should hold only what is unique to it. Everything that repeats lives once, in a shared platform defined in code, and is kept current there; this is often called a "paved road". In my case one repository defines everything in AWS (hosting, certificates, DNS, security headers, deploy roles) and each site's repository holds only its content. The platform hosts two sites today, with more joining, and adding the next one costs its content, not another stack to look after.
The upkeep runs itself. Several times a day a scheduled job looks at each identified dependency update and grades it by the most severe vulnerability it fixes (its CVSS score). When an update breaks the build, a scheduled agent session fixes it on its branch, and it may not skip or weaken a test to get there.
A paved road also makes the three Rs of security (Justin Smith, Pivotal) routine: repave, because everything is defined in code and can be rebuilt from it; rotate, because deploys use short-lived credentials issued per run; and repair, the patching below.
Most people building software with AI help have never had to decide how fast updates should go in, or even known that updates need applying, and shouldn't have to design a policy from nothing. So the defaults come with their reasons:
| Kind of update | Default wait | Why |
|---|---|---|
| Fixes a critical vulnerability (CVSS 9+) | None, once tests pass | Published holes are exploited within days; better briefly broken than vulnerable and open |
| Fixes a high one (7–8.9) | 1 day | Still urgent, but a day lets others find out if the fix itself is broken |
| Fixes a medium or low one | 3 days | Lower risk, a little more time to catch a bad release |
| Routine, no known vulnerability | 14 days | New releases are occasionally broken or hijacked; most are caught within days, so let someone else find out first |
| Major version | 28 days, and tell me | It may break things on purpose |
Better briefly broken than vulnerable and open.
— Andy Boura
Waiting protects against bad new code; hurrying protects against known holes in old code. The policy waits by default and hurries only when a known hole is being fixed. A deadline backs it up: a security fix reaches production by its due date even if something else breaks, unless I've explicitly placed a hold - because broken and secure is better than working but hacked.
In practice the wait runs twice: once before an update reaches staging, and the same again before production, so staging has time to show a problem. I can shorten it for a single update or hold one back, with a label on its pull request. A hold is mine until I lift it, and the report reminds me while a held security fix is past its due date.
Propose the default policy with a plain-words reason for each setting, build it so it works once accepted, and mark every speed-versus-safety choice as a proposed default for a person to confirm.
Rule for your agent, from the companion skill
The trade-off: the autonomous zone trusts upstream
An update can merge without a person, so a poisoned package is a real path in. The 14-day wait on routine updates, actions pinned to exact commits and a supply-chain check in CI narrow it. Critical fixes skip the wait by choice. There is also defence in depth, with security checks on every change.
In part 3 I turn to the evidence: how the platform keeps its compliance documents current without anyone assembling them.