[tracker1]

You can definitely do runtime based configuration. The bigger advantage to environment configuration generation at release is that you can target strictly static deployments. No need to support anything but HEAD/GET requests on said server, which can minimize a lot of risk in the environment.

The application I'm currently working on has a separate configuration project, more for application options for one client deployment vs. another at a feature level, as well as any customized localization/strings. Beyond this, there is are release variables generated that are also injected. Namely the endpoints for login/logout/user-management/api. The application itself doesn't handle authentication, it validates a token/key with the api endpoint. Other configuration options are loaded from the api endpoint on application startup.

The application itself will be loaded with the strings for the application and a small spinner and load-check. If the browser doesn't have JS or meet minimum requirements (ES2017 async function support), it will load another screen acknowledging as much. It will then verify the authentication token, load other parameters from the API/Database and proceed to client-side application routing/runtime.

It isn't particularly difficult to setup. Initially I had a complimentary server-side that would deliver the environment options at runtime. That was changed in order to facilitate static deployments of the application.