The document outlines the twelve-factor app methodology for building software-as-a-service apps. It discusses factors such as using one codebase per app, declaring and isolating dependencies, storing configs in environment variables, treating backing services as attached resources, writing logs to stdout, separating build and run stages, keeping development and production in parity, running processes using a stateless architecture, binding to ports, following the UNIX process model, and designing for robustness and disposability. The goals are to enable automation, a clean contract, deployment scalability with minimal changes, and minimizing divergence across environments.

1. Simon Vocella
The Twelve-Factor App

2. Simon Vocella
The application

3. Simon Vocella
I. Codebase
One codebase per app

4. Simon Vocella
II. Dependencies
Never relies on implicit existence of system-wide
packages

5. Simon Vocella
III. Config
Store config in environment variables

6. Simon Vocella
IV. Backing Services
The code should not make no distinction between local
and third party services.

7. Simon Vocella
XI. Logs
• Logs are the stream of aggregated, time-ordered
events collected from the output streams of all
running process and backing services
• An app never routes or storage its output stream. It
will always write every event to the stdout

8. Simon Vocella
V. Build, release, run
• The build stage is a transform which converts a
code repo into an executable bundle known as a
build.
• The release stage takes the build produced by the
build stage and combines it with the deploy’s
current config.
• The run stage runs the app in the execution
environment, by launching some set of the app’s
processes against a selected release.

9. Simon Vocella
X. Dev/prod parity
App is designed for continuous deployment by keeping
the gap between development and production small

10. Simon Vocella
The process
One codebase per app

11. Simon Vocella
VI. Processes
• Execute the app as one or more stateless
processes
• Shared nothing architecture
• Stateful data must be stored in a stateful backing
service (e.g. database).

12. Simon Vocella
VII. Port Binding
The app is completely self-contained and does not rely
on runtime injection of a webserver into the execution
environment to create a web-facing service.
e.g. the web app exports HTTP as a service by binding
to a port, and listening to requests coming in on that port.

13. Simon Vocella
VIII. Unix Process
Model (ex Concurrency)
Using this model, the developer can architect their app
to handle diverse workloads by assigning each type of
work to a process type.
The app should never daemonize or write PID files.

14. Simon Vocella
IX. Disposability
Maximize robustness with fast startup and graceful shutdown:
All jobs are reetrant
All the operations are idempotent
Process should be robust against crash

15. Simon Vocella
XII. Admin Processes
• Developers will often wish to do one-off
administrative or maintenance tasks for the app,
such as:
• Running database migrations
• Running a console to run arbitrary code
• Running one-time scripts committed into the
app’s repo

16. Simon Vocella
What we achieve:
• Setup automation
• Clean contract
• Suitable for deployment
• Minimize divergence between different
environments
• Can scale up without significant changes

17. Simon Vocella
Bibliography
• The Twelve-Factor App site - http://12factor.net/
• Shared nothing architecture - http://en.wikipedia.org/wiki/
Shared_nothing_architecture
• Sticky session - http://en.wikipedia.org/wiki/Load_balancing_
%28computing%29#Persistence
• Running processes - http://dustin.sallings.org/2010/02/28/running-
processes.html
• Applying the Unix Process Model to Web Apps - http://
adam.herokuapp.com/past/2011/5/9/
applying_the_unix_process_model_to_web_apps/
• Crash-only design - http://lwn.net/Articles/191059/

18. Simon Vocella
Thank you.
Questions?