12-Factor App

In this post, we’d like to share with you the methodology we use when developing applications, specifically the twelve-factor app approach. This set of best practices helps simplify development and makes your application reliable and flexible.

1. Code base. The idea is to keep a single code base in one repository for a single application. The same code base can be used for different environments (prod, staging, etc.).
2. Dependencies. This factor states that the application should never rely on implicitly existing libraries or packages. All dependencies must be declared and isolated.
3. Configuration. The application’s configuration should be stored in environment variables. This allows you to deploy the same codebase to different environments without changing the code.
4. Third-party services. The application should refer to third-party services, such as databases, mail services, queues, etc., which should be configured using environment variables without changing the code itself.
5. Build and run. Strictly separate the build, release, and runtime stages of the application. This enables quick rollbacks to previous versions if needed.
6. Processes. The application should always be stateless and never store its own state. Short-term data storage in cache or on disk is acceptable.
7. Port binding. The application should communicate with the external environment by binding to ports and listening for all requests on that port.
8. Concurrency. Application scaling occurs by horizontally increasing stateless processes, allowing for load distribution and easy scalability.
9. Disposability. This factor includes several important points: the ability to start and stop the application at any time, minimizing startup time, graceful shutdown, and resilience to unexpected terminations.
10. Dev/prod parity. Aim to keep different environments (dev, staging, prod) as similar as possible. Avoid using different services or tools in development and production.
11. Logs. The application should never manage or store logs itself; instead, each process should output logs to standard output (stdout).
12. Admin processes. Projects often have one-time tasks, like database migrations, running REPL scripts, etc. The key point of this factor is that one-time tasks should run as separate processes in the same environment as long-running tasks, using the same codebase, configuration, and deployed with the same release.