Personally I appreciate how straightforward and dead-simple environment variables are. Easy to check values with `env | grep ...', I'm content.
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)?
It appears to me that DMNO gathers then sets your environment variables at run time. It can gather them from a local config or from a multitude of network locations like a git repo or a website or a S3 bucket or run a function to calculate it now.
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.
Thats right :) and yes while you could do something similar on your own, you'd end up building a ton of custom tooling that has nothing to do with your actual business.
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.
DMNO founder here - having a proper schema for your config lets us do things like validation, coercion (because env vars are all strings), generate types with built-in docs, and reuse and compose your config together to keep things DRY. It also lets us understand which of your config items are actually sensitive and treat them accordingly - helping ensure you don't leak those items.
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 :)
> Being able to check secrets into Github instead of maintaining a separate secret store, which often charges per access, is super useful.
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.
DMNO creator here - sensitive config values are able to be retrieved from a variety of backends using a flexible plugin system. We are certainly not telling you that you have to use the encrypted file method, and depending on the security requirements of your project it may not be a good choice. You can also mix and match those plugins, and segment items however you see fit - so it's not always a single key being passed around.
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.
This happens all the time. Pull down the latest and suddenly you've got some cryptic runtime error, and it turns out there's a new config item everyone is missing. Wasting 20 minutes of 10 people's time quickly adds up - and while it may not happen that often, it does happen regularly. Also the "fix" is often insecurely sending the new key around on slack :(
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!
I like the simplicity of envars too, but they shouldn't be used for secrets. They are not designed to be secure, and are too easy to leak. Containers often allow placing secrets into files, and specifying the filepath in an envar. Files have access controls that are designed for security, so while it takes some thought, they are easier to secure.
There are tons of debates online about this. Realistically I think it's all tradeoffs and there are no silver bullets, so I won't really weigh in on the _right_ way to do it.
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.
We do certainly use JavaScript/TypeScript and we are targeting more JS heavy projects as initial users. That said, DMNO is meant to be universally applicable, and we think javascript is fairly _universal_, even if you personally don't love 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
Personally I appreciate how straightforward and dead-simple environment variables are. Easy to check values with `env | grep ...', I'm content.
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)?
It appears to me that DMNO gathers then sets your environment variables at run time. It can gather them from a local config or from a multitude of network locations like a git repo or a website or a S3 bucket or run a function to calculate it now.
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.
Thats right :) and yes while you could do something similar on your own, you'd end up building a ton of custom tooling that has nothing to do with your actual business.
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.
DMNO founder here - having a proper schema for your config lets us do things like validation, coercion (because env vars are all strings), generate types with built-in docs, and reuse and compose your config together to keep things DRY. It also lets us understand which of your config items are actually sensitive and treat them accordingly - helping ensure you don't leak those items.
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 :)
Being able to check secrets into Github instead of maintaining a separate secret store, which often charges per access, is super useful.
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.
> Being able to check secrets into Github instead of maintaining a separate secret store, which often charges per access, is super useful.
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.
DMNO creator here - sensitive config values are able to be retrieved from a variety of backends using a flexible plugin system. We are certainly not telling you that you have to use the encrypted file method, and depending on the security requirements of your project it may not be a good choice. You can also mix and match those plugins, and segment items however you see fit - so it's not always a single key being passed around.
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.
This happens all the time. Pull down the latest and suddenly you've got some cryptic runtime error, and it turns out there's a new config item everyone is missing. Wasting 20 minutes of 10 people's time quickly adds up - and while it may not happen that often, it does happen regularly. Also the "fix" is often insecurely sending the new key around on slack :(
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!
I like the simplicity of envars too, but they shouldn't be used for secrets. They are not designed to be secure, and are too easy to leak. Containers often allow placing secrets into files, and specifying the filepath in an envar. Files have access controls that are designed for security, so while it takes some thought, they are easier to secure.
There are tons of debates online about this. Realistically I think it's all tradeoffs and there are no silver bullets, so I won't really weigh in on the _right_ way to do it.
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.
Is there some sort of explanation of what DMNO is?
https://dmno.dev/docs/get-started/what-is-dmno/
4 capital letters
https://www.youtube.com/watch?v=Yt0kHiRsnHA&t=1880s
"printed in gold, 'cause plaintext makes the folks sweat"
Somehow I knew just from the title that this would be a JavaScript project.
We do certainly use JavaScript/TypeScript and we are targeting more JS heavy projects as initial users. That said, DMNO is meant to be universally applicable, and we think javascript is fairly _universal_, even if you personally don't love 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