The Twelve-Factor App
The Twelve-Factor App is a methodology for building software-as-a-service (SaaS) applications. It was drafted by developers at Heroku to synthesize their experience with building and deploying hundreds of apps.
The 12 Factors
1. Codebase
One codebase tracked in revision control, many deploys. There is always a one-to-one correlation between the codebase and the app. If there are multiple codebases, it’s not an app – it’s a distributed system.
2. Dependencies
Explicitly declare and isolate dependencies.
Never rely on implicit existence of system-wide packages. Use a dependency declaration manifest (like package.json or requirements.txt) and a dependency isolation tool (like Docker or virtualenv).
3. Config
Store config in the environment. Configuration that varies between deployments (staging, production, developer environments) should be stored in environment variables, not in the code.
4. Backing Services
Treat backing services as attached resources. A backing service is any service the app consumes over the network (databases, messaging systems, SMTP services). The app should treat them as attached resources, accessed via a URL or other locator stored in the config.
5. Build, Release, Run
Strictly separate build and run stages.
- Build: Converts code repo into an executable bundle.
- Release: Combines the build with the deploy's config.
- Run: Runs the app in the execution environment. You cannot change code at runtime.
6. Processes
Execute the app as one or more stateless processes. Processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service (database). Sticky sessions are a violation.
7. Port Binding
Export services via port binding. The app is self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
8. Concurrency
Scale out via the process model. Scale by adding more processes (workers), not by making one process larger (threads/vertical scaling).
9. Disposability
Maximize robustness with fast startup and graceful shutdown. Processes should start quickly (for scaling) and shut down gracefully (finish current request, put jobs back on queue) when they receive a SIGTERM.
10. Dev/Prod Parity
Keep development, staging, and production as similar as possible. Minimize the time gap, personnel gap, and tools gap between development and production. Use the same backing services (e.g., don't use SQLite in dev and PostgreSQL in prod).
11. Logs
Treat logs as event streams.
The app should not concern itself with routing or storage of its output stream. It should write everything to stdout. The execution environment captures this stream and routes it to final destinations (Splunk, ELK).
12. Admin Processes
Run admin/management tasks as one-off processes. Admin tasks (database migrations, REPL shells) should run in an identical environment as the regular long-running processes of the app.
programming/microservices-architecture programming/cloud-computing-basics programming/devops programming/docker-and-containers