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

41–50 of 184 posts

Re: The Twelve-Factor App (2025)

#41

Post by nebezb »

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?

> You need some way to pass secrets to the app

Absolutely. This is why the env method is so attractive. It's simple and feels "free".

> doesn't every other way also suffer the same kind of issue

Not entirely. Accessibility (or dev ergonomics) and security are opposite ends of the same dial. As the other commenter wrote: a workload identity and a vault, and sharing the secrets between the two in a way that doesn't leave a plain-text trace for everyone to read (the environment is not private).

I like sops: https://github.com/getsops/sops

Re: The Twelve-Factor App (2025)

#42

Post by theozero »

weinzierl wrote: post #34
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.

I won't disagree that it comes with security tradeoffs and depending on the situation it can definitely be a problem. But in many cases with how people deploy lots of software - most PaaS and things like lambdas / cloudflare workers, etc - it's absolutely fine. With varlock, we can even swap out the secret delivery mechanism at the end - but you still get a schema and familiar interface for how it all works.

Re: The Twelve-Factor App (2025)

#44

Post by nebezb »

jt2190 wrote: post #28
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 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 unwritten assumption in 12 Factor is: the environment is secure.

Fair assumption.

Assuming no attackers and you're only running trusted code, I still maintain the environment is a poor place to keep secrets. Devs adding `{ meta: process.env }` to logs. Instrumentation/reporting libraries dumping the process (and the env) for crash reports. Trust that subprocesses + dependencies inheriting your environment are taking equal care to avoid these issues, too.

Re: The Twelve-Factor App (2025)

#45

Post by HHad3 »

jt2190 wrote: post #28
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 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.

Re: The Twelve-Factor App (2025)

#46

Post by dewey »

nebezb wrote: post #40
stephbook wrote: post #35

Earlier quoted context omitted.

"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

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.

Re: The Twelve-Factor App (2025)

#47

Post by stephbook »

Tomte wrote: post #13

Every time it gets posted I read through the list and think "export services via port binding… of course a web server binds to a port, of course it‘s decoupled that way, what else would you do" and "treat backing services as attached resources… huh, is that really only about not linking in a database, but connecting using a JDBC string, for example?" So let me ask for once: what am I missing? Why is that interesting…

Doctors didn't wash their hands between inspecting corpses and doing surgery.

Drivers protested against seat belts that would save their own lives.

Times change and hindsight is 20/20. Let's just say 10 years ago I worked at a company that broke all 12 factors.

Re: The Twelve-Factor App (2025)

#49

Post by bad_username »

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

Notably, there is no requirement or recommendation that the dev environment be a single, shared environment. Development processes where this environment is single is shared is as terrible as it is ubiqitous.

Re: The Twelve-Factor App (2025)

#50

Post by kestrel-robotic »

cgarvis wrote: post #11
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.

Fly.io brings back some of that easy of deploy.

Caprover for me, but fly.io is pretty cool, reminds me of flynn.io
Post reply on HN