The Twelve Factors for Applications

The 12-factor app manifesto (sometimes called as 12-factor app configuration style) is more like a guidance on ideal practices (or principles, if you want) for building softwares delivered as a services. It can be applied to applications written in any programming language.

The 12-factor-app “word” is often used interchangeably with cloud native practices. These practices cover implementing, deploying, monitoring and managing applications, and they can be implemented in any programming language.


One codebase tracked in revision control, many deploys

This statement says that you should have only one repository for your codebase that is accessible to the developers within your organization. You can still use various branches, while having different repositories is not allowed in a 12-factor environment. This one codebase is stored in a revision control system and supports many deployments.

Nowadays, this is mostly handled with the use of GIT.

Best practice is to automate deployment, and some of the popular technologies to achieve this are Gradle and Jenkins.

There is only one codebase per application (but there will be many deployments of the app – a deploy is a running instance of the application). Multiple apps sharing the same code is a violation of twelve-factor!!!


Explicitly declare and isolate dependencies

The second principles of 12-factor app refers to application dependencies. Any dependency you application rely on to run must be managed in such way to avoid conflicts.

A twelve factor app declares all it’s dependencies, completely and exactly, by means of a dependency declaration manifest. For example in maven you have pom.xml while in gradle you have files.


Store config in the environment

An application’s configuration is everything that vary between deploys.

I consider this to be the most important rule. Configuration variables should always be separated from the source code, and never be hardcoded. Instead they should be handled with the use of environment variables, or externalized in properties files. Examples of app configuration variables are:

  • configuration location of a database in preProduction vs. production;
  • credentials to external services.

Following this practice enables the same code to be deployed to different environments, without changes.


Treat backing services as attached resources

A backing service is any service that the application consumes over network as part of its normal operation. The backing services may run on the same machine, or different machines in third-party servers. The following are backing service examples that should be treat as attached resources:

  • databases
  • messaging systems
  • SMTP services
  • LDAP servers


Strictly separate build and run stages

Twelve factor processes must be stateless and share nothing.


Execute the app as one or more stateless processes

This principles says that twelve factor app are stateless and share nothing.


Export services via port binding

An application architected according to twelve-factor-app as a service by binding to a port, and listening to requests coming on that port.


Scale out via the process model


Maximize robustness with fast startup and graceful shutdown

This ninths factor says that a twelve-factor-app’s process can be started or stopped at a moment’s notice.

X. Dev/Prod PARITY

Keep development, staging, and production as similar as possible

You don’t want development and production to get out of sync so that one does not reflect the other, you want them to be reasonably similar! This falls into agile software development, continuous integration and continuous deployment concepts.


Treat logs as event streams

A twelve factor app never concern itself with routing or storage of its output stream. (logs are examples of application output streams collected from the running processes and backing services).


Run admin/management tasks as one-off processes


Spread the love

Leave a Reply