Live data from Hacker News

The Twelve-Factor App (2025)

12factor.net

101–110 of 184 posts

Re: The Twelve-Factor App (2025)

#101

I really thought this would be a 12 layer MFA demo showing the absurdity of our current painful & unsustainable MFA trends.

Every time I leave my phone in the other room to “finally get some work done”, please enter this goddamn number we sent to your SMS, and I close my laptop.

The worst part is: why are they sending me an SMS when I never agreed to it and didn’t configured that as an MFA option?

Re: The Twelve-Factor App (2025)

#103
I'm debating the tradeoff for secret management in my app as well. Storing it is easy you just need encryption and it's mostly good. But delivering it is tricky. Delivery via env is simple for sure but can get leaked. The other route would be a job scoped signature, but this doesnt stop the job from printing the secret out, it only shrinks the blast radius.

But if you delete the secret after the job is done or deployment is up, it's pretty much the same result

Re: The Twelve-Factor App (2025)

#104
Storing config in environment variables is just such an incredibly obviously awful thing to do I can't recommend that anyone listens to this advice. Maybe some of the other things are good practice... honestly I don't remember... but once I saw that I immediately noped out.

Would you get advice from an antivaxxer? Like, maybe they do have good advice but it's still a good idea to get your advice elsewhere!

Re: The Twelve-Factor App (2025)

#105

I'm not sure where the (2025) in the title comes from, but this has been around much longer than that.

+1. I saw the 2025 suffix and fact that it was on the original domain and hoped they released a v2 to carry us through the world of Platform Engineering, Observability 2.0, Kubernetes vs Serverless, etc.

Re: The Twelve-Factor App (2025)

#107
post #82
post #75

Earlier quoted context omitted.

Dev/shm is used to materialize them, and then you have the ability to isolate the downstream code you might use from accessing it by dropping permissions or sandboxing it away from a file. You cannot really hide your environment from anything in process, since it's such a low level construct. Thus it's easier to leak environment unintentionally, leaking file contents takes effort.

Not at all clear why this is a better setup than a launcher shim that pulls secrets from a secret store and injects them into the environment as the program launches --- which is a pretty normal shape for these things to take. I guess you could be thinking "subprocess inheritance" as a downside? But subprocesses often need secrets, and if you arrange for that with the filesystem you have the same problem. And, of cou…

Have you seen this where eBPF patches secrets inside TLS send buffers? https://github.com/spinningfactory/kloak

Now you have to be much more clever to leak them :)

Re: The Twelve-Factor App (2025)

#110
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…

> Changing application behavior Configuration changes also change application behavior, otherwise is it really “config”?

> Note that this definition of “config” does not include internal application config, such as config/routes.rb in Rails, or how code modules are connected in Spring. This type of config does not vary between deploys, and so is best done in the code.
Post reply on HN