Run migrations, consoles and one-off scripts as short lived processes from the same release, config and dependencies as the app, and restrict and log who can start them. Twelve-factor calls these admin processes. They are powerful because they reach the live database with the app's credentials.
What counts as an admin process
The methodology lists three typical cases: running database migrations, opening a console to run arbitrary code or inspect models against the live database, and running one-time scripts committed in the repo. It says they should run in an identical environment to the regular processes, against a release, with the same codebase and config, and that admin code should ship with application code to avoid synchronization problems.
In production, it notes, developers can use ssh or another remote command mechanism from the execution environment to run them.
Why the risk is higher than it looks
A production console is a way to run any code with the app's database access. That makes it equivalent to a very privileged user, often with no review. Common problems follow.
- Shared credentials. Everyone who needs a console uses the same service account, so audit logs cannot say who did what.
- Code that is not in the release. An engineer pastes a script into a console. It is unreviewed, unscanned and gone after the session.
- Standing access. Console access is granted once and never removed.
- Secrets in shell history. Connection strings and tokens end up in terminal history or tickets.
Safer patterns
- Script it, review it, ship it. Put one-off scripts in the repo and run them from the release, as the methodology advises. Review applies to them like any other change.
- Run as a job. In Kubernetes, a Job runs a task to completion as its own pod, with its own logs and a clear start and end. That beats a long lived interactive session.
- Use a dedicated identity. Give migrations a credential with schema change rights that the web process does not have, and give the web process the narrower set it needs.
- Time box interactive access. If a console is unavoidable, grant access for a limited period with approval, and record who opened it and when.
- Record output. Keep logs of the commands run and the rows affected, without printing secrets.
- Test migrations first. Run them against a restored copy of production data shape before the real run, with care for personal data.
Migrations as part of the release
Order matters. A migration that drops a column breaks the old version still running during a rolling deploy. Make changes backward compatible in steps: add, backfill, switch, then remove. This is correctness work, but it also keeps rollback possible, which is a security property when you need to revert a bad release quickly.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the code scan and notice that one-off scripts in the repo get the same review as application code.
Quick check
Is it okay to open a production console for debugging?
Only with a clear reason, limited time, approval and a record of what was run. Prefer a reviewed script run as a one-off job.
Should migrations use the same database user as the web app?
Better to separate them. The migration identity needs schema rights, and the web process normally should not have them.
Why must admin code ship with the app?
The methodology says this avoids synchronization problems, and it also means one-off code is reviewed and scanned like everything else.
Where Safeguard fits
Safeguard's policies and gates can require review before changes land, and SAST and dependency scanning cover scripts that live in the repo alongside the app. Compliance and evidence automation helps you keep records of who approved what. Try a free scan.
Sources
Last reviewed: 19 October 2026.
