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 files between developers. This occurs either during the onboarding process when new engineers start working within a team or when an engineer merges new release code that adds/updates some variables. The problem is that each .env file is decentralized on each machine/environment. We need something more secure, robust, and stored in a single centralized location, such as a cloud environment variables management system that enables sharing with ease the secrets and other setting variables of an application.
What if we could all have those configurations on the cloud? And this is where Doppler comes in. With its handy CLI commands, you can ensure you run docker-compose over it, making sure all environment variables will be correctly loaded in the chosen environment.
Doppler is especially useful when working within a medium to large size team and with different environments (pierre-dev, dev, staging, prod, …). No copy/paste of missing environment variables anymore, no need to communicate with our teammates when releasing new env variables that break everyone else’s local environment, ...
The Downsides
You pay per user, and this could be a significant expense for your company. The more users you have in your team, the higher you pay (currently, it's set at $7/user). However, if you are a student, pursuing a diploma, bachelor, master, ... (even part-time) and you are enrolled in the fantastic GitHub Student Developer Pack, you can have it for free (for a limited time...). Anyway, it’s worth a try 😉
Now, it will give a significant boost to productivity for your team, as well as happiness over the slight frustration that the dotenv files can bring, which is the most important at the end of the day, right? 😊
Alternatives
dotenv has a sister package (still relatively new and not very 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.
Top comments (6)
We can also note that dotenv has a sister package (still relatively new and not very 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.