A methodology published by the Heroku folks in 2011 for applications that run as a service in the cloud. More than a decade later, it is still the baseline for what we expect from a containerized application.
| # | Factor | What it says | In practice |
|---|---|---|---|
| I | Codebase | One versioned codebase, many deploys | The same repository produces dev, staging and production |
| II | Dependencies | Explicitly declare and isolate dependencies | go.mod, pom.xml, package.json; nothing installed “by hand” on the server |
| III | Config | Store config in the environment | Database URL and keys in environment variables, not in code |
| IV | Backing services | Treat backing services as attached resources | Swapping the local database for a managed one only changes config |
| V | Build, release, run | Strictly separate the stages | An image built once and promoted across environments |
| VI | Processes | Run as stateless processes | Session in Redis, not in the instance’s memory |
| VII | Port binding | Export services via a port | The app starts its own HTTP server on the configured port |
| VIII | Concurrency | Scale out with more processes | More replicas instead of a bigger machine |
| IX | Disposability | Start fast and shut down gracefully | Handle SIGTERM, finish in-flight work and exit |
| X | Dev/prod parity | Keep environments as similar as possible | The same Postgres in dev (via a container) and in production |
| XI | Logs | Treat logs as event streams | Write to stdout and let the platform collect them |
| XII | Admin processes | Run admin tasks as one-off processes | Migrations running as a job, with the same code as the app |
Many of these factors are what make an application easy to run in containers.
- See more at: The Twelve-Factor App