The twelve-factor app as a checklist for services

What it is

The twelve-factor methodology lists twelve conventions: codebase, dependencies, config, backing services, build/release/run, processes, port binding, concurrency, disposability, dev/prod parity, logs and admin processes. Each factor is a short rule about how a service is built, configured and run so that it can be deployed on modern platforms without special cases.

Why it matters

Most of the factors remove hidden coupling: to a specific machine (config in the environment, port binding), to a specific deployment order (stateless processes, disposability), or to a specific developer laptop (declared dependencies, dev/prod parity). Services that follow them can be scaled, restarted and moved with fewer surprises.

How to apply

Use the list as a review checklist for a service rather than as dogma:

• Can a fresh checkout be built with declared dependencies only?
• Does every environment-specific value come from the environment, with no secrets in the repository?
• Would the service survive being killed and restarted at any moment?
• Are logs written to standard output as an event stream and collected elsewhere?
• Are one-off administrative tasks run with the same code and configuration as the service?

Pitfalls

The factors were written for hosted web applications; batch jobs, desktop software and embedded systems need translation. "Config in the environment" does not mean that every knob must be an environment variable; it means no environment-specific values in the code. Stateless processes still need durable state somewhere, handled as a backing service.