What twelve-factor is for
Portable, disposable, continuously deployable apps — the problem the twelve factors were written to solve.
The twelve-factor app methodology grew from Heroku-era SaaS: apps that must deploy often, scale out, and survive environment differences without snowflake servers.
What it optimizes for
- clean contract between app and OS/platform
- continuous deployment and minimal divergence between env
- scale via process model, not sticky machines
- developer/prod parity and declarative setup
What it is not
- a complete architecture guide (no DDD, no data modeling)
- a mandate to ignore stateful systems — databases are backing services, not the app process
- outdated dogma — containers and K8s implement many factors by default, but teams still violate config, logs, and parity daily
How to use these notes
Treat factors as a checklist in design reviews: “Where is config? How do we build once? Are processes disposable?” Adapt wording to your platform; keep the intent.
Smell test
If the app needs a hand-crafted VM, baked-in secrets, or latest rebuilt per environment to work, you are fighting twelve-factor — and your platform.