The 12 Factor App
Created: 2025-11-15: Blind summary of the factors
Codebase
- Keep the code of the application within a version control system, this should enable the control of the deployment units (production, development, staging, etc).
- Shared code should be implemented through libraries which are handled by a dependency manager
Dependencies
- All dependencies should be explicitly defined in a manifest.
- Builds should be deterministic
Config
- Source code and configuration of deployments should be strictly isolated.
I don't agree that the best solution are env vars but whatever, it is A solution
Backing Services
- Treat all services as remote resources. (ie. Changing the location of a Database should just require modifying config values)
I think it is a bit misleading the "[...] without any changes to the app’s code" sentence. You could think code reuse and abstraction are king, and to some degree they may be, but without understanding the trade-offs, this can be very painful long-term.
To be clear, the example is fine, IF it is from MySQL to MySQL Aurora RDS. Someone may read this only knowing that Aurora RDS has a PostgreSQL version and think their code should handle both engines.
Build, release, run
- Builds should be inmutable. While pulling configuration variables and executing the binary could be executed N times to the same build
If the build is attached to a commit in your version control system, and you have your dependencies explicitly defined in a manifesto, GENERATING a separate ID to identify the build seems redundant. Do use something to identify the build. I'm just saying it is not necessary to have a separate data store to know which build you are at.
Processes
- State should be isolated from the application. Every unit/deployment should not manage any state. They should be stateless.
Port binding
- Expose everything as a network call.
I don't like this, because the network is unreliable. Since this whole thing prefaces with "In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service." I think this whole "chapter" is binded to that context.
Concurrency
- The smallest unit of an application should be a process.
- A single application could have in a single machine multiple instances through separate processes.
- Processes can internally handle their own multiplexing.
Great, but this may be interpreted as "if you need to scale, just spawn more processes". Since they should be stateless, you could have N processes in M machines. Thats ok, but make sure you dont have wasteful processes first. You could be unnecessarily wasting CPU or memory. and since it is easier to spawn a process in a separate machine, you keep the wasteful application running.
Disposability
- Fast startup, graceful shutdown
- Transactions should be idempotent
Dev/prod parity
- Environments should be as similar as possible.
- Developers should be able to deploy and monitor their code.
- "Time to merge" should be as small as possible
Logs
- Processes should stream their logs to stdout. This can then be routed to somewhere else.
- Use an indexing and analysis system for your logs.
Admin processes
- Administrative tasks should be scripted and kept within the codebase.