The Twelve-Factor App is a methodology for building software-as-a-service applications, first published at 12factor.net in 2011. It was written by Adam Wiggins and other contributors drawing on their experience at Heroku, a platform that deployed and operated hundreds of thousands of applications. The document distills that operational experience into twelve concrete rules, each one phrased as a short imperative about how a well-behaved cloud application should be structured.
The twelve factors are: one codebase tracked in revision control with many deploys; explicitly declared and isolated dependencies; config stored in the environment; backing services treated as attached resources; strictly separated build, release, and run stages; the app executed as one or more stateless processes; services exported via port binding; scaling out via the process model (concurrency); robustness through fast startup and graceful shutdown (disposability); keeping development, staging, and production as similar as possible (dev/prod parity); treating logs as event streams; and running admin and management tasks as one-off processes.
Several of these factors became foundational vocabulary for modern operations. Factor III, “Store config in the environment,” argues that anything that varies between deploys - database handles, credentials, hostnames - should live in environment variables rather than be checked into the codebase. This cleanly separates code from configuration and avoids the trap of scattering settings across language-specific config files. The principle directly shaped later practices around environment-based configuration and the separation of secrets from source.
Factor VI, “stateless processes,” and Factor IX, “disposability,” anticipated the way containers and orchestration platforms would treat application instances as cattle rather than pets: a process should hold no important state in memory or on local disk, should start fast, and should shut down cleanly so that it can be created, destroyed, and replaced freely. These ideas align closely with immutable infrastructure and the elastic scaling models of cloud platforms.
The methodology arrived at a moment when teams were moving from hand-managed servers toward cloud platforms and, soon after, containers and microservices. Because the twelve factors describe properties an application should have rather than a specific tool to use, they remained influential well beyond Heroku. The document is frequently cited as a checklist for whether a service is “cloud native,” and its language - twelve-factor, config in the environment, backing services - became common shorthand in the DevOps and platform-engineering communities.