Factor I–IV: Code, dependencies, config, and backing services

• I. Codebase — one codebase, many deploys — One repo per app. Multiple environments (staging, prod) are just deploys of the same code. BAD: different code branches per environment. GOOD: feature flags or env vars distinguish behaviors.
• II. Dependencies — explicitly declare and isolate all dependencies — Never rely on system-wide packages. BAD: pip install not in requirements.txt. GOOD: requirements.txt, package.json, go.mod, Gemfile — versioned, checked in.
• III. Config — store config in the environment — Anything that varies between deploys belongs in env vars, not code. BAD: const DB_URL = "postgres://prod-db.company.com" in source code. GOOD: process.env.DATABASE_URL. This is also why you never commit .env files.
• IV. Backing services — treat them as attached resources — Databases, caches, queues — they are all "attached resources" accessed via a URL or credential in config. Swap a local MySQL for an RDS instance by changing one env var. Zero code change.

Factor V–VIII: Build, process, port, and concurrency

• V. Build, release, run — strictly separate build and run stages — Build: compile, bundle. Release: build artifact + config = immutable release. Run: execute. BAD: editing code on a running server (ssh into prod, vim app.py). GOOD: CI/CD pipeline creates immutable Docker images tagged by commit SHA.
• VI. Processes — execute app as one or more stateless processes — Processes are stateless and share nothing. Any state (sessions, data) is stored in a backing service (Redis, DB). BAD: storing user sessions in memory. GOOD: JWT tokens or Redis-backed sessions.
• VII. Port binding — export services via port binding — The app is self-contained and exposes HTTP by binding to a port. No external web server required to run. BAD: app only runs inside Apache with mod_wsgi. GOOD: app.listen(process.env.PORT).
• VIII. Concurrency — scale out via the process model — Scale horizontally by running more processes, not by making one process bigger. BAD: increasing JVM heap endlessly. GOOD: run 10 instances of the same process behind a load balancer.

Factor IX–XII: Disposability, dev/prod parity, logs, and admin

• IX. Disposability — maximize robustness with fast startup and graceful shutdown — Processes start fast and shut down gracefully. BAD: apps that take 5 minutes to start, lose jobs mid-flight on shutdown. GOOD: sub-second startup, SIGTERM handler that drains the queue before exiting.
• X. Dev/prod parity — keep development, staging, and production as similar as possible — BAD: dev uses SQLite, prod uses PostgreSQL (breaks when you need JSONB). GOOD: Docker Compose in dev uses the exact same Postgres version as production.
• XI. Logs — treat logs as event streams — The app writes to stdout. The platform aggregates, routes, and archives. BAD: logger.setFile("/var/log/app.log") — log rotation, disk management = your problem. GOOD: console.log(JSON.stringify({level:"info", msg:...})) → shipped to Datadog by the platform.
• XII. Admin processes — run admin/management tasks as one-off processes — Database migrations, data backups, REPL sessions — run them as one-off commands, not baked into startup. BAD: app runs db.migrate() every time it starts. GOOD: kubectl exec a migration job before rolling out the new version.

Violated factors and their fixes

• Factor VI broken — Sessions in memory → migrated to Redis (Factor IV: backing service). Now they could run 20 instances.
• Factor III broken — DB URL in source code → moved to env vars. Bonus: staging no longer accidentally pointed to prod.
• Factor XI broken — Logs on local disk → stdout to CloudWatch. Now they could actually debug the outage from logs.
• Factor IX broken — Slow startup (45 seconds) → profiled and reduced to 2 seconds. Auto-scaling now actually helped.