Twelve-Factor App

framework · computer science · organizing-schema

Heroku's methodology for building scalable, declarative SaaS applications.

The Twelve-Factor App is a methodology for building software-as-a-service applications, articulated by Heroku co-founder Adam Wiggins in 2011 and published at 12factor.net as a practical synthesis of patterns Heroku had observed across hundreds of applications running on its platform. The twelve factors: I. Codebase (one codebase tracked in revision control, many deploys); II. Dependencies (explicitly declare and isolate); III. Config (store in the environment); IV. Backing services (treat as attached resources); V. Build, release, run (strictly separate stages); VI. Processes (execute the app as one or more stateless processes); VII. Port binding (export services via port binding); VIII. Concurrency (scale out via the process model); IX. Disposability (maximize robustness with fast startup and graceful shutdown); X. Dev/prod parity (keep development, staging, and production as similar as possible); XI. Logs (treat as event streams); XII. Admin processes (run admin/management tasks as one-off processes). The methodology has been substantially adopted across cloud-native development and substantially influenced Kubernetes design, with Beyond the Twelve-Factor App (Hoffman 2016) extending the framework for modern cloud-native contexts.

Originators

Adam Wiggins (Heroku) high

Year / Decade

2011 (12factor.net publication) high

Primary sources

Wiggins, A. (2011). The Twelve-Factor App (12factor.net), Hoffman, K. (2016). Beyond the Twelve-Factor App high

Core components

Twelve specific factors: Codebase, Dependencies, Config, Backing services, Build-release-run, Processes, Port binding, Concurrency, Disposability, Dev/prod parity, Logs, Admin processes
Heroku platform context
Stateless process emphasis
Configuration via environment
Statelessness and disposability
Connection to cloud-native and container-orchestration practices
Beyond the Twelve-Factor App (Hoffman) extension

Primary use case

Cloud-native and platform-as-a-service application development; foundation for modern container-orchestration practice (Kubernetes); checklist for application portability between cloud providers; teaching tool for cloud-native development; integration with continuous deployment and DevOps practices.

Common criticisms

Some factors (e.g., port binding) reflect Heroku's specific platform design more than universal cloud-native principles
'stateless processes' oversimplifies for stateful workloads (databases, queues, caches) which most systems require
logs as event streams can produce log-volume explosions in modern microservices contexts
doesn't address security, observability, or contemporary concerns adequately (Beyond Twelve-Factor addresses some)
methodology is twelve years old and predates Kubernetes, serverless, and edge computing
can be cargo-culted as compliance checklist without underlying understanding
some factors (Dependencies, Config) are universal good practice while others (Concurrency model) are platform-specific.

Lineage

Siblings: Microservices, DevOps