0Pricing
React Academy · Lesson

Independent Deployment & CI Pipelines for MFEs

Set up separate CI/CD pipelines so each micro-frontend deploys without coordination.

Independent Deployment & CI Pipelines for MFEs is a free React Academy lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the React Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

The Goal: Independent Deployment

Each micro-frontend should deploy independently without coordination from other teams. This requires separate repositories (or Nx/Turborepo), separate CI pipelines, and separate hosting.

Repository Strategies

Two approaches: Polyrepo (one repo per MFE, truly independent) and Monorepo (all MFEs in one repo, shared tooling with affected-based CI). Monorepo is often simpler to start with.

Remote Entry URL Strategy

Each MFE exposes a remoteEntry.js at a predictable URL. Deploy to a versioned path or use a manifest file for dynamic discovery.

// Versioned URL strategy:
https://cdn.example.com/products/1.2.3/remoteEntry.js

// Latest URL strategy (simpler, no host update needed):
https://cdn.example.com/products/latest/remoteEntry.js

// Dynamic manifest:
https://cdn.example.com/manifest.json
// { products: 'https://cdn.example.com/products/1.2.3/remoteEntry.js' }

GitHub Actions Pipeline for a Remote

A typical CI pipeline for a micro-frontend: test, build, upload to CDN, and optionally notify the host to update its manifest.

# .github/workflows/deploy.yml
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test
      - run: npm run build
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_KEY }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET }}
          aws-region: us-east-1
      - run: aws s3 sync dist/ s3://cdn-bucket/products/ --delete

Environment-Specific Remote URLs

Use environment variables in the host's webpack config or manifest to point to staging vs production remotes.

// Host webpack.config.js
const PRODUCTS_URL = process.env.PRODUCTS_REMOTE_URL ?? 'https://cdn.example.com/products/latest/remoteEntry.js';

new ModuleFederationPlugin({
  remotes: { products: `products@${PRODUCTS_URL}` },
});

Nx Affected for Monorepos

In an Nx monorepo, nx affected only builds and deploys the MFEs that changed, not all of them — saving CI time.

# Only build MFEs affected by the current PR
npx nx affected:build --base=origin/main
npx nx affected:test --base=origin/main

Contract Testing

When a remote changes an exposed module's API, consumers break. Contract testing (Pact) verifies the producer and consumer agree on the interface before deploying.

Canary Deployments

Deploy a new remote version to a small percentage of users first. Monitor error rates before promoting to all users — reduces the blast radius of breaking changes.

Rollback Strategy

Keep the previous remote version's remoteEntry.js on the CDN. A manifest update pointing back to the old version is all that's needed to roll back.

// Rollback: update manifest to previous version
await updateManifest({ products: 'https://cdn/products/1.1.0/remoteEntry.js' });

CDN Caching for Remote Entries

Set a short TTL (or no cache) on remoteEntry.js so hosts always pick up the latest version. Use long TTLs for versioned chunk files.

# CloudFront cache behavior:
# remoteEntry.js → Cache-Control: no-cache, max-age=0
# *.chunk.js     → Cache-Control: max-age=31536000, immutable

Smoke Tests Post-Deploy

Run a minimal Playwright smoke test after each deployment to verify the remote loads and renders correctly in the context of the shell.

Quick Check

What is the key advantage of using a versioned manifest file for remote URLs instead of hardcoding them in the host's webpack config?

Recap

Each MFE has its own CI pipeline: test → build → upload to CDN. Use versioned or manifest-based remote URLs for rollback capability. Set short cache TTL on remoteEntry.js for immediate pickup. In Nx monorepos, use nx affected to only deploy changed MFEs.

Frequently asked questions

Is the “Independent Deployment & CI Pipelines for MFEs” lesson free?

Yes — the full text of “Independent Deployment & CI Pipelines for MFEs” is free to read here on the web, and the React Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the React Academy course, upgrade to CoddyKit PRO.

What will I learn in “Independent Deployment & CI Pipelines for MFEs”?

Set up separate CI/CD pipelines so each micro-frontend deploys without coordination. You practise React Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start React Academy?

No prior experience is required. React Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Independent Deployment & CI Pipelines for MFEs” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this React Academy lesson?

Yes. Every React Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Micro-Frontend Concepts & Trade-offs
  2. Module Federation with Webpack 5
  3. Shared State & Routing Between MFEs
  4. Independent Deployment & CI Pipelines for MFEs
← Back to React Academy