How to manage Local vs Dev vs Prod settings/configs in React?

React Best Practices

How to manage the settings that are different from local vs dev vs prod; such as api urls, resources, other parameters...

Comments

[Thomas Werner]

I would keep .env or other local configuration files out of version control. Add those files to .gitignore (in case you're using git) so they cannot ever be accidentally committed. Create a template with comments and explanations for your config file which can be customized by each developer working on the project (e.g. .env.template). That template file can be added to version control.

I would use a CI server such as Jenkins for building and deploying environment specific versions of your project. There are plenty of plugins and features that allow you to take full control over the build process.

One of those features is storing local configuration files such as .env files right in your CI server's database. You can add staging and production build configuration files to your CI server, and set up a build script that:

1. Checks out a fresh copy of your project
2. Adds the correct config file for the current build type to it
3. Builds and deploys the project

This has the following advantages:

• Not everyone on your dev team (or your client) really needs to know about all secrets and details that are stored in local configuration files. You keep them out of source control. Specifically the production secrets should be confidential
• An accidental source code leak does not mean that you have to renew all your 3rd party API keys and secrets

Minor downside:

• You need to add a CI server to your mix and learn how to set it up and how to write build scripts

[Xing Wang]

• Have 3 files. production.env, develop.env, and local.env
• but keep them out of the git. in your gitignore file, add .env to ignore all environment variable. it can be very dangerous to check production API keys into git.
• Keep the .env files separate, for most developers on your team, they should only have local.env or develop.env. The production.env should be only available to very few key people.

[Kasey Speakman]

Like you, I am currently searching for this answer.

I have used some of the suggested solutions already. I created different .env files. This still requires your code to have different build branches based on target environment. The built-for-production code is not portable between staging and production environments, for example. You would have to build again for staging.

What I wish for is something like config with 12-factor apps. I can build a backend service that can run in dev or staging or production without modification. Because the configuration comes from the running machine's environment vars instead of something that gets packaged into the app on build.

The only way I can think of to accomplish something like this with JS is to fetch a config file as the app's first action. It would need to call a separate configuration service that returns different configs depending on who is asking (e.g. Origin header). That feels like it misses the point a bit, but is probably closest to creating environment-portable apps.

🔔 Never put secrets in front-end code. Front-end web code, along with any included secrets, is directly viewable from the browser. Usually APIs designed for front-end use have a "public" key for that purpose. Otherwise use standard auth mechanism (session cookies or JWT) to make a request to your own backend. Then let your backend deal with the "secret" stuff. Although, mobile may actually have reasonable secret storage. I'm less familiar with that.

🔔 Don't depend on .gitignore to keep you from checking in secrets. It is easy to accidentally check in ignored files. If you put them anywhere inside your repo folder, they are vulnerable to being accidentally disclosed.

[Suri Nuthalapati]

I have been using .env file for environment specific configurations.