The Twelve-Factor App: A Methodology for Modern SaaS
The Twelve-Factor App is a methodology for building software-as-a-service applications that emphasizes declarative setup, portability, cloud deployment, and continuous deployment. It outlines twelve principles—from codebase and dependencies to logs and admin processes—that help minimize divergence between development and production, enable scaling, and prevent software erosion. Written by developers from Heroku, it synthesizes experience from hundreds of thousands of apps and provides a shared vocabulary for addressing systemic problems in modern app development.
The twelve-factor methodology can be applied to apps written in any programming language, and which use any combination of backing services (database, queue, memory cache, etc).
- nebezb
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.
- browningstreet
I really thought this would be a 12 layer MFA demo showing the absurdity of our current painful & unsustainable MFA trends.
- dec0dedab0de
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.
- 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.
- theozero
.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.
- imglorp
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.
- mermadicsolutio
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
- RKearney
Title should read (2011)