#Staging

Three commands that take a tested release into production without overwriting what production owns: they promote configuration structure but keep its secrets and addresses, refuse to copy new secrets, and apply schema migrations the images carry.

Three commands that build a full copy of production for one release — configuration from the repository, images from the registry, data from the latest backup — restore it in order, run the release's migrations against that data, and remove it without a trace.

Release Workflow: Development to Production is the procedure every change of mine follows from my laptop to production — which steps I automated, which I deliberately left to a person, why each step sits where it does, how I diagnose a failed release, and how I recover from it.

Staging and production shared 136 keys, but 21 had to stay different, including the one that decrypts years of data. Promoting a release's structure, not a file's contents, keeps that key in place and stops a schema migration from silently never running.

Point one environment's volumes at another's data and the restore succeeds, every health check passes, and the database is empty. Separating networks, state and runtime identity is what keeps three environments on one host from quietly erasing each other.