The twelve factors are a set of rules for building applications that any environment can run unchanged: immutable, ephemeral, declared and automated. The canonical statement of each factor is quoted below from 12factor.net, alongside what it asks of an application in practice.
| Factor | Canonical rule | In practice |
|---|
| Codebase | One codebase tracked in revision control, many deploys | One repository per application. The same codebase produces every deploy of it; a second codebase means a second application. |
| Dependencies | Explicitly declare and isolate dependencies | Declare every dependency in a manifest and isolate it at runtime. Never rely on a package that happens to be installed system-wide. |
| Config | Store config in the environment | Anything that differs between environments is separated from the code and read from the environment, not from a checked-in file. |
| Backing services | Treat backing services as attached resources | A database, broker or cache is reachable by a URL in config, and swapping a local instance for a managed one is a config change, not a code change. |
| Build, release, run | Strictly separate build and run stages | Build produces an artifact, release combines it with config, run executes it. A release is immutable and can be rolled back; code cannot be changed at runtime. |
| Factor | Canonical rule | In practice |
|---|
| Processes | Execute the app as one or more stateless processes | Processes share nothing and hold no session state. Do not use sticky sessions; persist anything that must survive a request to a backing service. |
| Port binding | Export services via port binding | The application binds its own port and serves HTTP itself, rather than depending on a webserver being injected into a runtime container around it. |
| Concurrency | Scale out via the process model | Scale by running more processes of the right type, not only by making one process bigger. |
| Disposability | Maximize robustness with fast startup and graceful shutdown | Fast startup so capacity can be added quickly, graceful shutdown on SIGTERM, and resilience to a process dying without warning. |
| Dev/prod parity | Keep development, staging, and production as similar as possible | Close the gaps in time, personnel and tooling: dev = staging = prod, including using the same backing services in each. |
| Logs | Treat logs as event streams | The application writes an unbuffered event stream to stdout and never manages log files or rotation. The environment routes and stores it. |
| Admin processes | Run admin/management tasks as one-off processes | Migrations and one-off scripts run in an identical environment against the same release, as isolated processes, not by hand on a running instance. |