I recently had to solve a similar problem on a project and did so in a different manner, but with largely the same results, using *nix's `envsubst` and nginx's `subs_filter`. I really like the SSI approach, but I'll share our approach as well as it covers it slightly differently.

We had a set of static frontend apps (React) that were built in CI, and which had to support being served either out of S3 buckets in a variety of environments, or in walled-off on-prem environments, and therefore had to support a variety of API endpoint URLs. There was an 85% likelihood that the endpoint URL would be one main one (our primary distribution platform), but the other 15% could be anything.

I set up a global variable attached to `window` (gasp!) in the frontend's index.html that would point to the API endpoint, and by default our CI build would spit out the common scenario URL. When doing local development, the URL was supplied via an environment file, which worked perfectly.

For all other production scenarios we served the app out of a Docker container. At container launch, we passed in via env vars the proper endpoint URL, and a script would absorb the passed env var and embed it into the nginx config file using `envsubst` like the OP's article. This config file was configured using `subs_filter` to find our global variable in the index.html file and replace its contents with that of the env var, which was now hardcoded in a sense into the file.

This setup was a bit convoluted, but it allowed us to not have to change anything while in local development, be able to change the endpoint URL each time the container was launched without any rebuild, and didn't require any additional requests to a configuration script. It was the best fit in our situation to allow local development to continue unchanged while also supporting pretty much any future scenario.

Hope that might spur some ideas for someone.