The 12-Factor Apps Methodology: Implement It in Your Own Apps with AppFog

Share this article

This article was sponsored by AppFog. Thank you for supporting the sponsors who make SitePoint possible.
In today’s world of SaaS products, a common methodology has emerged with the purpose of providing an outline for building well structured and scalable applications. It’s called the “12-Factor App” methodology, and it’s about to change the way you approach the architecture of your next app. If you’ve had a lot of experience deploying applications, then you may be well aware that the deployment process can be complicated and extensive to say the least. Virtualization, networking, and setting up runtime environments are just a few of the headaches involved. The 12-Factor App methodology doesn’t eliminate the complexity altogether, but it does create a framework for organizing the process in order to maintain a healthy and scaleable application. But how should these difficult architecture necessities be handled, in such a way that each of the 12-Factor App principles can be met? The following paragraphs explain how you can meet the standards of the 12-Factor App methodology, while easily overcoming the difficult realities involved in your application infrastructure and deployment setup. A key tool in this process is AppFog, a Platform-as-a-Service product offered by CenturyLink Cloud to allow application developers to build software without having to focus on infrastructure.

The 12 Factors

As made apparent by the title, the 12-Factor App methodology is a list of principles, each explaining the ideal way to handle a subset of your application. The 12 factors are as follows:

1. Codebase – One codebase tracked in revision control, many deploys

The first principle of the 12-Factor App methodology is related to your application’s codebase. The most important point here is to ensure that your application is tracked with revision control, and that it sits in a central repository that is accessible to your developers. This is most commonly handled by using Git or SVN to store your code.

2. Dependencies – Explicitly declare and isolate dependencies

There is no room for assumptions when it comes to dependencies. Anything your applications rely on to run should be controlled and managed to minimize — if not completely eliminate — conflicts.

3. Configuration – Store config in the environment

Configuration, as it relates to API keys, services, and database credentials, should never be hardcoded. This prevents your application from being at risk from both production data leaks and production errors. Instead of hardcoding this information, rely on environment variables to handle this sensitive information.

4. Backing Services – Treat backing services as attached resources

A backing service is one that requires a network connection to run. This is a very popular paradigm found in modern application development, especially prevalent with the rise in popularity of microservice architecture. The 12-Factor App methodology advises developers to treat these services agnostically, meaning changes or modifications should occur without having to make any code changes. Typically, this factor is best handled by calling each backing service through an API, with credentials stored in a configuration file that lives in your runtime environment.

5. Build, release, run – Strictly separate build and run stages

Build, release, and run stages should be treated as completely distinct from one another. Automation and tooling will help to make this principle simpler. This can be accomplished by using existing tools to fully automate your build process. A tool like Github can be used to tag your latest build, while Jenkins can be used to automate your release stage.

6. Processes – Execute the app as one or more stateless processes

Stateless applications are designed to degrade gracefully. That means if a dependency fails, the app itself does not become a failure. Single points of failure may be difficult, but not impossible, to avoid. The 12-Factor App methodology recommends storing data outside of running code in order to prevent operational headaches and debugging nightmares.

7. Port binding – Export services via port binding

All application services should be accessible via a URL. For web applications, this process happens automatically. This enables 12-Factor Apps to be fully self-contained, avoiding the need to rely on various methods of runtime injection in order to create web facing services.

8. Concurrency – Scale out via the process model

Every process inside your application should be treated as a first-class citizen. That means that each process should be able to scale, restart, or clone itself when needed. This approach will improve the sustainability and scalability of your application as a whole.

9. Disposability – Maximize robustness with fast startup and graceful shutdown

As noted in the previous factor, treating processes as first-class citizens translates to an easier startup and shutdown process. Compare this to an application where all process are bundled together, where startup and shutdown processes can take up to several minutes depending on their size. To ensure your startup and shutdown processes remain seamless, reach for tried and true services that are optimized for speed and performance. Databases and caches like RabbitMQ, Redis, Memcached, and CenturyLink’s own Orchestrate are just a few services that are built to help with this factor.

10. Dev/prod Parity – Keep development, staging, and production as similar as possible

Consistency is key for meeting this factor. When your environments are similar, testing and developing gets much simpler. Similar environments means ensuring that areas such as your infrastructure stack, config management processes, software and runtime versions and deployment tools are the same everywhere. With this approach, fewer bugs will find their way into your production environment, since your test cases can be applied on production-level data.

11. Logs – Treat logs as event streams

Logging is important for debugging and checking up on the general health of your application. At the same time, your application shouldn’t concern itself with the storage of this information. Instead, these logs should be treated as a continuous stream that is captured and stored by a separate service.

12. Admin processes – Run admin/management tasks as one-off processes

One-off admin processes are essentially data collection jobs that are used to gather key information about your application. This information will be needed to asses the state of your production environment, so it’s important to ensure these one-off processes occur in your production environment. That way there can be no discrepancies between the data you need and the data coming from the visible long running production application. On the 12-Factor App methodology site, each of these factors links to a section where an in-depth topic overview is available. While it’s impressive to see how well thought out the 12-Factor methodology is, there’s little information regarding how exactly one might best go about setting up an infrastructure that can best handle such rigorous requirements. But there is a way to do this efficiently with a tool built with the 12-Factor App methodology in mind: AppFog

AppFog, Apps, and You

AppFog is a PaaS designed to provide you with the tools you need to satisfy the 12-Factor App methodology. AppFog manages network resources, middleware, operating systems, virtualization, servers, storage, and the runtime. All you need to do is focus on writing your code. Offered by CenturyLink Cloud, AppFog relies on the versatile open source Cloud Foundry platform. Getting started with AppFog is as simple as signing into your CenturyLink Control Panel and enabling the AppFog service by adding a region that defines where your code will be hosted. From there, you can deploy your application to AppFog using the Cloud Foundry CLI. Cloud Foundry then manages your applications’ runtime, middleware, and O/S environments. Additionally, tasks like load balancing, application runtimes, and streaming app logging are abstracted away from the development process and handled entirely by the cloud infrastructure that Cloud Foundry provides. That is the entire process. Once your application has been deployed to AppFog, all of your infrastructure headaches are over. You’re now free to focus on the application’s codebase.

Tying AppFog into the 12-Factor App Methodology

Your Codebase, Dependencies, Configuration, and Backing Services are 12-Factor principles related to your application and its data. This means they are best managed by you, the developer. Almost everything else about your app can be handled through AppFog, since AppFog has been built with the 12-Factor Application methodology in mind. For example, Concurrency, Disposability and Logging are all managed by AppFog automatically, once you’ve deployed your codebase. In fact, AppFog manages all hardware, software patching, updates, the physical and software security, and any day-to-day, routine operational tasks. While some of the 12-Factor App principles may require a small amount of thought and configuration to set up, the majority are handled seamlessly when you deploy your application to AppFog. Not only does AppFog make this process a lot easier, the team offers plenty of documentation and support for any questions you might have. You can find all of the relevant documentation on CenturyLink’s Knowledge Base. Building 12-Factor applications can be a challenging process, but AppFog has done the majority of the hard work for you. All that’s left for you to do is write your code and deploy. For additional resources on the 12-Factor App Methodology and how AppFog makes it easier, be sure to review AppFog’s in-depth explanation.


The 12-Factor App Methodology is an exceptional blueprint that provides every necessary step to deploying a reliable SaaS product. While managing all of those steps (and choosing the correct services that do so) can be overwhelming, AppFog PaaS makes the process smoother, taking care of aspects of your app like Concurrency and Disposability so you can focus on writing good code that offers something special to your users. Wouldn’t you rather focus on building your app and delivering “delight” to your clients, and let AppFog take care of the rest?

Frequently Asked Questions about 12-Factor Apps Methodology

What is the 12-Factor App methodology?

The 12-Factor App methodology is a set of best practices designed to enable the development of scalable, maintainable, and portable software-as-a-service (SaaS) applications. It was created by engineers at Heroku, a cloud platform as a service (PaaS) provider. The methodology provides a structured approach to building apps that are easy to manage, can scale up without significant changes to tooling, architecture, or development practices, and are portable between execution environments.

Why should I use the 12-Factor App methodology?

The 12-Factor App methodology provides a number of benefits. It promotes the development of software that is declarative, meaning it minimizes time and cost for new developers joining the project. It also ensures a clean contract with the underlying operating system, offering maximum portability between execution environments. Furthermore, it is suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration.

What are the 12 factors in the 12-Factor App methodology?

The 12 factors in the 12-Factor App methodology are: Codebase, Dependencies, Config, Backing Services, Build, Release, Run, Processes, Port Binding, Concurrency, Disposability, Dev/Prod Parity, Logs, and Admin Processes. Each factor represents a specific aspect of app development and deployment that should be considered to ensure the app is scalable, maintainable, and portable.

How does the 12-Factor App methodology handle dependencies?

In the 12-Factor App methodology, dependencies are explicitly declared and isolated. This means that no implicit reliance on system-wide packages is allowed. Instead, the app should declare all dependencies, completely and exactly, via a dependency declaration manifest. Furthermore, the app should also use a dependency isolation tool during execution to ensure that no implicit dependencies “leak in” from the surrounding system.

How does the 12-Factor App methodology manage configuration?

The 12-Factor App methodology treats configuration as a separate entity from the code. Configuration that varies between deployments should be stored in the environment and not in the codebase. This separation of concerns ensures that the app is portable across different deployment environments.

What is the role of backing services in the 12-Factor App methodology?

In the 12-Factor App methodology, backing services are treated as attached resources. This means that a backing service, such as a database, is accessed via a URL or other locator stored in the configuration. The app makes no distinction between local and third-party services, allowing for flexibility and portability.

How does the 12-Factor App methodology handle build, release, and run stages?

The 12-Factor App methodology strictly separates the build, release, and run stages. The build stage involves transforming code into an executable bundle, the release stage combines the build with the deployment’s current config, and the run stage (also known as runtime) runs the app in the execution environment.

What is the significance of processes in the 12-Factor App methodology?

The 12-Factor App methodology treats apps as one or more stateless processes. Any data that needs to persist must be stored in a stateful backing service, typically a database. This approach ensures that the app is share-nothing, meaning each process is self-contained and shares nothing with other processes.

How does the 12-Factor App methodology handle logging?

In the 12-Factor App methodology, logs are treated as event streams. Instead of managing log files, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior.

What are admin processes in the 12-Factor App methodology?

Admin processes are one-off tasks in the 12-Factor App methodology. They should be run in an identical environment as the regular long-running processes of the app. They run against a release, using the same codebase and config as any process run against that release. Examples include database migrations, console sessions, and temporary scripts run in the app’s environment.

Tim EvkoTim Evko
View Author

Tim Evko is a front end web developer from New York, with a passion for responsive web development, Sass, and JavaScript. He lives on coffee, CodePen demos and flannel shirts.

Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week
Loading form