Why companies should ditch .env files for Doppler?
Okay, letβs face it, it has always been quite archaic to share the right updated .env...
For further actions, you may consider blocking this person and/or reporting abuse
We can also note that dotenv has a sister package (still relatively new and not too popular either), called dotenv vault that encrypts and pushes your keys, so that others working with us can easily pull them and retrieve the env variables.
I can't wait to hear about your experience with Doppler, Qovery, and similar tools. Have you started using any of these to centralize and secure the way you share environment variables across your team, etc? π€
I'm not really sold on the solution of paying a relativity high monthly price to store your secrets in a 3rd party service.
In some of my smaller Vercel hosted projects I've simply used Vercel's CLI to get the env.
The main project I am working on now is hosted in AWS and we already use AWS Secrets manager to store some secrets. So I just wrote a script to create the .env by reading Secrets Manager, Parameter Store parameters, and some hard-coded localhost specific values.
I might be more sold on something Dopler-like if it were an open source tool that used a config file to define where to fetch config from within whatever hosting you were already using.
The pain point I'm running into is that our environments are all over the place, some in local, some in GCP, some in Github, and misconfiguring any environment will cause the app to not start up.
This sounds quite painful indeed @donfour!, slowing down the development flow (and increasing the chance of having misconfiguration bugs, as you mentioned π).
Have you considered spending one hour cleaning up everything and implementing such a solution?
using a configuration management tool like mentioned in my article or a unified deployment strategy to address this issue.