Twelve-Factor App

The Twelve-Factor App methodology, articulated by Heroku engineers in 2011, defines a contract for building portable, scalable, maintainable software-as-a-service applications. Each factor addresses a specific source of operational fragility — configuration drift, environment parity gaps, and unreliable process management. Adherence enables zero-downtime deploys, horizontal scaling, and smooth migration between cloud providers. The methodology is prerequisite knowledge for Kubernetes-native application design.

Key Points

• I — Codebase: one codebase tracked in VCS, many deploys. No per-environment branches; use environment variables for differences.
• II — Dependencies: explicitly declare all dependencies (package.json, requirements.txt); never rely on system-wide packages.
• III — Config: store config in environment variables, not in code or config files checked into VCS.
• IV — Backing Services: treat databases, caches, and queues as attached resources, swappable via URL/config without code changes.
• V — Build/Release/Run: strictly separate build (compile), release (combine build + config), and run (execute) stages.
• VI — Processes: execute the app as one or more stateless, share-nothing processes — session state lives in Redis, not in-memory.
• VII — Port Binding: export services by binding to a port, not by injecting a web server — the app is self-contained.
• VIII — Concurrency: scale out via the process model (web, worker, clock process types), not by threading within a process.
• IX — Disposability: processes start fast (<5s) and shut down gracefully on SIGTERM, completing in-flight requests.
• X — Dev/Prod Parity: keep development, staging, and production as similar as possible to eliminate "works on my machine" bugs.
• XI — Logs: treat logs as event streams — write to stdout, let the platform aggregate (ELK, Datadog, Cloud Logging).
• XII — Admin Processes: run admin/management tasks (migrations, console) as one-off processes in the same environment.