Long before Kubernetes or serverless existed in their current form, engineers at Heroku distilled a set of principles for building applications well suited to cloud deployment, drawn from patterns they observed across many applications running on their platform. The twelve-factor app methodology remains one of the most widely referenced architectural checklists in cloud-native development, and it’s worth examining both what it actually says and how well it’s held up.
What the twelve factors cover, broadly
The twelve factors span several themes rather than being a single unified idea: how dependencies are declared and isolated, how configuration is handled, how the application treats backing services, how the build, release, and run stages are separated (discussed further in Build Once, Deploy Everywhere), and how the running application processes are designed — stateless, disposable, and able to start up and shut down quickly.
The factor that’s aged best: config
Factor three, config, states that configuration — anything that varies between deployment environments, such as database credentials or external service endpoints — should be stored in the environment, strictly separate from the application code itself, never hardcoded and never checked into version control. This principle has held up completely, and if anything has become more deeply embedded in standard practice since, forming the basis of how secrets management in CI/CD is expected to work: credentials and environment-specific values injected at runtime, never baked into a build artifact or committed to source control.
Processes as stateless and disposable
Factor six, processes, states that application processes should be stateless, with any data that needs to persist stored in a backing service — a database or an external cache — rather than in the process’s own memory or local filesystem. Factor nine, disposability, states that processes should be able to start up quickly and shut down gracefully at any time. Both principles have aged well and are, if anything, prerequisites for the compute models discussed in Serverless vs. Containers vs. VMs: a serverless function that can’t start quickly, or a container that can’t be safely and quickly replaced, fights directly against how those platforms are designed to work.
Where the platform assumptions have shifted
A few of the original factors were written with assumptions specific to Heroku’s platform model circa its original publication, and the surrounding infrastructure landscape has evolved in ways that change how some of them are best implemented, even where the underlying goal remains sound. Factor four, backing services, treats every backing service — a database, a queue, a cache — as an attached resource, addressable through configuration, interchangeable without a code change. The goal has held up completely; the implementation has evolved considerably, with service meshes, discussed in What Is a Service Mesh?, and more sophisticated service discovery mechanisms now often handling what the original methodology assumed would be managed through simpler, more manual configuration.
Factor eight, concurrency, recommends scaling out by running more processes rather than relying on threading within a single process — a principle that maps naturally onto how container orchestration and horizontal scaling generally work today, though the specific mechanics of exactly how an application scales out have grown considerably more automated and sophisticated than the original methodology’s model of manually adjusting a fixed number of process types.
Applying it as principles, not a rigid checklist
The methodology is best read today as a set of durable underlying principles — separate config from code, keep processes stateless and disposable, treat backing services as attached and swappable — rather than a literal, unmodified checklist to follow exactly as written. Some later commentary and extensions (sometimes discussed as a “fifteen-factor” or “beyond twelve-factor” approach) have proposed additional factors addressing things like API design, telemetry, and authentication that the original methodology didn’t cover — a reasonable acknowledgment that the cloud-native landscape has grown considerably since the original list was written, without invalidating what the original factors got right.
Key takeaway
The twelve-factor app methodology’s core principles — especially strict separation of configuration from code, and treating application processes as stateless and disposable — have held up well over more than a decade and remain standard, sound practice in cloud-native application design. The specific platform mechanics behind a few of the original factors have evolved considerably since, which is best understood as the surrounding infrastructure catching up to and building on the underlying principles, not as those principles being wrong.
This article summarizes a widely referenced methodology; the original source is linked above for full detail. See our disclaimer.