Versioning, Deployment, and Orchestration

Module Federation's primary value is independent deployment: a team can update, test, and deploy their remote without coordinating with host teams or triggering host redeployments. The host picks up changes automatically the next time it loads remoteEntry.js from the remote's URL.

Instead of serving remoteEntry.js at a fixed URL (which changes on every deploy), include a content hash in the URL: remoteEntry.[hash].js. This makes each deployment immutable — old URLs continue working, and the host references the new hash once it is updated to the new deployment. Immutable URLs enable aggressive CDN caching.

Because the host discovers remotes via URL, you can implement A/B testing at the infrastructure level: serve different users different remoteEntry.js URLs (pointing to different remote versions). This enables true canary deployments for micro-frontends without any feature flag logic in the application code.

Instead of hardcoding remote URLs in the Webpack config, the host fetches a JSON manifest at startup: GET /federation-manifest.json returns { buttonApp: 'https://cdn.example.com/button/remoteEntry.abc123.js' }. To update which version the host uses, update the manifest — no host rebuild required.

When a remote deployment introduces a regression, rollback is instant: update the federation-manifest.json to point to the previous remoteEntry.js URL. The host immediately starts using the old version on the next request cycle. No host rebuild, no host rollback, no coordination needed.

Module Federation 2.0 (the @module-federation/enhanced package) adds significant improvements: better TypeScript support with automatic type generation from remote manifests, runtime plugin API for custom loading logic, and enhanced shared scope management for complex version negotiation scenarios.

The vite-plugin-federation package brings Module Federation to Vite-based projects, using a similar configuration API to Webpack's ModuleFederationPlugin. It is compatible with both Vite remotes and Webpack hosts (and vice versa), enabling teams to migrate to Vite incrementally without abandoning Module Federation.

For highly dynamic architectures, you can configure remote URLs entirely at runtime: import(remoteRegistry[featureName]) where remoteRegistry is populated by an API call. This enables plugin-like architectures where new micro-frontends can be added without any rebuild of the shell application.

The shell application's primary job is orchestration: it reads the remote manifest, initializes Module Federation's runtime, registers remote modules under named routes, and renders the appropriate remote based on the current URL. The shell is intentionally thin — it knows what to load, not how to render it.

Add performance monitoring to remote loading: wrap remote imports in try/catch to handle loading failures gracefully (render a fallback UI if the remote is unavailable), measure the time to download remoteEntry.js and component chunks, and alert if remote load time exceeds a threshold (indicating CDN issues).

A mature Module Federation CI/CD pipeline looks like: remote team commits → CI builds remote → uploads immutable remoteEntry.[hash].js to CDN → updates federation-manifest.json → host picks up new remote on next user request. Each step is automated and the host team is never involved in remote deployments.

What is the fastest way to rollback a bad Module Federation remote deployment?

Module Federation enables true independent deployment: remotes deploy without host rebuilds, the host discovers new versions automatically. Use content-hashed remote URLs for immutable CDN caching and a dynamic manifest for flexible version routing and instant rollbacks. vite-plugin-federation brings these capabilities to Vite, and dynamic remote imports enable plugin-like architectures. The shell orchestrates remote loading, keeping itself intentionally thin.