Live data from Hacker News

The Twelve-Factor App (2025)

12factor.net

61–70 of 184 posts

Re: The Twelve-Factor App (2025)

#61
post #48

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.

Give Cloud Run a try if you haven't. It's basically serverless done right.

Azure Container Apps is very similar to Cloud Run if you can't use GCP

Re: The Twelve-Factor App (2025)

#62
> X. Dev/prod parity > Keep development, staging, and production as similar as possible

Gets interesting at the seams of software & data environments. If my preprod stack operates independently of my prod stack (due to different internal users), but preprod data stack is best tested on prod data, the seams of these two things imply there should be a separate data stack for both preprod data versus preprod-internal.

Generally pro 12-FA, but it's very service dev oriented.

Re: The Twelve-Factor App (2025)

#63

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

Okay so this may sound odd but this is literally my whole life right now... Can you explain why do you feel MFA is painful/unsustainable? How would you fix it?

[deleted]

Re: The Twelve-Factor App (2025)

#64
post #60
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…

The assumption is the vector. Why assume?

It's more accurate to describe it as a "premise", not an assumption. It may not be true of every environment, but it's a very common norm (for instance, secrets management systems inject tokens and such through the environment).

You can reject the premise in your own environments, and then that part of 12 Factor doesn't apply to you.

Re: The Twelve-Factor App (2025)

#65
post #45
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…

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.

Re: The Twelve-Factor App (2025)

#66
post #39

Earlier quoted context omitted.

> this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files Teach them to use dotenv. We are moving away from configuration in config files because it is a pain to modify, especially if part of that configuration is secrets. You have to throw everything into your secrets vault of preference, and editing it requires extracting and reuploading the whole th…

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…

It's not a secret store. It's an IPC mechanism. Secret stores are built on top of it.

Re: The Twelve-Factor App (2025)

#67
post #59
post #16

Still incredibly relevant. Even if you don’t apply it, there is so much to learn by reading this in 15 minutes. The only grievance I have with this is Chapter 3: Config [1] “Store config in the environment”, “Credentials to external services such as Amazon S3 or Twitter” Besides being bad advice, this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files.…

100% this. 1. Keep secrets in a dedicated secrets store. 2. Read directly from the secrets store in application code. There is no environment, there are no environment variables. Yes, even on local.

It's pretty normal to keep secrets in a dedicated secret store, and then have the service launcher inject them from the secret store into the environment.

Re: The Twelve-Factor App (2025)

#69

Earlier quoted context omitted.

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 most obnoxious aspect of that: I specifically have my texts accessible on my laptop, but some 2fa authentication texts get blocked via that mechanism in favor of a message saying "look at this message on your phone".

That drives me crazy. The RBC app does this although it eventually times out and gives me the number.
Post reply on HN