The Twelve-Factor App Methodology - A Rundown

・4 min read
The Twelve-Factor App Methodology - A Rundown

The methodology of twelve-factor app development is used during the process of creation Software as a Service modern cloud applications which minimize divergence and can scale up without significant changes. It is a set of best practices designed to ensure the final product will be easily scalable horizontally. This article aims to provide the main thoughts behind this methodology with a short summary of them.

1. Codebase

A single repo or a set of repos, which are a copy of the tracking database, share a root commit which is decentralized in Git - a version control system. An app based on the twelve-factor methodology has one codebase but many deployments - running instances of the application. This means the app can be running on production, staging and on local development environments.

2. Dependencies

Support libraries (like gems for Ruby or npm for Nodejs) most often have packaging systems, which can be used during the process of installation. Those libraries can later be installed system-wide. In the methodology, the app never relies on the implicit system-wide packages. It declares dependencies through a dependency declaration manifest and uses an isolation tool in order to ensure no implicit dependencies ‘escape’. Those apps also do not rely on the existence of any system tools.

3. Config

In the case of config, the methodology requires separation of the code from config, which varies across deploys, contrary to the code. This can be easily checked through making the codebase an open source, without sacrificing any credentials. What is more, the app developed using this methodology stores config in environment variables, making them easy to modify without changing the code.

4. Backing services

In this development methodology, the app code does not distinguish between local and third-party services. This means that at any time the deploy of the app can swap a local database with a third-party one without introducing any changes to the code. Thanks to that, when experiencing issues, the current production database can be detached and a new one can be attached without code changes.

5. Build, release, run

The twelve-factor app a codebase can be transformed into a deploy in three stages: the build, the release and the run stage. This methodology strictly separates those stages as there is no way to make changes to the code at runtime.

6. Processes

Processes are characterized by the share-nothing architecture and are stateless. The data that is to be persisted must be stored in a database. The applications developed using the discussed methodology never assume that things stored on disk or in memory will be available later on.

7. Port binding

Applications following the twelve-factor rules are self-contained which means they do not rely on runtime injection to create a web-facing service. For example, a HTTP is exported as a service through binding to a port and acknowledging requests coming on the given port. Therefore, port binding should be used to expose and give access directly via a port.

8. Concurrency

The methodology states that the processes are a first class citizen. Thanks to that, developers can assign various types of work to process types. The nature of the apps developed is that they are scaled horizontally, not vertically. This means that adding more concurrency is easy to perform.

9. Disposability

The processes are disposable, which means that they can be stopped or started at any given time. Thanks to this, the application ensures fast and elastic scaling as well as rapid deployment or changes in configuration. On the other hand, shutdowns should be graceful in order to maximize robustness.

10. Dev-Prod parity

The gap between production and deployment is what ensures a continuous deployment of the twelve-factor applications. The production, staging and development environments should be as similar as possible. Using the same backing services ensures complete compatibility.

11. Logs

Logs should be treated as event streams and should not be dealing with storing of the app’s output stream or its routing. The application should not write or manage logfiles.

12. Admin processes

The one-off admin processes, as well as the long-running processes of the application, should be run in the same environment. They use the same config and codebase.


The twelve-factor app development methodology is a great set of best practices to follow in order to create a product that can be easily scaled horizontally. Following this approach ensures that the application can be delivered as a service, will be reliable, speedy and portable. What is more, the twelve-factor applications can be written in any language.