There's a question every enterprise security questionnaire asks in some form: how are deployment credentials managed and rotated?
The honest answer, at most companies, is a long-lived token pasted into a CI settings page two years ago by someone who has since left. It has more permissions than it needs. Nobody knows exactly what would break if it were rotated, so nobody rotates it.
We don't have one to rotate.
How it works
CI doesn't hold credentials. When a job needs to deploy, it presents a token that the CI provider itself issues and signs — one that says I am this workflow, on this repository, on this branch, and that expires in minutes.
OpenBao verifies that signature, checks the claim against a policy, and hands back only the secrets that specific job is entitled to. Those are short-lived too.
The result is that there is no moment where a durable secret sits anywhere it could leak from. Not in a CI variable, not in a .env on someone's laptop, not in the shell history of whoever set it up. The secret you never stored is the one you never have to rotate, audit, or explain in an incident review.
One path, every target
The same pipeline deploys a Worker to Cloudflare's edge and a container onto a dedicated server. Same review, same audit trail, same one-click rollback, whatever is being shipped.
That mattered more than I expected. The temptation with a new deployment target is always to give it its own bespoke path — it's faster on the day. What you get six months later is four deployment systems with four failure modes, and the one nobody uses often is the one that's broken when you need it.
Four applications now run on this foundation. The fourth cost a fraction of the first, which is the only real evidence that a platform is working.
The monitoring ships this way too
Dashboards and alert rules aren't clicked together in a console. They're code, and they go out through the same pipeline as the products.
Raising an alert threshold is a reviewed pull request. That sounds like bureaucracy and is the opposite: it means the Grafana you're looking at and the Grafana in the repository are the same Grafana, and nobody has to wonder whether a threshold was changed at 2am during an incident and never changed back.
Including me
Machine access runs through one identity-based system with auditable sessions, rather than distributed keys.
I don't have direct access to those machines either. I log in the same way everyone else does, and it's recorded the same way.
This is the part people push back on when they build something like this, usually with a reasonable-sounding argument about needing a break-glass path. Keep a break-glass path — but make it loud, logged, and rare. A control that quietly exempts the person who built it isn't a control. It's a description of a control, and the difference becomes visible at exactly the wrong moment.
What this actually bought
The security questionnaire answer is the smallest benefit, though it is a real one: how is privileged access managed, how are secrets rotated, what happens if CI is compromised — each of those now names a system instead of needing a paragraph of apology.
The bigger one is that deploying stopped being an event. There's no ceremony, no person who has to be awake, no credential someone has to be trusted with. It's a merge, and then it's live, and if it's wrong it's one click back.