Implementing Dynamic Environment Configuration in Angular for Avoiding One Build per Environment

Share on facebook
Share on google
Share on twitter
Share on linkedin

One big flaw of the Angular CLI’s way of handling environments, according to the build once, deploy many DevOps principle, is that out-of-the-box Angular CLI wants you to create one separate build per environment.

Why should you only build once and reuse that build in all environments?

The reason why you don’t want to create a separate build for every environment is:

  1. It slows down CI pipelines because it needs to create a build for every environment
  2. It increases the risk of errors/differences in different environments because the builds are separate
  3. It adds unnecessary information about other environments in the code
  4. You might, for security reasons, don’t want to show confidential information in the environment config, which is saved to the version control

All these problems make me wonder why Angular CLI is opting for one build per environment. I sure wanted a solution to these problems.

How are these problems solved?

By making the deployment server substitute a config.json file, which is loaded on runtime by the app.

Making an Angular app use dynamic configurations

We want to make the Angular app only have two environment files: environment.ts and

Why two environments you may ask? One for local dev use, where you can put whatever you want when serving locally and one used when doing a prod build of the app. These environment files are getting most of its values from an app-config.json file loaded on runtime as contrast to having all the environment info hardcoded in the environment files.

Create a new Angular CLI App

The first step is to create a new Angular CLI app by opening the terminal, go to the desired directory for the app and type:

ng new dynamic-config-demo

And this should create a new Angular CLI app for you.

Loading the config.json file on startup

All the environment configuration are gonna be stored in a app-config.json file used by the environment.ts file for referencing these values type-safely.

We simply create an empty JSON file inside the assets folder called app-config.json.

The next step is to load the config.json file using an app.init.ts initialization service:

This service will run on startup and will ensure that the app-configuration is getting fetched by using fetch to get the configuration file and then save it in window for making it globally available to the application. Note, when using fetch you might need polyfills for IE browser support.

The app initializer service is set up in the app.module like this:

Using an app initializer service creates a slight delay on the startup time of the application, but simple stuff like this won’t have a big impact on startup time. Still, I recommend that you let your users know to wait using a loading spinner.

Make the environment files use dynamic values

Now that we are loading the configuration JSON dynamically and saving them in window, we want to be able to reference them type-safely. To do this, we should have three environment files: environment,, and dynamic-environment.

environment is for using locally, is for production and dynamic-environment is shared with environment and for providing dynamic configuration.

dynamic-environment looks like this:

This is used in environment like this:

Now we can try the new dynamic config capabilities out by displaying the environment name like this:

You can find a complete demo of an Angular app with dynamic configuration on my Github here.

Substituting the config.json file on the deployment server

Now that we have set the app up for dynamic configuration the next part is to set up substitution of the config file on the deployment server.

I have done this using Octopus, which has a smart function to substitute a JSON file with configuration values for the environment. Other deployment servers should have similar capabilities to substitute a JSON file right before deploying the app to the front end server.


We discussed the problems with the “Angular CLI” way of handling environment configuration with one build per environment and looked at why it is beneficial to do build once, deploy many instead. We looked at how to implement this using an app.init service which loaded a dynamic configuration file on initialization, with values set by the deployment server.

If you liked this post remember to comment, share and follow me on Twitter.

Do you want to become an Angular architect? Check out Angular Architect Accelerator.

Related Posts and Comments

Build a Course Platform with SPARTAN Stack

Build a Course Platform with the SPARTAN Stack​ Step by Step Guide giving you a full production ready setup with industry best practices. <p style=”text-align: center;”><b>Press for sound.</b><b></b></p> <h2>Here’s what’s inside…</h2> <p >Section 1</p> <h2>Designing the course portal (Figma)</h2> <p style=”text-align: left;”>We will cover the fundaments of designing a brand new site in Figma including

Read More »


Develop Real Projects With Industry Best Practices Join our community of expert developers and get the industry level best practices, step-by-step, from real projects. Hi, I’m Christian Lüdemann I’m a web developer from Denmark and the creator of this blog. You are here to learn how to code like the best companies and learn

Read More »

Debugging Angular apps (with Sentry) and workflow

In this video, we cover the topic of debugging Angular apps and provide an overview of various tools and approaches that can be used. I highlight the use of Sentry as a tool for error logging and performance monitoring. I also cover my scientific approach to fixing hard-to-debug bugs. Do you want to become an

Read More »