DMNO: Environment Variables Evolved
dmno.dev
dmno.dev
This looks rather complicated. What is the advantage here, i.e. Why is my existing configuration "dumb" and "unsafe" (the opposite of what dnmo purports to be)?
You could already be doing all that with any scripting language, maybe Ansible and friends, but DMNO is more focused and seems to depend on Vite, so it’s also got a narrower (but huge) audience.
DMNO also includes multiple features that test if any environment variables are being accidentally leaked somehow.
While DMNO does use vite under the hood, it's not at all tied to your own usage of vite, or even of JS/TS. Our bet on using JS/TS is that it's fairly universal - most projects at least have a web frontend of some kind, so it's likely part of your stack, and most team members can write a little javascript, even if they don't love doing so. The tooling is also quite good in most IDEs without installing plugins, and can even be run in the browser, which opens up some interesting possibilities. For most end-users it should feel like writing some glorified json, but by using typescript, we get nice IDE support, can define inline functions without some DSL, and can build with the full power of a real programming language in cases where it's necessary.
It's not that these problems are so hard, but I've seen them bite people and waste tons of time, over and over again. Every time you onboard a new team member, every time you add a new external service to the stack, every time you rotate a key that folks had in their local .env, every time you try deploying something to a new environment and have to manually set up 20 env vars.
I've personally seen many production outages and hours of wasted time due to forgetting to update some new env var in every environment, or even a simple typo while updating it. With DMNO, your deployment would fail before it reaches prod and you'd get a clear error message about what went wrong - in return for writing out a very simple schema. No more pulling down the latest code to discover nothing boots anymore, and having to track down whoever has the new XYZ_KEY to add to your local env.
Of course there are ways to mitigate these problems, but many of them costly and complex to set up - meaning it only makes sense for larger projects.
There's definitely a lot going on under the hood - but for most end users, writing out your schema should feel like a glorified json file and you'll get a ton of value in return. Would love for you to give it a shot and let me know what you think after trying it out :)
Having a proper schema on secrets is also nice, I've ran into problems where a dev changed the name of a secret and broke everyone's local dev setup.
Don’t do this. Having all your secrets in git, encrypted with the same key, allows anyone with access to the repository to try decrypting sans any throttling. By looking at older commits, they get a helpful list of comparison values to infer your rotation schedule (if any) or possibly interesting targets.
If the attacker succeeds, or even just an employee with the decryption key leaves, you’ll need to rotate every single secret at once; you don’t control access to the secrets and don’t have an audit log, except for maybe logs of the git server.
I repeat: do not store secrets in git. Set up Vault or Infisical, or your cloud provider‘s secret management solution, and do it properly.
That said, it is a valid way that some folks use (see https://dotenvx.com/, https://github.com/AGWA/git-crypt, https://github.com/getsops/sops) which can make sense for simpler projects with less stringent security needs. The bonus here is it does not require setting up, paying for, or integrating any external service, and helps save you from "secret sprawl".
We have a plugin for 1password (which many teams are already using anyway) and have plugins planned for many other popular tools, including Infisical.
Many other tools only really make sense for bigger enterprises, either due to cost, complexity, or both. Our goal here (or one of them anyway) is to make a tool that provides enough value to use in all cases, from very small and simple to very large and complex.
Also don't forget having to log into CI and multiple infra providers to update those config values as well, where it can easily cause an outage (or at least block CI) if someone makes a mistake.
Of course you can do it a better way, but setting these tools up is often complex and costs money. We want to provide a tool that fixes all of the annoying papercuts of dealing with config, and is useful for everyone from solo devs all the way up to huge teams.
Please give it a whirl and let us know what you think!
But I think we can all agree that MANY people are using env vars for secrets because of their simplicity, so our hope is to help make those folks more secure and solve some of the related papercuts.
Ultimately DMNO is designed in a way that we should be able to swap out how the config actually gets passed around, so we can hopefully help users use whatever is the most secure way to do things without having to think too much about it.
Why?
- Your stack probably already includes some javascript, at the very least for a public facing website, and probably a lot more
- Most folks on your team probably know a bit of javascript, regardless of how they feel about it
- IDE tooling is usually pretty good, without installing additional plugins, and it can be run in the browser, which opens up some interesting possibilities
- npm modules exist to interact with most platforms/tools (many of which are official and maintained by the platform itself), helping to simplify the authoring of integrations