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 b

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 :)