The Twelve-Factor App (2025) • Hacker News Board

Re: The Twelve-Factor App (2025)

#141

Post by nunez » Sat, Aug 29, 2026, 6:41 AM UTC

xp84 wrote: post #99

nebezb wrote: post #39

Earlier quoted context omitted.

My issue with the env is it's not a secret store. Dotenv is a delivery mechanism. If you're using it to put APP_BASE_URL or APP_PORT into your env, it's a very convenient one. If you're using dotenv to put SECRET_SIGNING_KEY into your env, it's as poor a delivery mechanism as ~/.bashrc is. Processes and subprocesses inherit your environment. Too much can go wrong. Something as innocent as an error logging library add…

Not a rhetorical question, just curious: Suppose you have all your secrets encrypted with sops. That secret that validates your application's identity, that it needs to use to get or decrypt the secrets, like an AWS keypair or similar, how do you provide that secret to the app?

Via workload identity (Instance Profiles in this case; IRSA with EKS)

Re: The Twelve-Factor App (2025)

#142

Post by nunez » Sat, Aug 29, 2026, 6:44 AM UTC

jchook wrote: post #140

You have to enjoy this article from the perception of its time. For example #1, the idea of a central codebase + many deploys was not always the way folks did things lol. The (2025) date must not be correct…

It's not this came out in 2012 when Heroku was The Way to run SaaS apps

Re: The Twelve-Factor App (2025)

#143

Post by nunez » Sat, Aug 29, 2026, 6:48 AM UTC

dec0dedab0de wrote: post #4

Heroku seemed like it was going to be the future back then. Every time I find myself struggling to understand some nonsense in Azure I dream of the simpler future we lost.

Sucks that it didn't become that. "heroku up" or "cf push" (Heroku kind of sort of invented build packs) was hella addictive.

Shoot, I'm sad that Docker didn't become the way to run containers. compose/swarm is still light years easier than Kubernetes

I guess Heroku ran so that Vercel could fly?

Re: The Twelve-Factor App (2025)

#144

Post by nunez » Sat, Aug 29, 2026, 6:49 AM UTC

sandeepkd wrote: post #31

Its interesting how this felt so natural and right way to do software. I remember people referencing it as the north star. And then gradually people came close to it but moved past it. Personally I feel that these concepts require to have generalist mindset aka application architect. What we have as of today are lot of product engineers within teams, product managers and management. The product engineers do not alway…

Idk I still think it's a great way to ship software

Re: The Twelve-Factor App (2025)

#145

Post by nunez » Sat, Aug 29, 2026, 6:50 AM UTC

_superposition_ wrote: post #8

I can't believe how old this is and I feel like most devs still haven't internalized this which is a shame.

Now they'll never need to now that they have agents

Re: The Twelve-Factor App (2025)

#146

Post by stephbook » Sat, Aug 29, 2026, 7:00 AM UTC

nebezb wrote: post #120

dewey wrote: post #46

Earlier quoted context omitted.

The vault of the cloud provider would just inject the value of the environment variable securely so it doesn't have to be stored on-disk. What the parent poster wrote isn't wrong.

The parent poster is wrongly quoting me to say the original post doesn't mean “env var”. Yes, it does mean env var.

No, they are not stored permanently on disk according to 12f. They are only injected for the lifetime of the application and destroyed when stopped.

It's not okay to store your secret on your own machine disk's .bashrc forever.

It seems we're in agreement anyway.

Re: The Twelve-Factor App (2025)

#147

Post by mcapodici » Sat, Aug 29, 2026, 7:39 AM UTC

I haven't checked the 12 factors for a while but feel proud to have worked on systems probably for a long old while where most or all have applied. To the point I'd naturally do these things without consciously thinking.

I think that says a lot about good practices spreading than anything else. To not do these things: maybe a startup moving fast, or a very isolated company or just some old legacy COBOL type thing where you want the thing to still work as the main concern.

Re: The Twelve-Factor App (2025)

#148

Post by ksbd-pls-finish » Sat, Aug 29, 2026, 8:01 AM UTC

nailer wrote: post #81

HHad3 wrote: post #45

Earlier quoted context omitted.

Unfortunately, with secrets in the OS env, you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident. The env and more importantly what populates it should be secure, but security works best in layers. Sanitizing the env after loading it is a nicer middleground, k8s-style secrets materialized to files work best and are conceptually close enough to the OS env.

> you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident. Game over already if anyone can run commands or arbitrary code. Not using the environment won't help you.

This was about a programmer accidentally adding a debug print, or say an error page helpfully dumping environment, or logs from a third party tool, etc. Not about someone actually getting RCE just to print the environment, of course.

Re: The Twelve-Factor App (2025)

#149

Post by thaumasiotes » Sat, Aug 29, 2026, 8:01 AM UTC

tptacek wrote: post #65

HHad3 wrote: post #45

Earlier quoted context omitted.

Unfortunately, with secrets in the OS env, you‘re one `printenv` or improperly written third party dependency that leaks env vars away from a security incident. The env and more importantly what populates it should be secure, but security works best in layers. Sanitizing the env after loading it is a nicer middleground, k8s-style secrets materialized to files work best and are conceptually close enough to the OS env.

It's not my intuition that materializing secrets to files is a better way to protect them than just injecting them into the environment, where they don't persist.

> It's not my intuition that materializing secrets to files is a better way to protect them than just injecting them into the environment, where they don't persist.

I don't really follow this reasoning. Where are you injecting the secrets from?

Re: The Twelve-Factor App (2025)

#150

Post by thaumasiotes » Sat, Aug 29, 2026, 8:08 AM UTC

grey-area wrote: post #139

jt2190 wrote: post #28

Earlier quoted context omitted.

The unwritten assumption in 12 Factor is: the environment is secure . For example, a production system should always have a secure means of setting environment variables. Said another way: If a random dev can change an environment variable in production either directly by logging in or indirectly by pushing code then there is something very very wrong. If the dev is pushing code to production they should not simultan…

Adding a config setting should never be dangerous (if it is your system is deeply broken) and should be distinct from changing an existing config setting.

> Adding a config setting should never be dangerous (if it is your system is deeply broken)

While I can't name anything specific offhand, I feel pretty strongly that I've seen documentation for various things stating that those things check for an environment variable and, if it isn't present, fall back to other candidate names for the same variable.

This makes setting a new variable synonymous with changing an existing one, unless all variables are currently using the highest-priority possible names.

Another architecture with the same effect is that the software will only check a single environment variable, and if not present it will use a default value. That also makes setting a new variable synonymous with changing an existing one.