1. Codebase

Apps should be tracked in a revision control system and have a copy of the tracking database stored as a code repository. With this repository, you have your codebase, and there should be just one of these controlling all instances and deploys of the app.

2. Dependencies

Ideally, your app can run independently of other services, even if the underlying operating system fails. To accomplish this, all your dependencies should be declared exactly in your manifest. Also, using a dependency isolation tool keeps external, implicit dependencies from “leaking in”. Declare all dependencies to move servers, architectures, and versions without breaking your application.

3. Config

Configuration is everything that varies between deploys, like code to be executed, external dependencies, and any files uploaded to the server. Use environment variables for storing and managing config. These will be easy for you to change between deploys without accidentally getting checked into your code repository.

4. Backing Services

Backing services are essential components for every app. These are additional tools your app needs to run smoothly. These can be local or third-party, but the app shouldn’t distinguish between the two. Both should be accessible via URLs or stored credentials, and be interchangeable with no code changes.

5. Build, Release, Run

Transform your codebase into a deploy over three stages. Build: Transform code into an executable build, compiling binaries and assets. Release: combine the build with the current deploy’s config. Run: launch the app in an execution environment with a specific set of processes. Strictly separate these stages; don’t revert back to the build for code changes if you’re already in the run stage.

6. Processes

Your app should be executed as one or more processes. These processes must be unique and stateless. Any persisting data should be stored in a stateful database. This lets you add or remove processes with ease, allowing you to easily scale your app.

7. Port Binding

Using port binding allows your app to be self-contained. This way, it’s able to listen to requests coming in and create web-facing services by responding to them with HTTP or other server software like XMPP or Redis. Set up a local development environment and access what you’re exporting through a service URL. When you deploy to production, route incoming requests through the app server.

8. Concurrency

Processes shouldn’t be confined to the same system facilities as code running in production. Instead, design them to handle a wide variety of workloads by splitting them into different kinds. These process types running concurrently lets your app handle diverse workloads, and makes it easy to scale out.

9. Disposability

For your app to be ready to quickly scale and adopt code/config changes as needed, you’ll need your processes to be disposable. Disposable processes can start and stop at a moment’s notice. To achieve this, your processes need fast start-up times and graceful shutdowns.

10. Dev/Prod Parity

Between your app’s development and production, you’ll experience three gaps. There’s a time gap before release, a personnel gap between your development and ops engineers, and a tools gap between both teams. The goal is to make these as small as possible. Try to reduce time between code deploys as much as possible, keep your developers involved in the production side and vice-versa, and keep the teams’ tools as similar as possible.

11. Logs

Logs are a time-ordered record of events generated by an application. They help you keep track of what your app is doing and how long things take. Your app’s logs should output as each process’s event stream. Each stream can be accessed by developers in their terminals, and will be aggregated, archived, and managed by the execution environment.

12. Admin Processes

Outside of an app’s regular process formation, one-off administrative or maintenance processes may need to be run. It’s important that these are run in the same environment as the regularly-running processes, against a release, with the same codebase and config as any other process run against the same release.