How to update environment variables without rebuilding the React app image

I had the same problem recently, then I published some packages: @import-meta-env/* to npm to solve the problem.

This plugin exposes environment variables on a special import.meta.env object (heavily inspired by Vite).

During production it will be statically replaced with a placeholder instead of current environment variables.

Thus we can run a script anywhere to populating files with environment variables from the system.

You can see more info at https://iendeavor.github.io/import-meta-env/ .

I also created a Docker example: https://github.com/iendeavor/import-meta-env/tree/main/packages/examples/docker-starter-example .

Hope this helps someone who needs it.

What you are trying to accomplish is applying the principle of "build once, deploy many" to a ReactJS app.

The following article covers some of the available options to do that: https://profinit.eu/en/blog/build-once-deploy-many-in-react-dynamic-configuration-properties/

Build once, deploy many is an essential principle of software development. The main idea is to use the same bundle for all environments, from testing to production. This approach enables easy deployment and testability and is considered a fundamental principle of continuous delivery. It is also part of the twelve-factor methodology. As crucial as it is, it has not received significant support in the world of frontend development, and React is no exception.

The simplest solution provided by the article is based on an external configuration file.

External configuration file:

// public/config.js
// provided by the customer as a resource in the public folder, after compilation

const apiUrl = "http://api.myservice.com";
const env = "TST";

Website root (index.html):

<script src="%PUBLIC_URL%/config.js"></script>
<script>
  window.config = { apiUrl, env };
</script>

In other words, your bundled (built/compiled) app should import an external config.js file, and make them globally available using the window object.

The article goes on giving some more advanced and refined options, but the above should suffice for simple usecases.

In addition to the options presented by Ernest and pagliuca, you can also implement the Immutable Web Applications methodology presented in detail here: https://immutablewebapps.org/

Basically, separate static assets (which do not contain anything specific to the environment) and web application configuration (non-static) which varies from environment to environment and from deployment to deployment, using index.html as a configuration file.

An implementation advantage is that we can add version references to the static assets of the web application and set the environment variables. In the unlikely event that a browser attempts to load an outdated version of index.html, all features of the previous version will still be available and not corrupted.

Yes indeed this is a problem with environment variables. What you want to achieve can be done with a service that is commonly called "Remote Config" or "Config as a service - CaaS". This service notifies your application that some external data has changed. I would highly recommend LaunchDarkly or Firebase but you can always choose to build it on your own (not a fast solution though). The only way to avoid multiple environment builds is by applying rules on the CaaS and modify the responses based on who requests (eg, based on the request's "Origin" header)