Zero Downtime Deployments for React Micro Frontends Using AWS

Introduction

Micro-frontends allow large React applications to be divided into independently developed and deployed applications. However, independent deployment poses an important challenge: how can a new micro-frontend be released without breaking users who are still accessing the previous version?

A production-ready solution requires more than CI/CD. It needs immutable deployments, versioned assets, controlled releases, caching strategies, backward-compatible APIs, and fast rollback.

AWS services such as Amazon S3 and Amazon CloudFront provide a strong foundation for this architecture.

Why Traditional Deployment Strategies Break

A traditional React application commonly follows:

User → CloudFront → S3 → React Application

Deployment usually means building the application and replacing existing files in S3.

With micro-frontends, the architecture is different:

Shell → Product MFE / Checkout MFE / Account MFE / Search MFE

Each micro-frontend can have its own repository, CI/CD pipeline, release version, team, dependencies, and deployment lifecycle.

Problems occur when different versions of assets are being served simultaneously. For example, the shell may reference product-v2.js while CloudFront or an existing user still expects product-v1.js.

This can result in users receiving incompatible combinations of old and new assets.

The Core Principle: Immutable Deployments

The first rule should be:

Never overwrite deployed frontend assets.

Instead of:

/products/main.js

use versioned releases:

/products/
/v1.8.0/
main.js
styles.css
/v1.9.0/
main.js
styles.css
The same approach should be used for every micro-frontend:

/mfe/product/1.4.2/
/mfe/product/1.4.3/

/mfe/checkout/2.1.0/
/mfe/checkout/2.2.0/
This ensures old versions remain available while new versions are deployed.

If a user has already loaded version 1.4.2, it can continue working even after 1.4.3 is released.

That is the foundation of zero-downtime deployment.

AWS Architecture

A production architecture can use:

Route 53 → CloudFront → S3 → React Shell + Micro-Frontends

Each micro-frontend can have an independent pipeline:

Git Repository → CI/CD → Build → Test → Upload Versioned Assets to S3 → Validation → Release

CloudFront provides global caching and low-latency delivery, while S3 stores the immutable frontend assets.

An important additional component is the release manifest.

Use a Version Manifest

Instead of hardcoding micro-frontend versions, the shell can consume a release manifest:

{
“product”: “https://cdn.example.com/product/1.9.0/remoteEntry.js“,
“checkout”: “https://cdn.example.com/checkout/2.2.0/remoteEntry.js“,
“account”: “https://cdn.example.com/account/3.1.0/remoteEntry.js”
}
The shell determines which version should be loaded.

This separates deployment from activation.

Uploading version 1.9.0 does not automatically expose it to users.

The process becomes:

Build → Upload → Test → Validate → Activate

A deployment means the code exists. A release means users can receive it.

Two-Phase Deployment

A safer deployment can be divided into two phases.

Phase 1 — Publish

Upload the new version to S3:

/product/1.9.0/

while production continues using:

/product/1.8.0/

Automated tests can validate JavaScript loading, routing, authentication, API compatibility, browser compatibility, and critical user journeys.

Phase 2 — Activate

After successful validation, update the release manifest:

product → 1.9.0

instead of:

product → 1.8.0

Users can now receive the new release without replacing the previous assets.

Handle CloudFront Caching Correctly

Amazon CloudFront caching needs to be designed around asset types.

Immutable assets such as:

/product/1.9.0/main.js

can have a long cache lifetime because their URLs never change.

The release manifest, such as:

/releases/manifest.json

should have a shorter cache lifetime because it determines which version is active.

The pattern is:

Immutable Assets → Long Cache

Release Metadata → Short Cache

This avoids constantly invalidating large numbers of JavaScript files.

Backward-Compatible APIs

Zero-downtime deployment is not only a frontend concern.

Imagine that frontend v2 requires a new API while some users are still running frontend v1.

If the backend immediately removes the old API contract, existing users can break.

A safer approach is:

API v1 + API v2 → MFE v1 + MFE v2

Keep old contracts available during the transition.

This is commonly known as expand-and-contract deployment:

Expand → Support Old + New → Deploy New Frontend → Move Traffic → Monitor → Remove Old Contract

This is particularly important because frontend and backend deployments often happen independently.

Canary Releases

You do not always need to expose a new micro-frontend to 100% of users immediately.

For example:

95% → v1.8

5% → v1.9

Monitor JavaScript errors, API failures, performance, authentication failures, and client-side exceptions.

If the release remains healthy:

5% → 25% → 50% → 100%

If problems appear, roll back to the previous version.

Because the old version still exists, rollback can be extremely fast.

Instant Rollback

A strong micro-frontend architecture should make rollback simple.

Suppose the current release is:

product → 1.9.0

And errors suddenly increase.

Instead of rebuilding the application, change the manifest:

product → 1.8.0

There is no need for compilation, asset replacement, or an emergency build.

The previous version is already stored in S3 and can continue to be served through CloudFront.

Versioning the React Shell

The React shell should follow the same immutable deployment model.

Instead of:

/shell/latest/

use:

/shell/2026.08.25.01/
/shell/2026.08.25.02/
A release configuration can define a known-good combination:

{
“shell”: “2026.08.25.02”,
“microfrontends”: {
“product”: “1.9.0”,
“checkout”: “2.2.0”,
“account”: “3.1.0”
}
}
This creates a frontend release graph in which the shell and micro-frontends are tracked as compatible versions.

CI/CD and Compatibility

A mature pipeline can follow:

Developer Push → Build → Unit Tests → Integration Tests → Upload Immutable Assets → Contract Tests → E2E Tests → Security Checks → Canary Release → Observability → Activate

AWS services such as CodePipeline and CodeBuild can orchestrate these stages, while S3 and CloudFront handle artifact delivery.

However, the most important part is the release model and compatibility strategy, not the individual AWS service.

Teams should define compatibility contracts covering:

• Exposed modules
• Expected props
• Events
• Shared dependencies
• API expectations
• Supported shell versions

Testing individual micro-frontends is not enough. Teams must also test valid combinations of shell and micro-frontend versions.

Conclusion

A reliable zero-downtime strategy for React micro-frontends is fundamentally about controlling versions and separating deployment from release.

Using immutable S3 assets, CloudFront caching, release manifests, backward-compatible APIs, canary releases, and instant rollback enables teams to deploy independently without involving users in the deployment process.

The goal is not simply to deploy faster. It is to make every deployment safe, observable, reversible, and predictable.

Drop a query if you have any questions regarding React Micro-Frontends, and we will get back to you quickly.