How is this only from 2025? I thought this was a thing back in 2015
The Twelve-Factor App (2025)
131–140 of 184 posts
Re: The Twelve-Factor App (2025)
#132Earlier quoted context omitted.
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.
systemd-creds too, for anyone who has not found it yet like I was a week ago.
Re: The Twelve-Factor App (2025)
#133Earlier quoted context omitted.
> 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.
How does the running app instance get the workload identity?
The ways I can think of are (1) it's baked into the source code (worst possible security), (2) it's provided on the command line (also bad since command lines are visible to ps unless you do various OS-specific hijinks), (3) it's provided in an environment variable (no better than before), or (4) it's read from some well-known path (it seems to me that anything that could read a process's env vars could also read the contents of this file, so how is this more secure?)
Re: The Twelve-Factor App (2025)
#134Very 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-...
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.
Re: The Twelve-Factor App (2025)
#135Still 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.…
I wonder what alternative methods people use nowadays that are good enough but still simple and lightweight ? secret management services have its own place but not everyone have those available.
Re: The Twelve-Factor App (2025)
#136Still 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.…
Ironically agents F'IN LOVE using dotenv for config but really struggle with sOps (as of Opus 4.6; maybe its better now).
I was a massive fan of dotenv but sOps is so much cleaner, easy enough to use and works well enough in k8s.
Re: The Twelve-Factor App (2025)
#137Earlier quoted context omitted.
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.
tbf thats what a good logging lib is for, and if printenv can be run within the machine, then it's already too late
Re: The Twelve-Factor App (2025)
#138Still 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.…
Yeah, secrets should be fetched by application code from a secret store (aws secrets manager, vault, etc) using an identity. Put in a pull request.
This is the beauty of sOps. Store the secrets in the code, but store the keys in AWS SM and have sOps do the work. Works great with Instance Profiles or IRSA.
Re: The Twelve-Factor App (2025)
#139Still 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…
Adding a config setting should never be dangerous (if it is your system is deeply broken) and should be distinct from changing an existing config setting.
Re: The Twelve-Factor App (2025)
#140You 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…