Twelve-Factor Apps

The twelve-factor app is a methodology for building software-as-a-service apps. The Twelve Factors are:

  1. Codebase: one code repo per app
  2. Dependencies: declare and isolate. E.g. Ruby uses a Gemfile and Python uses pip and virtualenv
  3. Config: store config in the environment (not in the code) – config varies substantially across deploys, code does not
  4. Backing services: treat as attached resources. Should be able to swap out a local MySQL database for a third party (such as Amazon RDS) without changing the code
  5. Build, release, run: strictly separated stages – i.e. you can’t make changes to code at runtime
  6. Processes: stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service (e.g. a database)
  7. Port binding: export services via port binding. i.e. don’t rely on runtime injection of a webserver to create a web-facing service
  8. Concurrency: twelve-factor app processes are a first class citizen. They should never daemonize or write PID files. Instead use systemdor other tool
  9. Disposability: fast startup, graceful shutdown
  10. Dev/Prod parity: keep development, staging and production as similar as possible. E.g.
    1. time between deploys: hours not weeks
    2. code authors vs code deployers: same people
    3. dev vs production environments: as similar as possible
  11. Logs: treat as event streams. i.e. each running process writes its event stream, unbuffered, to stdout
  12. Admin processes: run admin / management tasks as one-off processes / scripts. E.g. Locally, run admin process in shell command in app’s checkout directory. In Prod, devs can ssh and run in deploy’s execution environment