For teams already using Module Federation
Module Federation gives you loading. It does not give you versioning.
Module Federation lets a host application consume code from another build at runtime and share dependencies between them. What it deliberately leaves open is which version of which remote each environment should load. Most teams answer that with a remotes configuration committed to the host repository — and quietly put every micro frontend release back behind a host deploy.
MFE Orchestrator answers it with a versioned registry instead, and serves the configuration your host reads at startup. The mechanism stays; the manual bookkeeping goes away.
What static remotes cost you
The remotes map lives in the host
Remote URLs are declared in the host's bundler configuration and committed to the host repository.
Publishing a new version of any micro frontend requires a pull request, a build and a deploy of the host — the coupling micro frontends were supposed to remove.
Versions become URLs to remember
Version information ends up encoded in paths, in CI variables, or in whatever the last engineer decided.
There is no single answer to 'which version is in UAT right now', and rollback means reconstructing a URL from a commit history.
Every environment forks the configuration
DEV, UAT and PROD each need a different set of versions, so the configuration is duplicated per environment and drifts.
Configuration bugs surface only in the environment that has them, which is usually production.
Before and after
Static remotes, declared in the host
// webpack.config.js in the host — committed, so every
// version change is a host rebuild and a host deploy
new ModuleFederationPlugin({
name: "shell",
remotes: {
header: "header@https://cdn.example.com/header/2.1.0/remoteEntry.js",
checkout: "checkout@https://cdn.example.com/checkout/4.2.0/remoteEntry.js",
},
});Orchestrated remotes, resolved at runtime
// The host asks MFE Orchestrator what to load, per environment.
// Versions change in the console; the host stays exactly as it is.
{
"environment": "production",
"microfrontends": {
"header": { "version": "2.1.0", "entry": ".../header/2.1.0/remoteEntry.js" },
"checkout": { "version": "4.2.0", "entry": ".../checkout/4.2.0/remoteEntry.js",
"canary": { "version": "4.3.0-rc.1", "traffic": 10 } }
}
}Illustrative shape of the configuration served per environment. The exact integration for Webpack and Vite is in the documentation.
What you get on top of Module Federation
- A version registry. Every published build stays addressable, with a record of what was released when.
- Per-environment assignment. DEV, UAT and PROD serve different versions from the same registry, with no duplicated configuration.
- Canary releases. Shift a percentage of traffic to a new remote and raise it only when the numbers hold.
- Rollback as a version change. Select the previous version. No revert, no rebuild, no dependency on your pipeline's queue.
- Artifact storage you control. AWS S3, Azure Blob Storage, Google Cloud Storage, or on-premise.
- Shared dependencies handled. Common libraries are configured to load once and be reused, rather than bundled into each remote.