Twelve-Factor application: practices, not magic infrastructure

The Twelve-Factor methodology separates source, build, release configuration, processes, backing services and logs. It is a useful application contract, but it does not supply a deployment controller, rollback, database replication, backup restoration, queue semantics or multi-region recovery. Those remain explicit architecture and operational work.

Boundaries that matter

• A build artifact is immutable and reusable. A release combines that artifact with environment-specific configuration.
• Deploy-varying configuration, including resource addresses and credential references, stays outside source. Prefer short-lived credentials and a dedicated secret manager.
• Stateless processes may be replaced, but durable state must live in attached resources. The diagram therefore includes the database, Redis, and queue as real edges rather than implying that process statelessness removes them.
• Disposability requires bounded startup/shutdown, health checks, idempotent recovery of in-flight work, and supervision.

Failure and security rules

A cache outage can shift load to the database; a queue retry can repeat a side effect; and a process crash can leave an acknowledged request ambiguous. Define timeouts, retry budgets, idempotency keys, expiry and overload behavior for each backing service.

If a secret enters Git history, revoke or rotate it before attempting a history rewrite. Rewriting does not invalidate clones, forks or cached copies and can recontaminate the repository if collaborators are not coordinated.

Scenarios

Sources

• The Twelve-Factor App
• Config
• Backing services
• Processes and disposability
• GitHub: removing sensitive data