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

161–170 of 184 posts

Re: The Twelve-Factor App (2025)

#161

Post by sudhirj »

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 take still holds, although it is a bit more nuanced than it seems at first. 12 Factor was written by the founders of Heroku, for context, and that's exactly how Heroku worked. The app code would be submitted into a system, and run in a pre-container era container-ish environment where any instance specific data would be supplied as environment variables.

This is actually in place in most hosting providers today - don't know if Heroku does it, but many others like Vercel and Fly will also encrypt your secret env vars and decrypt and inject them only at the last minute.

AWS itself has something similar with its secrets manager. Even in the absence of credentials, like using role based IAM when running on EC2, it probably makes sense to note that the code must access credentials by hitting a local-only metadata server - and of course this is available only when running on EC2.

For other secret like payment processor tokens, etc, there's you do need to store secrets somewhere.

Putting secrets in plaintext in the files on the execution platform is of course a problem - but that's not a problem in the 12 Factor idea - it's a security lapse in the design and architecture of the platform that is supposed to be running your 12 Factor app, if that makes sense.

Re: The Twelve-Factor App (2025)

#162

Post by jiggunjer »

nightbrawler wrote: post #95
tptacek wrote: post #67

Earlier quoted context omitted.

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.

normal indeed but not what i'd consider a best practice anymore. we've moved away from any secrets in the env after the typical secrets leak when secrets popped up in some debug logging that hit datadog. we now have a secret cache layer api and the app loads secrets securely at time of use from that api. there's also no secret-0 problem because we use IAM auth when calling the cache. edit: for those wondering, api re…

Your iam token is just a secret by another name. Sure it's more automated but theres no avoiding secret0.

Re: The Twelve-Factor App (2025)

#163

Post by vinnymac »

vrosas wrote: post #48
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.

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

I tried to use this the other day and found out they still don’t support arm64 :(

Somehow ECS does though… tradeoffs everywhere I look have made me dizzy.

Re: The Twelve-Factor App (2025)

#164

Post by thaumasiotes »

grey-area wrote: post #158
thaumasiotes wrote: post #157

Earlier quoted context omitted.

You've never seen software that will use a default value, instead of refusing to operate, when a particular environment variable isn't present in the environment?

No I’ve never seen software that broke because someone added a config key.

Are you talking about altering environment variables in a system, or altering software to read different environment variables? I read jt2190 as talking about the former.

Re: The Twelve-Factor App (2025)

#165

Post by KnightHawk3 »

grey-area wrote: post #158
thaumasiotes wrote: post #157

Earlier quoted context omitted.

You've never seen software that will use a default value, instead of refusing to operate, when a particular environment variable isn't present in the environment?

No I’ve never seen software that broke because someone added a config key.

I was deploying some dotnet app and it broke because the devs baked a config key into the image that was otherwise unset, which enabled it trying to start a SSL endpoint without a cert, thus breaking the app.

Re: The Twelve-Factor App (2025)

#166

Post by mermadicsolutio »

nunez wrote: post #143
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?

Yeah I don't see a reason to use k8s if not on cloud, and k8s on cloud is even more complex. Compose is still the right size for one box, that one command does all was really nice to have

Re: The Twelve-Factor App (2025)

#167

Post by [deleted] »

jodersky wrote: post #153

> I. Codebase ( https://12factor.net/codebase ) > Multiple apps sharing the same code is a violation of twelve-factor. I never understood why the 12 factor app is against monorepos. It seems completely orthogonal to the contract between an application and its execution platform, which if I understand correctly, is the main point of 12 factor.

[deleted]

Re: The Twelve-Factor App (2025)

#170

Post by mermadicsolutio »

rietta wrote: post #9
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.

They got painfully expensive and then acquired. I still remember the arguments with clients and finally went all in AWS ECS, which is still quite pricey but clients seem to complain less about the Amazon bill then they did about Heroku.

Other than the pricing, for something built for simplicity, i always found their config method bit weird. Maybe it's just me b/c I first learned the aws stack, and got tired of managing EKS
Post reply on HN