HN Debrief

The Twelve-Factor App (2025)

  • Programming
  • Infrastructure
  • Security
  • Developer Tools
  • Cloud

The post is the original Twelve-Factor App site, a short guide from the Heroku era that laid out twelve principles for building SaaS applications. It pushed ideas that are now normal in cloud software, like strict separation of config from code, disposable processes, attached backing services, and apps that bind their own ports instead of depending on heavyweight shared web containers. That is why a lot of the text now reads as obvious. It won because it described a cleaner operating model than the Tomcat, WebSphere, mod_php, shared-DB, hand-managed-server world it was reacting to.

If you run product or platform teams, treat 12-factor as a baseline architecture checklist, not a complete modern operating model. Keep the deployment and service-boundary ideas, but revisit secret delivery, stateful systems, and platform-specific tradeoffs instead of copying the document literally.

Discussion mood

Warm and nostalgic, with a strong sense that the guide was formative and is still worth reading. The biggest frustration was aimed at the environment-variable config rule, which many now see as outdated for secret handling and awkward for modern structured configuration.

Key insights

  1. 01

    Why the obvious parts mattered

    The now-boring bits were a direct break from an older deployment model where apps lived inside Tomcat or WebSphere, PHP ran as a webserver module, and databases or mailers were tightly coupled to hosts and ops teams. Seeing port binding and attached backing services as explicit rules helped normalize self-contained services, horizontal scaling, and local environments that looked more like production.

    If younger engineers think parts of 12-factor are trivial, use that as proof that the ideas won. The useful move is to teach the historical failure mode, because that makes it easier to spot modern versions of the same coupling.

      Attribution:
    • ipsi #1
    • jaggederest #1
    • dec0dedab0de #1
    • anon7000 #1
  2. 02

    Environment config breaks down with structure and scope

    Even if you ignore secret leakage, environment variables are a bad fit for large or nested configuration. They have size limits, flatten everything into key-value strings, and encourage ugly encodings for structured data. More importantly, they make every secret available to the whole process even when most requests or code paths never need it, which widens the blast radius of partial read bugs and routine introspection.

    Use env vars for small, low-sensitivity toggles and wiring, not as your universal config substrate. When config gets structured or secrets are only needed by narrow code paths, move to mounted data, sidecars, or service APIs with tighter access patterns.

      Attribution:
    • zbentley #1 #2
  3. 03

    Modern secret handling shifts to identity and retrieval

    The cleaner pattern is to stop treating secret delivery as a static startup concern. Several comments converge on workload identity plus a vault, or a local secret cache API authenticated with IAM, so the app proves who it is and fetches what it needs when it needs it. That also fits the new threat model where coding agents or untrusted dependencies make "everything in the VM can read everything" a much weaker assumption.

    If your apps still start by slurping every credential into process state, you have an easy platform upgrade to make. Add identity-based access first, then narrow which secrets are fetched, when, and by which component.

      Attribution:
    • nebezb #1
    • patmorgan23 #1
    • skybrian #1
    • nightbrawler #1
  4. 04

    The model is weakest around data and state

    Twelve-factor is strongest when your service is mostly stateless compute wrapped around external services. It gets thin once state itself is the product concern, or when staging, production, and data environments cannot be kept neatly parallel. The example of teams using staging as a pseudo-production data workflow shows the gap plainly. Operational reality often lives in data migration, release flow, and state ownership, not just app packaging.

    Do not expect 12-factor alone to give you a release model for data-heavy products. Pair it with explicit practices for schema changes, data promotion, and stateful service operations.

      Attribution:
    • imglorp #1
    • echrisinger #1
    • nkmnz #1
  5. 05

    Teams miss it because incentives miss it

    The reason many shops still violate these rules is not that engineers have never heard the ideas. It is that delivery pressure rewards shipping features in days, while 12-factor discipline pays off later and is much harder to retrofit once tech debt hardens. That matches the observation that many new engineers have never been taught the framework in the first place.

    If you want these principles to stick, bake them into templates, platform defaults, and architecture review, not inspirational docs. Once an app starts life outside these constraints, recovering later is expensive and politically hard.

      Attribution:
    • commandlinefan #1
    • duderific #1
    • mocamoca #1

Against the grain

  1. 01

    Secret-in-env risk is often overstated

    There is a credible pushback that putting secrets in the environment is not automatically reckless. If an attacker can already run code, inspect arbitrary process memory, or execute commands, avoiding env vars does not save you. In many real systems, the normal pattern is still to keep secrets in a proper store and inject them into the environment at launch, because it is simple and usually good enough. The fancier in-memory encryption and sidecar schemes can turn into security theater with poor ROI.

    Do not rip out environment-based secret injection just to feel modern. Start by checking whether your actual failure mode is debug logging, subprocess inheritance, or broad credential scope, then fix that specific leak path.

      Attribution:
    • tptacek #1 #2
    • nailer #1
  2. 02

    Files are not obviously safer than env

    Mounting secrets as files sounds safer, but that claim got challenged hard. Files leak too, and if child processes need the secret you still have a propagation problem. The real gain only appears if you use a more constrained delivery path like tmpfs, stdin, inherited file descriptors, or tighter sandboxing around which code can read the materialized secret.

    If you switch from env vars to files, be clear what security property you are buying. A plain file mount is often just a different container for the same exposure.

      Attribution:
    • tptacek #1
    • abofh #1
    • crote #1
    • NewJazz #1

In plain english

DB ↩
Database, a system used to store and query application data.
IAM ↩
Identity and Access Management, AWS's system for defining users, roles, and permissions.
Kubernetes ↩
An open source system for deploying and managing containerized applications across clusters of machines.
mod_php ↩
A way of running PHP as a module inside the Apache web server rather than as a separate service.
SaaS ↩
Software as a Service, software delivered over the internet and typically accessed through a browser.
serverless ↩
A cloud model where the provider runs code and manages infrastructure automatically, often charging only for actual usage.
sidecar ↩
A helper process or container that runs next to an application and provides supporting capabilities such as proxying or secret access.
stdin ↩
Standard input, the default input stream a program can read from when it starts.
tmpfs ↩
A temporary in-memory filesystem whose contents live in RAM rather than on persistent disk.
Tomcat ↩
Apache Tomcat, a Java web application server commonly used to run Java web apps.
vault ↩
A dedicated system for storing, controlling, and auditing access to secrets like passwords, tokens, and keys.
WebSphere ↩
IBM WebSphere, an enterprise application server used to host Java applications.
workload identity ↩
A way for a running service or job to prove its identity to other systems without embedding long-lived secrets in the app.

Reference links

Secret management tools and approaches

  • sops
    Named as a preferred tool for keeping secrets encrypted and out of environment variables.
  • kloak
    Shared as an example of an eBPF-based approach to patch secrets into TLS buffers to reduce leak exposure.
  • Stop Storing Secrets in Environment Variables
    Referenced as an argument for ephemeral filesystem mounts instead of environment variables for secret delivery.
  • exe.dev integrations
    Pointed to as an example of using external proxies that hold secrets rather than putting them on the same VM as coding agents.

Primary source and related project links

Background and prior discussions