Multi‑Cloud Angular Deployments for AWS, Azure, and GCP — An Angular Consultant’s CI/CD Playbook (GitHub Actions, Jenkins, Azure DevOps)

Multi‑Cloud Angular Deployments for AWS, Azure, and GCP — An Angular Consultant’s CI/CD Playbook (GitHub Actions, Jenkins, Azure DevOps)

Build once, deploy many. Proven multi‑cloud hosting and pipelines for Angular 20+ that won’t break production.

Build once, deploy many. Promote artifacts, not branches. Measure everything.
Back to all posts

I’ve shipped Angular dashboards that had to survive kiosk outages in airports, analytics spikes during live events, and executive demos on flaky hotel Wi‑Fi. When a CTO says “Make it multi‑cloud,” they usually mean: zero downtime, trivial rollbacks, and clear metrics. Here’s exactly how I deliver that with Angular 20+, Signals/SignalStore, Nx, and pipelines that don’t collapse under real‑world pressure.

The Airline Kiosk That Had to Survive a Cloud Outage

As companies set 2025 Angular roadmaps, “multi‑cloud” is as much about governance and latency as it is about uptime. The trick is to avoid three divergent builds and three sources of truth. Build once; deploy many; measure relentlessly.

The scene

We had airport kiosks running Angular with hardware peripherals (card readers, printers, scanners) that needed to operate even when a region hiccupped. Ops asked for multi‑cloud: primary in Azure, warm standby in AWS, Docker simulation for hardware so we could test without a hangar full of kiosks.

We built once with Nx, pushed artifacts to an internal registry, and fanned out deployments to Azure Storage+Front Door and S3+CloudFront. Runtime config toggled endpoints per region, and the kiosk app handled offline/online with exponential backoff and jitter. Failovers were boring—which is exactly what you want.

Why Multi‑Cloud Delivery Matters for Angular 20+ Teams in 2025

If you need to hire an Angular developer or bring in an Angular consultant, this is where multi‑cloud pays off: lower MTTR, predictable rollbacks, and numbers leadership understands.

The business reasons

Multi‑cloud isn’t ideology; it’s risk management. For Angular teams shipping role‑based dashboards, telematics, or kiosks, you want regional performance, DR playbooks, and approvals that satisfy audit.

  • Regulatory separation and data residency

  • Latency and regional edges for dashboards

  • Vendor negotiation leverage

  • Disaster recovery and incident response

The engineering reasons

Angular 20’s esbuild pipeline and Signals/SignalStore let us keep runtime state and UX stable while ops flips origins or routes. We instrument Core Web Vitals and CDN cache hit rates to prove it.

  • Artifact promotion beats branch promotion

  • Static hosting beats SSR until metrics prove otherwise

  • Runtime config beats per‑env rebuilds

Reference Architecture: Build Once, Deploy Many (Nx, Signals, Artifact Promotion)

// runtime-config.store.ts (Angular 20+, @ngrx/signals)
import { signalStore, withState, withMethods } from '@ngrx/signals';

export interface RuntimeConfig {
  apiBaseUrl: string;
  featureFlags: Record<string, boolean>;
  cdn: 'aws' | 'azure' | 'gcp';
}

export const RuntimeConfigStore = signalStore(
  { providedIn: 'root' },
  withState<RuntimeConfig>({ apiBaseUrl: '', featureFlags: {}, cdn: 'aws' }) ,
  withMethods((store) => ({
    async load() {
      const res = await fetch('/assets/runtime-config.json', { cache: 'no-store' });
      const cfg = await res.json();
      store.$patch(cfg);
    },
  }))
);

// app.config.ts
import { APP_INITIALIZER, ApplicationConfig, inject } from '@angular/core';
import { provideHttpClient } from '@angular/common/http';
import { RuntimeConfigStore } from './runtime-config.store';

export function runtimeConfigInitializer() {
  const store = inject(RuntimeConfigStore);
  return () => store.load();
}

export const appConfig: ApplicationConfig = {
  providers: [
    provideHttpClient(),
    { provide: APP_INITIALIZER, useFactory: runtimeConfigInitializer, multi: true },
  ],
};

Core principles

Avoid env‑specific builds. Output a single dist/ artifact with content‑hashed filenames. Store in artifact repo. CI jobs pull it and deploy to each cloud with cloud‑specific commands.

  • Single Nx build → immutable artifact

  • Parallel deployments to AWS/Azure/GCP

  • Runtime-config.json injected at startup

  • Strict caching: hashed assets (immutable), short TTL HTML

Signals + SignalStore for config

Keep environment differences out of the binary. Fetch runtime config at startup and expose via SignalStore so components react instantly without page reloads.

Hosting Strategies by Cloud: SPA vs SSR, Caching, and Costs

Use case AWS Azure GCP Pros Cons
SPA (default) S3 + CloudFront (OAC) Azure Storage + CDN/Front Door GCS + Cloud CDN Cheapest, global POPs, trivial rollback Needs explicit CDN invalidation for HTML
SSR (Node) Lambda@Edge or ECS Fargate App Service/Functions Cloud Run SEO, potentially lower LCP first paint More moving parts, cost, cold starts
Multi‑tenant CloudFront behaviors + headers Front Door routes + rules URL map host/path rules Simple routing, cache partitioning Config sprawl if unmanaged

Set cache headers during deploy so assets are immutable and index.html is fresh:

Default to static; graduate to SSR only when metrics demand

On most enterprise dashboards I’ve built (telecom ads analytics, insurance telematics), static hosting with aggressive CDN caching beat SSR in cost and complexity while hitting LCP < 2.5s.

  • SPA: cheapest, fastest, simplest; perfect for dashboards with cached APIs

  • SSR: use when SEO critical or initial data/hydration boosts LCP/INP

  • Hybrid: static shell + API prefetch for hero data

SPA hosting patterns

Each cloud can serve your Angular build with long‑lived cache headers for assets and short TTL for index.html. Enable WAF and TLS everywhere.

  • AWS: S3 static website + CloudFront + Origin Access Control

  • Azure: Storage Static Website + CDN or Front Door

  • GCP: Cloud Storage + Cloud CDN + HTTPS Load Balancer

SSR patterns (only when needed)

If you go SSR, containerize the Node server, use blue/green (slots/revisions), and set a hard budget for cold starts and memory.

  • AWS: Lambda@Edge or ECS Fargate behind CloudFront

  • Azure: App Service (Node) or Azure Functions with Node SSR

  • GCP: Cloud Run (Node SSR) behind HTTPS Load Balancer + Cloud CDN

CI/CD with GitHub Actions: One Pipeline, Three Clouds

# .github/workflows/deploy-multicloud.yml
name: Deploy Angular Multi-Cloud
on:
  push:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: '20' }
      - name: Install
        run: npm ci
      - name: Build (Nx)
        run: npx nx build web --configuration=production
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: web-dist
          path: dist/apps/web

  deploy:
    needs: build
    runs-on: ubuntu-latest
    strategy:
      matrix:
        provider: [ aws, azure, gcp ]
    steps:
      - uses: actions/download-artifact@v4
        with: { name: web-dist, path: dist }

      - name: Deploy to AWS S3+CloudFront
        if: matrix.provider == 'aws'
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_OIDC_ROLE }}
          aws-region: us-east-1
      - if: matrix.provider == 'aws'
        run: |
          aws s3 sync dist s3://my-angular-spa/ --delete --cache-control max-age=31536000,public --exclude index.html
          aws s3 cp dist/index.html s3://my-angular-spa/index.html --cache-control no-store
          aws cloudfront create-invalidation --distribution-id $CF_DISTRIBUTION_ID --paths /index.html
        env:
          CF_DISTRIBUTION_ID: ${{ secrets.CF_DISTRIBUTION_ID }}

      - name: Deploy to Azure Storage+CDN
        if: matrix.provider == 'azure'
        uses: azure/login@v2
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
      - if: matrix.provider == 'azure'
        run: |
          az storage blob sync -c '$web' -s dist --account-name mystaticacct --delete
          az storage blob upload --account-name mystaticacct -f dist/index.html -c '$web' -n index.html --overwrite \
            --content-cache-control 'no-store'
          az cdn endpoint purge -g myrg -n mycdnendpoint --profile-name mycdnprofile --content-paths '/index.html'

      - name: Deploy to GCP GCS+Cloud CDN
        if: matrix.provider == 'gcp'
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: ${{ secrets.GCP_WORKLOAD_IDP }}
          service_account: ${{ secrets.GCP_SA }}
      - if: matrix.provider == 'gcp'
        uses: google-github-actions/setup-gcloud@v2
      - if: matrix.provider == 'gcp'
        run: |
          gsutil -m rsync -d -r dist gs://my-angular-spa
          gsutil setmeta -h 'Cache-Control:no-store' gs://my-angular-spa/index.html
          gcloud compute url-maps invalidate-cdn-cache my-url-map --path '/index.html'

Build once, publish artifact

Use Nx to build Angular 20+ with hashing. Upload the dist as a single artifact; don’t rebuild in deploy jobs.

Deploy matrix

Fan out to AWS, Azure, and GCP in parallel. Use OIDC where possible to avoid long‑lived secrets. Invalidate/purge CDNs post‑sync.

Jenkins Pipeline: Parallel Deployments and Deterministic Rollbacks

pipeline {
  agent { docker { image 'node:20' } }
  options { timestamps() }
  stages {
    stage('Checkout') { steps { checkout scm } }
    stage('Install & Build') {
      steps {
        sh 'npm ci'
        sh 'npx nx build web --configuration=production'
        stash name: 'dist', includes: 'dist/apps/web/**'
      }
    }
    stage('Deploy Parallel') {
      parallel {
        stage('AWS') {
          agent any
          steps {
            unstash 'dist'
            withAWS(role: env.AWS_ROLE, region: 'us-east-1') {
              sh '''
              aws s3 sync dist/apps/web s3://my-angular-spa/ --delete --cache-control max-age=31536000,public --exclude index.html
              aws s3 cp dist/apps/web/index.html s3://my-angular-spa/index.html --cache-control no-store
              aws cloudfront create-invalidation --distribution-id $CF_DISTRIBUTION --paths /index.html
              '''
            }
          }
        }
        stage('Azure') {
          steps {
            unstash 'dist'
            withCredentials([azureServicePrincipal('AZURE_SP')]) {
              sh '''
              az login --service-principal -u $AZURE_CLIENT_ID -p $AZURE_CLIENT_SECRET --tenant $AZURE_TENANT_ID
              az storage blob sync -c '$web' -s dist/apps/web --account-name mystaticacct --delete
              az storage blob upload --account-name mystaticacct -f dist/apps/web/index.html -c '$web' -n index.html --overwrite --content-cache-control 'no-store'
              az cdn endpoint purge -g myrg -n mycdnendpoint --profile-name mycdnprofile --content-paths '/index.html'
              '''
            }
          }
        }
        stage('GCP') {
          steps {
            unstash 'dist'
            withCredentials([file(credentialsId: 'GCP_SA_JSON', variable: 'GOOGLE_APPLICATION_CREDENTIALS')]) {
              sh '''
              gcloud auth activate-service-account --key-file=$GOOGLE_APPLICATION_CREDENTIALS
              gsutil -m rsync -d -r dist/apps/web gs://my-angular-spa
              gsutil setmeta -h 'Cache-Control:no-store' gs://my-angular-spa/index.html
              gcloud compute url-maps invalidate-cdn-cache my-url-map --path '/index.html'
              '''
            }
          }
        }
      }
    }
  }
}

Why Jenkins

For a telecom ads analytics dashboard, we used Jenkins to fan out to AWS/GCP while keeping on‑prem artifact retention for audits.

  • Great for on‑prem or hybrid clouds

  • Fine‑grained control; easy to parallelize

Jenkinsfile

Use stashes to move artifacts between stages; run cloud deploys in parallel.

Azure DevOps: Staged Approvals and Environment Gates

# azure-pipelines.yml
trigger:
  branches: { include: [ main ] }

stages:
- stage: Build
  jobs:
  - job: Build
    pool: { vmImage: 'ubuntu-latest' }
    steps:
    - checkout: self
    - task: NodeTool@0
      inputs: { versionSpec: '20.x' }
    - script: |
        npm ci
        npx nx build web --configuration=production
      displayName: Build
    - publish: dist/apps/web
      artifact: web-dist

- stage: Deploy
  dependsOn: Build
  jobs:
  - deployment: AWS
    environment: prod-aws
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: web-dist
          - task: AWSCLI@1
            inputs:
              awsCredentials: 'aws-oidc-service-connection'
              regionName: 'us-east-1'
              awsCommand: |
                aws s3 sync $(Pipeline.Workspace)/web-dist s3://my-angular-spa/ --delete --cache-control max-age=31536000,public --exclude index.html
                aws s3 cp $(Pipeline.Workspace)/web-dist/index.html s3://my-angular-spa/index.html --cache-control no-store
                aws cloudfront create-invalidation --distribution-id $(CF_DISTRIBUTION_ID) --paths /index.html

  - deployment: Azure
    environment: prod-azure
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: web-dist
          - task: AzureCLI@2
            inputs:
              azureSubscription: 'azure-sp-connection'
              scriptType: bash
              scriptLocation: inlineScript
              inlineScript: |
                az storage blob sync -c '$web' -s $(Pipeline.Workspace)/web-dist --account-name mystaticacct --delete
                az storage blob upload --account-name mystaticacct -f $(Pipeline.Workspace)/web-dist/index.html -c '$web' -n index.html --overwrite --content-cache-control 'no-store'
                az cdn endpoint purge -g myrg -n mycdnendpoint --profile-name mycdnprofile --content-paths '/index.html'

  - deployment: GCP
    environment: prod-gcp
    strategy:
      runOnce:
        deploy:
          steps:
          - download: current
            artifact: web-dist
          - bash: |
              gcloud auth activate-service-account --key-file=$(GCP_SA_JSON)
              gsutil -m rsync -d -r $(Pipeline.Workspace)/web-dist gs://my-angular-spa
              gsutil setmeta -h 'Cache-Control:no-store' gs://my-angular-spa/index.html
              gcloud compute url-maps invalidate-cdn-cache my-url-map --path '/index.html'
            env:
              GCP_SA_JSON: $(GCP_SA_JSON)

Use environments for approvals

For a broadcast network VPS scheduler, Azure DevOps gates kept compliance happy while we shipped daily.

  • Manual approval before prod

  • Protected variables and service connections

Pipeline YAML

Build once, then deploy to three clouds with approvals.

Runtime Configuration Without Rebuilds: SignalStore + APP_INITIALIZER

// example: using the config in a service
import { inject, Injectable, computed } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { RuntimeConfigStore } from './runtime-config.store';

@Injectable({ providedIn: 'root' })
export class ApiService {
  private http = inject(HttpClient);
  private cfg = inject(RuntimeConfigStore);
  private baseUrl = computed(() => this.cfg.apiBaseUrl);

  getUsers() {
    return this.http.get(`${this.baseUrl()}/users`);
  }
}

Why runtime config

We keep a runtime-config.json next to index.html. Flipping API hosts or toggling features doesn’t require a rebuild, just an atomic upload plus a CDN purge for HTML.

  • No env rebuilds

  • Safer blue/green flips

  • Multi‑tenant overrides

Consume config with Signals

Expose config through a SignalStore. Components subscribe to signals, and your UI updates without reloads.

Caching, CDN Invalidation, and Versioning: Make Cache Work For You

# Example: set headers for a bucket (AWS)
aws s3 cp dist s3://my-angular-spa/ --recursive \
  --cache-control max-age=31536000,public,immutable \
  --exclude index.html
aws s3 cp dist/index.html s3://my-angular-spa/index.html --cache-control no-store

Cache rules that work

Immutable assets mean no mass invalidations; only purge index.html. Measure CloudFront/Cloud CDN cache hit rates; aim for >95% for assets.

  • Assets: Cache-Control: public, max-age=31536000, immutable

  • HTML: Cache-Control: no-store

  • Version every deploy; never overwrite hashed assets

Service worker? Maybe

For kiosks I add a service worker for peripheral readiness and offline flows. For public dashboards, CDN caching usually beats SW complexity.

  • Angular PWA helps kiosks/offline UIs

  • Be careful with stale HTML in PWA caches

Security, Secrets, and Edge Rules Across AWS/Azure/GCP

Security isn’t a separate track. It’s baked into the pipeline and the CDN. I run OWASP ZAP in CI for kiosk apps and use WAF managed rules for public dashboards.

Identity and CORS

Use the cloud’s managed identity wherever possible. Keep API CORS tight to the CDN hostnames; never wildcard in production.

  • OIDC: Azure AD/Microsoft Entra ID, Cognito, or Auth0

  • Lock CORS to your CDN origins only

Secrets and deploy auth

Prefer short‑lived tokens. Store nothing sensitive in the repo. Audit who can deploy which environment.

  • GitHub OIDC → AWS/Azure/GCP

  • Azure Key Vault, AWS Secrets Manager, Secret Manager

Edge rules and WAF

Use edge to enforce security and performance policies consistently across clouds.

  • CloudFront Functions/Edge, Front Door rules engine, Cloud Armor

  • Block crawlers, strip headers, force HTTPS

Real Projects: Telecom Analytics on GCP with AWS DR; Airline Kiosks on Azure with AWS Warm Standby

These weren’t lab demos. They ran in production with incident drills and measurable outcomes: LCP/INP steady, error budgets intact, and executive dashboards up during live events.

Telecom ads analytics (GCP primary, AWS DR)

We served Angular + PrimeNG dashboards from GCS, BigQuery fueled charts (D3/Highcharts). During a CDN provider issue, we flipped DNS to CloudFront; LCP stayed <2.6s in North America.

  • GCS+Cloud CDN primary, S3+CloudFront mirror

  • GA4 + BigQuery for real‑user metrics

  • Rollback < 3 minutes via CDN switch

Airport kiosks (Azure primary, AWS standby)

Device readiness and peripheral APIs were simulated in Docker so we could test payment and printing without physical kiosks. Runtime config drove endpoint flips; SignalStore kept UI state coherent during reconnects.

  • Azure Storage+Front Door primary, S3+CloudFront warm

  • Docker hardware simulation for CI

  • Offline‑tolerant flows with exponential backoff

When to Hire an Angular Developer for Multi‑Cloud Delivery

Looking for an Angular expert? I’m a remote Angular consultant who can assess and stand up a build‑once, deploy‑many pipeline in 1‑2 weeks, then hand it to your team with guardrails and dashboards.

Signals you need help

If any of these sound familiar, hire an Angular developer with Fortune 100 experience to normalize builds, add runtime config, and build pipelines with fast rollbacks. I’ve done this for airlines, telecoms, and media networks.

  • You rebuild per environment and deploy times balloon

  • SSR was added but didn’t move LCP/INP

  • Rollbacks require a full rebuild and change approvals

  • You can’t answer “What’s our cache hit rate?”

How an Angular Consultant Plans Multi‑Cloud CI/CD for Angular

This is exactly how I stabilized chaotic codebases and reduced MTTR on live dashboards. See NG Wave for component quality and IntegrityLens/SageStepper for live Angular 20+ apps.

Week 1: Assess and prototype

You’ll get a written assessment and a sandbox repo with working multi‑cloud deploys.

  • Audit build (Nx/CLI), asset hashing, bundle budgets

  • Create a runtime-config POC with SignalStore

  • Provision three buckets/origins and CDNs

Week 2–3: Harden and automate

We lock in approvals, SLOs, and rollback scripts. Your team can operate it by day 10–15.

  • Add OIDC auth to pipelines

  • Set headers and purges, add WAF rules

  • Wire GA4/BigQuery and CDN metrics

Week 4+: Optional SSR and DR drills

Only if metrics justify SSR; otherwise keep it static and fast.

  • Containerized SSR with blue/green (slots/revisions)

  • Quarterly DR playbook with mock incidents

Key Takeaways and What to Instrument Next

Ready to discuss your Angular roadmap? Review my live products—NG Wave components, the AI‑powered verification system at IntegrityLens, and the adaptive learning system SageStepper—and let’s map a plan for your team.

Measure what matters

Tie every recommendation to numbers. Executives care about reliable UX, not tech fashion.

  • LCP/INP from GA4 RUM and Lighthouse CI

  • CDN cache hit rate and TTFB per region

  • Deploy MTTR, rollback success rate

Next steps

If you’re evaluating multi‑cloud for 2025, we can have a discovery call this week and ship a working pipeline in two.

  • Adopt build‑once, deploy‑many

  • Add runtime config with SignalStore

  • Stand up parallel multi‑cloud deploys in your CI

FAQs: Multi‑Cloud Angular CI/CD

Q: Do we need SSR to succeed with multi‑cloud? A: No. Start with SPA on CDNs. Add SSR only if metrics demand it (SEO or LCP/INP wins).

Q: How fast can we roll back? A: With versioned buckets and CDN purges, static rollbacks take 1–3 minutes. SSR blue/green via slots/revisions is similarly quick.

Q: Which CI should we choose? A: GitHub Actions for simplicity, Azure DevOps for enterprise gates, Jenkins for on‑prem control. All can do build‑once, deploy‑many.

Q: What about costs? A: Static CDNs are inexpensive. SSR adds runtime cost. Multi‑cloud primarily increases ops complexity—offset by better MTTR and leverage.

Related Resources

Key takeaways

  • Adopt build‑once, deploy‑many: promote a single immutable artifact to AWS, Azure, and GCP to avoid drift.
  • Use static hosting (S3+CloudFront, Azure Storage+CDN/Front Door, GCS+Cloud CDN) for SPA; switch to SSR only if metrics demand it.
  • Centralize runtime config via SignalStore + APP_INITIALIZER to avoid rebuilds per environment/tenant.
  • Design CI/CD for fast rollbacks: versioned buckets, CloudFront invalidations, App Service/Cloud Run slots or revisions.
  • Instrument success: cache hit rate, TTFB, LCP/INP, error budgets, and deployment MTTR across clouds.

Implementation checklist

  • Decide SPA vs SSR with Lighthouse and Core Web Vitals—don’t assume SSR.
  • Create a single Nx build that outputs hashed, immutable assets; publish as an artifact.
  • Provision three static origins (S3, Azure Storage, GCS) with CDNs in front; enforce HTTPS/WAF.
  • Implement runtime-config.json + SignalStore; inject via APP_INITIALIZER.
  • Stand up CI in GitHub Actions (or Jenkins/Azure DevOps) with parallel cloud deploy jobs.
  • Automate CDN invalidation/purges; rely on long-lived immutable caching for assets.
  • Protect deploy credentials with OIDC (GitHub→AWS/Azure/GCP) or short‑lived tokens; store no long‑term secrets in repos.
  • Add RUM + logs: GA4/BigQuery, CloudWatch, Azure Monitor, Cloud Logging; alert on LCP/INP regressions and 5xx.
  • Use blue/green (CloudFront versions, App Service slots, Cloud Run revisions) with fast rollback scripts.
  • Document a cross‑cloud DR drill: 30‑minute failover playbook, tested quarterly.

Questions we hear from teams

How much does it cost to hire an Angular developer for multi‑cloud delivery?
It depends on scope, but typical engagements run 2–6 weeks. I offer fixed‑fee assessments and week‑by‑week delivery. Expect strong ROI: faster rollbacks, lower MTTR, and reliable dashboards that reduce incident costs.
What does an Angular consultant do for multi‑cloud deployments?
I design build‑once, deploy‑many pipelines, set cache/headers, add runtime SignalStore config, wire OIDC auth, and instrument Core Web Vitals and CDN metrics. I hand off runbooks and train your team to operate it.
How long does a multi‑cloud Angular setup take?
A prototype in 1–2 weeks, hardened in 2–4. If SSR or DR drills are required, add 1–2 weeks. We can start a discovery call within 48 hours and deliver an assessment in one week.
GitHub Actions vs Jenkins vs Azure DevOps—what should we use?
Use GitHub Actions for cloud‑native repos and OIDC, Azure DevOps when you need environments/approvals, and Jenkins for on‑prem or custom runners. All support parallel AWS/Azure/GCP deploys.
Do we need Nx to do this?
Nx isn’t required but highly recommended. It speeds builds, manages targets, and keeps workspaces sane. Angular CLI alone works; Nx adds caching, affected builds, and better monorepo ergonomics.

Ready to level up your Angular experience?

Let AngularUX review your Signals roadmap, design system, or SSR deployment plan.

Hire Matthew — Remote Angular Expert for Multi‑Cloud Delivery See NG Wave — 110+ Animated Angular Components (Signals, Three.js)

NG Wave

Angular Component Library

A comprehensive collection of 110+ animated, interactive, and customizable Angular components. Converted from React Bits with full feature parity, built with Angular Signals, GSAP animations, and Three.js for stunning visual effects.

Explore Components
NG Wave Component Library

Related resources