I'm transitioning my company's infrastructure from various git repos to a monorepo, primarily to improve CI, deployment, and package management processes. However, I'm uncertain about the best way to handle .env files in this new setup. Previously, each repo contained its own committed `.env.dev`, `.env.staging`, and `.env.prod`, with no secrets directly stored there—just references to AWS Secrets Manager IDs. Developers had local, uncommitted `.env` files that were automatically loaded. In a monorepo, I'm faced with the dilemma of either creating one large root `.env` file or duplicating common values like the database URL in each app's `.env` file. I want to ensure a smooth workflow for everyone, ideally with a root `.env` for common configurations and separate `.env` files for specific project settings, but I'm running into limitations like the inability to specify multiple `.env` files in VSCode. How do others manage their environment configuration in a monorepo while keeping the developer experience positive?
5 Answers
Centralized configuration management is key. Whether you go for a cloud service or a database that holds your configuration, keep it outside your codebase. Having a UI for switching environments can greatly enhance developer flexibility without IDE constraints.
While not everyone is thrilled about the monorepo transition, it can simplify environment management significantly. If needed, setting up a single `.env` file per app in the monorepo might mirror your previous setup while still providing a better development experience overall.
Definitely! It’s about finding that balance and making sure everyone stays on track.
It's essential to manage your `.env` files carefully in a monorepo. If you're using PHP, for instance, there are libraries like Symfony's DotEnv that can seamlessly handle multiple `.env` files following a naming convention. You can set up a primary `.env` for production and override specific values for dev or staging contexts. That way, your team can run local setups without heavy lifting and without duplicating configuration. This keeps things neat and manageable!
That's insightful! I assume this means you have a base configuration in your production file and local ones as needed? I'm interested in how you'd practically apply that.
Exactly! It minimizes redundancy by centralizing keys and allowing developers to inject environment-specific variables without much hassle.
My approach is to make sure no secrets end up in the repo. I rotate keys and manage them safely. But in your case, if you're just putting AWS Secrets IDs in the `.env`, that's relatively safe. It's good practice to keep the sensitive values fetched dynamically during runtime, rather than storing any credentials directly. Seems like you're on the right track!
Exactly my thoughts! Separating IDs and fetching secrets at runtime is a much safer approach. It keeps everything streamlined.
Thanks for the encouragement! That's the plan—to keep sensitive info clear of the repo and just manage IDs.
Don't forget to add your `.env` files to the `.gitignore`. You should avoid committing sensitive information directly. Instead, consider generating them from a secure vault or template, which helps maintain a clean repo while still integrating with your CI pipelines.
Yes, the idea is to blend old practices with new benefits. Sometimes, having just one `.env` for each app can work just as well.