What is the twelve-factor app methodology's relevance to containerized applications?
Quick Answer
The twelve-factor app methodology is a set of principles for building software-as-a-service applications that are portable, scalable, and consistent across environments — and it maps almost perfectly onto how containers are meant to be used: strict separation of config from code (see that question), treating backing services as attached resources, logging to stdout rather than managing log files internally, and explicit process isolation. Understanding these principles explains why several Docker best practices (log to stdout, never bake config into the image, keep containers stateless/disposable) are considered best practices in the first place, rather than being arbitrary conventions.
Detailed Answer
Why a pre-container methodology maps so well onto containers
The twelve-factor app methodology was originally written (by engineers at Heroku, around 2011) describing principles for building cloud-native SaaS applications. It predates Docker's mainstream adoption, but it describes exactly the properties that make an application a good fit for the containerized, orchestrated deployment model that later became standard. Several of its factors directly explain why specific Docker/Kubernetes conventions exist, rather than those conventions being arbitrary.
Factor III: Config — strictly separate from code
Covered in depth in the earlier environment-configuration question: configuration that varies by deployment (database URLs, feature flags, credentials) belongs in the environment, never hardcoded into the build artifact. This is precisely why Docker images should be built once and configured at runtime via environment variables or mounted files (see that question). It is also exactly why Kubernetes ConfigMaps/Secrets and Compose's environment mechanisms exist as first-class concepts.
Factor VI: Processes — stateless and share-nothing
An application should treat any locally-stored state as disposable. This directly explains why a container's own writable layer is treated as ephemeral scratch space (see the storage topic). It also explains why genuinely persistent data must live in an external store (a database, a mounted volume, or an external service), rather than being assumed to survive within the container's own filesystem indefinitely.
Factor XI: Logs — treat logs as event streams, write to stdout
console.log('Request received', { path: req.path }); // stdout -- NOT writing to a local log file
The twelve-factor principle is that an application shouldn't manage its own log file rotation, storage, or routing at all. It should simply write a continuous stream of events to stdout, and let the execution environment decide what to do with that stream. This is exactly why Docker's log-capturing mechanism (see the lifecycle and production topics) is built around capturing stdout/stderr specifically. An application that instead insists on writing to its own internal log files requires extra plumbing (a sidecar, a shared volume) just to get its logs captured. This fights against the principle rather than working with it.
Factor IX: Disposability — fast startup and graceful shutdown
An application should start up quickly and shut down gracefully, handling SIGTERM properly to finish in-flight work before exiting. This directly explains the emphasis, covered in the lifecycle topic, on using exec-form CMD/ENTRYPOINT (so signals reach the application process directly) and on applications handling SIGTERM correctly. Orchestrators (Docker's own --restart, Kubernetes's rolling updates and scaling) constantly start and stop container instances as a normal, routine part of operation, not an exceptional event.
Factor V: Build, release, run — strict separation of stages
The methodology insists on a strict separation between building an artifact, combining it with environment-specific configuration to create a "release," and actually running that release. This is precisely the "build once, deploy the same artifact everywhere, configure at runtime" pattern covered in the environment-configuration question. It is also precisely why baking environment-specific values into a build is considered an anti-pattern, rather than just a style preference.
Why this matters for an interview beyond just naming the factors
Being able to connect a specific twelve-factor principle to a specific Docker/container best practice demonstrates that you understand why these practices are recommended, not just that they are. For example: Factor XI maps to logging to stdout rather than files; Factor III maps to runtime config injection rather than baked-in values; Factor IX maps to exec-form CMD and proper SIGTERM handling. This is a meaningfully stronger signal than simply reciting "you should log to stdout" as an isolated rule, without the underlying reasoning that connects it to the broader goal of building applications that genuinely fit the containerized, orchestrated deployment model. It is also a genuinely useful checklist when containerizing an existing, previously non-containerized application. Writing to local log files, or expecting config baked into the install directory, are exactly the kinds of assumptions that need real adaptation work — not just a Dockerfile wrapped around them.