Twelve-factor app (12-factor app)

The twelve-factor app is a set of twelve practices for building services that run well on cloud platforms. Heroku engineers led by Adam Wiggins published it at 12factor.net in 2011. The factors are: codebase; dependencies; config; backing services; build, release, run; processes; port binding; concurrency; disposability; dev/prod parity; logs; and admin processes.

How it works

The common thread is that one build artifact should run anywhere, with everything that differs between environments supplied from outside. Dependencies are declared explicitly, processes are stateless and keep shared state in backing services such as a database, the app binds to its own port, and it writes logs to stdout as a stream instead of managing log files. Processes start fast and shut down cleanly, so the platform can scale or replace them at any time.

Factor III says config belongs in the environment. In the bootcamp student API, the database address comes from DATABASE_URL at startup instead of being hard-coded. The same students-api:1.4.0 container image then runs in dev against localhost:5432, in staging against the staging database and in production against the production one, and promoting a release means deploying that image again, not rebuilding it.

Why it matters in production

Most of the factors are now defaults on Kubernetes and other container platforms, and the services that break them are the hard ones to run. Hard-coded config forces a build per environment, local files and in-memory sessions are lost when a pod is rescheduled, and a different database in dev than in prod hides bugs until release. Secrets are config too, but inject them from a secret store, for example with the External Secrets Operator, instead of committing .env files.