Scenario

Picture an Angular application whose frontend must talk to backend APIs that live in different deployment targets. This walkthrough shows how to define extra environments, wire them up, and then serve or build the app for whichever target you need.

Creating the Environment Files

Generate the initial files:

In your terminal, execute:

ng generate environments

That command adds an environments folder under src, containing a starting environment.ts. By default, that file holds the configuration for your local development setup.

environment.ts

Add your development variables:

Open environment.ts and populate it with the values your dev environment needs:

export const environment = {
  production: false, //Set to False for development
  apiUrl: 'http://my-dev-url' //Replace with your development URL
};
Enter fullscreen mode Exit fullscreen mode

Set up files for UAT and production:

Create separate files for the other two targets:

environment.test.ts (for UAT)
environment.prod.ts (for Production)

Fill each one with the appropriate API endpoints for its corresponding environment:

// environment.test.ts (UAT)
export const environment = {
  production: false,
  apiUrl: 'http://my-uat-url'
};

// environment.prod.ts (Production)
export const environment = {
  production: true,
  apiUrl: 'http://my-prod-url'
};
Enter fullscreen mode Exit fullscreen mode

Using the Environment in Your Code

To pull the API URL into your application logic:

Import the environment module:

import { environment } from './environments/environment';

Reference the API URL:

Inside your service or component, use the imported variable:

export class MyService {
  constructor() {}
  apiUrl = environment.apiUrl;
}
Enter fullscreen mode Exit fullscreen mode

Wire up angular.json for per-environment builds:

Define build configurations:

In angular.json, find the "configurations" block inside the "build" target. This is where you declare which environment file each build variant should use.

"configurations": {
  "production": {
    // Rest of the configs
    "fileReplacements": [
      {
        "replace": "src/environments/environment.ts",
        "with": "src/environments/environment.prod.ts"
      }
    ]
  },

"staging": {
    // Rest of the configs
    "fileReplacements": [
      {
        "replace": "src/environments/environment.ts",
        "with": "src/environments/environment.test.ts"
      }
    ]
  },
  // ... other configurations
},

"defaultConfiguration": "production"
Enter fullscreen mode Exit fullscreen mode

With that setup, the Angular CLI swaps the default environment.ts for environment.prod.ts when you build for production, and for environment.test.ts when you build for UAT.

To serve the app in those environments as well, add similar configuration entries under the serve target in angular.json:

"serve": {
    "builder": "@angular-devkit/build-angular:dev-server",
    "options": { … },
    "configurations": {
      "development": {
        // Use the `development` configuration of the `build` target.
        "buildTarget": "my-app:build:development"
      },
      "staging": {
        // Use the `development` configuration of the `build` target.
        "buildTarget": "my-app:build:staging"
      },
      "production": {
        // Use the `production` configuration of the `build` target.
        "buildTarget": "my-app:build:production"
      }
    },
    "defaultConfiguration": "development"
  },
Enter fullscreen mode Exit fullscreen mode

Building and Serving for Each Environment

Compile for production:

Run the following to create a production bundle:

ng build --configuration=production

The value after --configuration should match the key you defined in angular.json (in our example, that's production and staging).

Serve for UAT:

To start a dev server pointed at your UAT configuration, use:

ng serve --configuration=staging

Wrap-Up

Relying on environment-specific configuration makes the build and deploy process far more comfortable. It keeps things tidy and easy to maintain, letting you ship to different targets without touching application code—which shortens the time it takes to get from development to production.

If this was helpful, you can find more about the author here.