DEV Community: MFEOrchestrator

One build, every environment: runtime configuration for micro frontends

MFEOrchestrator — Thu, 08 Oct 2026 08:10:13 +0000

Look at your pipeline. If it builds staging and production separately from the same commit, you are shipping an artifact nobody tested. You tested the staging one.

Most of the time this is fine, right up until the day it is not — a variable spelled differently in one environment, a flag that defaulted the other way, a bundle that behaved because of something only the staging build had. The bug appears in production only, and the investigation starts with the least useful sentence in software: it works on staging.

Why does each environment get its own build?

Because the configuration is inside the bundle. Somewhere in the code there is an API base URL, a feature flag, a tenant id, and at build time a bundler replaced it with a literal string. Change the value, and you have changed the bundle, so you build again.

For a single application this is merely wasteful. For micro frontends it compounds: every micro frontend, times every environment. Five micro frontends and three environments is fifteen builds of code that was identical in all fifteen.

What does it actually cost?

The test result stops transferring. Whatever CI proved about the staging artifact, it proved about that artifact. The production one was built later, separately, from configuration nobody exercised.
Promotion becomes a rebuild. Moving a version from staging to production is not a promotion any more, it is a new build — with a new chance to fail, on the day you least want one.
Rollback gets slower. The old artifact for this environment may not exist any more. If it does not, rolling back means building it again, which means the rollback is a deploy.
Configuration drifts silently. Three sets of environment variables in three places, and no single view of what actually differs. The drift is invisible until it is an incident.

What does runtime configuration actually mean?

It means the bundle contains no environment-specific value at all. Instead, on startup, the application asks for them and gets back a small document — a plain JSON object with the API base URL, the flags, whatever else differs.

The bundle is then genuinely identical everywhere. The same file, the same hash, the same artifact that CI tested, served to staging and production alike. What differs between environments is one document, and that document is data rather than code.

How does the browser get the configuration?

The host fetches it before it mounts anything. In practice this is one request early in the boot sequence, its result handed to whatever the application uses for configuration, and only then does rendering start.

Two details are worth getting right. Keep the response small, because it sits on the critical path of the first paint. And keep the cache short — a configuration cached for an hour at the edge is a configuration you cannot change for an hour, which quietly undoes the point.

What about secrets?

There are none here. Anything the browser can read is public, whether it arrived in a bundle or a JSON document: a value shipped to a client is a published value. Runtime configuration changes when a value is decided, not who can see it.

What belongs in it is the non-secret configuration that varies: base URLs, public keys, feature flags, tenant identifiers. Anything genuinely secret stays on a server that never hands it to a browser, exactly as before.

Does this work with Vite and Webpack?

Yes, and the change is the same shape in both, because it is not really a bundler change. You stop reading import.meta.env or process.env at module scope and start reading a value that was fetched. The bundler stops being involved the moment the value is no longer inlined.

The one thing that does stay at build time is the set of remote names in a Module Federation setup. Names are structural. The URLs behind them are not, and those can come from the same document as everything else.

What does this have to do with rollback?

Everything, and it is the same mechanism. Once an environment is described by a document rather than by a build, changing what an environment serves is a write, not a deploy. That is what makes a thirty-second rollback possible, and it is why the two are worth doing together: one build for every environment is the thing that makes the old artifacts still exist when you need them.

Build once, test that one, run it everywhere. The configuration is the only thing that was ever environment-specific — so it should be the only thing that varies.

How to Ship Canary Releases for Microfrontends Without Losing Your Mind

MFEOrchestrator — Thu, 08 Oct 2026 08:10:09 +0000

TL;DR: Canary releases let you test new microfrontend versions on a slice of your traffic before going full rollout. Most teams build custom tooling for this. You don't have to.

The Problem With Shipping Microfrontend Updates

You've just merged a feature to your microfrontend. It's tested locally, it passed CI. Now what?

In monolithic architectures, you'd just deploy and move on. But with microfrontends, you're running multiple independently-deployed remotes feeding into a host application. Each one can fail independently. And unlike a full-app rollout, you can't easily A/B test a new MFE version before pushing it live to everyone.

So most teams end up building their own solution:

Custom feature flags that toggle versions per user (adds complexity to your MFE code)
Manual traffic splitting logic (now you're maintaining deployment state)
Sticky session routing (sessions need to stick to the same MFE version, otherwise users jump between old and new)
Monitoring and rollback procedures (when things go wrong at 2 AM, you need a fast way out)

It's operational debt masquerading as a deployment strategy.

What Is a Canary Release, Anyway?

A canary release is a progressive rollout pattern: instead of flipping a switch and serving the new version to everyone, you start by serving it to a small percentage of your traffic (5–10%), then gradually increase that percentage as you confirm it's stable.

The name comes from mining: canaries were sent into mines as an early warning system. Same idea—your early users are the canary. If they have problems, you catch them before the entire flock is affected.

Canary vs. Other Deployment Strategies

Strategy	What happens	Best for
Blue-green	Two identical production environments; you flip traffic from one to the other	Zero-downtime deployments; rollbacks are instant
Rolling update	Gradually replace old instances with new ones	Stateless services; works fine in containers
Canary release	Route a percentage of traffic to the new version; increase % over time	Testing new features safely; catching runtime errors early
Feature flags	Toggle features on/off at runtime; doesn't change the deployed version	A/B testing; feature experiments; gradual enablement

Why Canary Releases Are Harder for Microfrontends

Three reasons:

1. Traffic Routing is Complex

In a traditional app, you control the load balancer. Route 10% of requests to the new version, boom, done.

With microfrontends, your host application doesn't know (and shouldn't need to know) which version of each remote it's loading. The host just asks for the MFE, and some service returns a URL. If you want different users to get different versions, you need:

Sticky session management (so the same user always gets the same version across multiple page views)
Per-microfrontend decision-making (you might canary version 2.1 of the checkout MFE while keeping the header MFE at 1.0)
Server-side traffic splitting logic (handled entirely server-side; the host page shouldn't be aware of the split)

2. Versioning is Invisible

In monolith-land, a deploy is a deploy. You know exactly what version is running.

With MFEs, multiple versions might be running simultaneously, and users won't notice the transition. If a user's session spans a canary increase (e.g., they were at 5% when they loaded the page, then 10% of new users got the new version), they might end up on different versions mid-session if you're not careful.

3. Rollback Must Be Instant

If a canary goes bad, you need to stop the bleeding immediately. Rolling back a traditional deployment means re-running CI/CD or reverting to a previous Docker image. That's 5–15 minutes.

With microfrontends, users might cache the new version. You need a way to instantly point all canary traffic back to the stable version—without re-deploying anything.

The Traditional DIY Approach (What You're Probably Doing)

Here's what most teams build:

# Pseudo-code: your custom canary logic
if user.id % 100 < canary_percentage:
  serve(mfe_version_new)
else:
  serve(mfe_version_stable)

Then you add:

A database table tracking canary_percentage, start_time, version_new, version_stable
A dashboard UI to adjust the percentage
Webhooks to trigger when the canary percentage changes
Metrics/logging to track how the canary is performing
Runbooks for what to do if the canary fails

Cost: 2–3 weeks of development. Ongoing maintenance: 30% of one engineer's time.

The Better Way: Native Canary Releases

A better approach is to build canary releases into your MFE orchestration layer—the service that decides which version each user gets.

Here's what that looks like:

Step 1: Enable Canary for a Microfrontend

Open the microfrontend in your control panel. Under Release, you'll see Canary Settings. Toggle it on.

Step 2: Configure the Canary

You'll be asked for:

Canary percentage - What % of new users get the new version? 10%
Canary type - How do you want to split traffic? Sticky (per-user)
Canary version - Which version is the canary? 1.2.0-beta
Deployment type - Should the new version be deployed fresh, or just routed to? Use existing deployment

Step 3: Monitor

Watch your metrics. Error rates, session duration, user feedback—whatever tells you if the canary is healthy.

Step 4: Increase the Percentage

As confidence grows, increase the percentage. 10% → 25% → 50% → 100%.

Or if something goes wrong: instant rollback. Flip the percentage back to 0%, and all traffic goes back to the stable version. No re-deploy. No cache-busting. Just a config change.

How MFE Orchestrator Handles This

If you're using MFE Orchestrator, canary releases are built in. Here's the workflow:

Deploy a new version of your MFE. Push to your repository; MFE Orchestrator detects the build and creates an immutable snapshot.
Enable canary in the UI. One toggle. Four fields. That's it.
Watch metrics. The orchestrator captures deployment events and canary outcomes.
Increase or rollback. Adjust the percentage via the UI. Changes are instant; no CI/CD re-run required.

Why This Works

MFE Orchestrator makes three bets:

Immutable deployment snapshots: Every version is locked in time. Rollback doesn't mean "re-run the build"; it means "point to a previous snapshot." Instant. ~30 seconds.
Server-side sticky assignment: The decision about which version you get is made entirely server-side. The host page doesn't need to know or care. Sticky by default, so the same user always gets the same version within a session.
Per-microfrontend decisions: You canary one MFE without affecting others. Checkout at 2.0, header at 1.5, and they work together seamlessly.

Step-by-Step Walkthrough: Setting Up Your First Canary

Let's say you've deployed a new version of your payment-mfe (v2.0). It's tested locally, but you want to be cautious before sending it to all 500K daily users.

Before You Start

You have a stable version running (v1.5). Keep it as your baseline.
You have a new version ready to test (v2.0). It's built, versioned, and deployed to your hosting.
You're using an MFE orchestration layer (MFE Orchestrator, qiankun, single-spa + a custom control plane, etc.).

The Walkthrough

1. Navigate to your payment-mfe in the control panel.

Look for the Release section. You'll see the current version (v1.5) and a Canary Settings toggle.

2. Enable Canary Settings.

Toggle the switch. A form appears asking for:

Canary percentage: Start small. 5%.
Canary type: Choose "Sticky per-user" (same user always gets the same version).
Canary version: Select v2.0.
Deployment type: "Use existing deployment" (v2.0 is already deployed).

3. Click Save.

The orchestrator immediately starts routing 5% of traffic to v2.0. The other 95% gets v1.5.

4. Deploy another version

Go to the deployment panel and hot Deploy button

5. Monitor for the next 30 minutes.

Watch your error logs, session analytics, and user feedback. Is v2.0 crashing? Are cart completions still happening? Any JavaScript errors in the console?

If everything looks good: continue to Step 5.
If something breaks: immediately set canary percentage to 0%. Rollback is instant.

6. Increase the percentage.

After 30 minutes of green metrics, bump the canary to 10%. Wait another 30 minutes. Then 25%. Then 50%.

By the time you hit 100%, v2.0 is serving all traffic, and v1.5 is no longer in the critical path.

7. Turn off Canary Settings.

Once you're at 100%, you can either:

Let the canary run indefinitely (keeps a fallback to v1.5 if v2.0 ever fails)
Disable canary and make v2.0 the stable release

Common Pitfalls

Pitfall 1: Canary % Doesn't Add Up to 100%

If your canary is at 10% and your stable version is at 90%, where do the other 0% go?

They don't. The math always works out: if canary is at X%, stable is at (100 - X)%.

Pitfall 2: Jumping to 100% Too Quickly

It's tempting. Your canary looked good for 5 minutes. Ship it to everyone!

Resist. Wait for real usage patterns. Weekday traffic looks different from weekends. Mobile usage differs from desktop. Edge cases take time to appear.

Recommendation: Increase by 1-2x every 30–60 minutes, depending on your traffic volume.

Pitfall 3: Not Monitoring the Right Metrics

Canary health isn't just about "no errors." Also watch:

Error rate: Obvious, but watch for slow increases (not just crashes).
Response time: Did v2.0 get slower?
User engagement: Are users dropping off? Completing transactions?
Browser console errors: v2.0 might have script errors that don't crash but hurt UX.

Pitfall 4: Forgetting to Test the Rollback Path

You've decided canary is the way to go. But have you practiced rolling back? Setting percentage to 0% should be fast and painless. Do a drill.

When Not to Use Canary Releases

Canary releases are powerful, but they're not always the right choice:

Breaking changes to your MFE contract: If v2.0 changes how remotes communicate with the host, canary won't help. You'd need to coordinate a host deployment first.
One-off hotfixes: If you're patching a critical bug and need it live in 60 seconds, canary adds no value. Just deploy and monitor closely.

For most feature updates and optimization work, though? Canary is your friend.

The Payoff

Here's what canary releases buy you:

✅ Catch bugs before they hit all users
✅ Roll back in seconds, not minutes
✅ Test real production traffic (not synthetic)
✅ Gradual confidence building
✅ Less stress

That last one is underrated. Knowing you can safely test a new version on 5% of your users, then roll back with one click if something breaks—that's peace of mind.

TL;DR: The Canary Release Checklist

[ ] You have a stable version (v1.5) running for all users.
[ ] You have a new version (v2.0) built, tested, and deployed.
[ ] You've enabled Canary Settings and set percentage to 5%.
[ ] You've monitored error rates, response times, and user behavior for 30 minutes.
[ ] You've increased percentage to 10%, then 25%, then 50%, waiting 30 minutes between each.
[ ] At 100%, you've decided: keep the canary active (as a rollback safety net) or disable it.
[ ] You've documented the rollout (when you increased %, what metrics you watched, any issues that came up).

Next Steps

If you're doing this manually today: You're probably maintaining custom feature flag logic, a dashboard to track canary %, and a runbook for rollbacks. That's fine—it works. But it's friction.

If you want to reduce that friction: Look into an MFE orchestration layer that handles canary natively. MFE Orchestrator is one option. The benefit: canary releases become a 30-second UI interaction instead of a custom integration.

Either way, canary releases are your best tool for safe, confident microfrontend deployments.

Deterministic AI Agents in Mission-Critical Systems: Why Microfrontend Boundaries Matter

MFEOrchestrator — Thu, 08 Oct 2026 08:10:04 +0000

You've deployed an LLM agent to production to automate customer workflows. It's trained on your entire codebase, your entire state tree, your entire API surface. It works. Then it doesn't. It hallucinated a payment endpoint. It mutated shared state. The entire system broke.

Now imagine the same agent, but it can only see—and touch—a single bounded domain: the checkout flow. Same intelligence. Zero blast radius.

That's what microfrontend boundaries do for AI reliability.

The Determinism Problem: Why AI + Mission-Critical = Danger

Mission-critical systems live on a knife's edge. A payment system cannot fail. A healthcare workflow cannot guess. A financial settlement engine cannot hallucinate. These systems run monoliths or tightly-coupled architectures because the engineers who built them needed predictability—the certainty that, given X input, you get Y output, and nothing breaks state elsewhere.

Then we introduced LLM agents.

The promise is seductive: deploy an intelligent agent to automate entire business processes. Let it read your API docs, understand your domain, make decisions. But here's what actually happens:

State explosion. Your agent sees the entire application state tree. It has access to every domain, every service, every possible side effect. The surface area for error isn't just the agent's logic—it's the agent's logic multiplied by the complexity of your entire system.

Hallucination risk scales with scope. The more context an agent has, the more ways it can misinterpret that context. It reads a deprecated API endpoint and decides it's the primary one. It confuses a state variable in Module A with the similar one in Module B. The system is now in a broken state, and your entire platform is down.

Blast radius = system blast radius. If your agent goes wrong, and it can touch anything, it can break anything. Traditional unit tests and integration tests miss this because they test code, not agent decision-making under uncertainty. Your mission-critical system is now dependent on the stability of an AI model, not just your code.

Mission-critical environments demand determinism. They demand predictability. They demand architectural safety.

The Unbounded AI Agent: Today's Default Pattern

This is how most teams deploy AI agents today:

LLM Agent
    ↓
Full App Context (entire state tree, all APIs, all domains)
    ↓
Mission-Critical System (payment, auth, data warehouse, etc.)

Why? It's easier to implement. A single agent with unrestricted context is simpler to build than a scoped, boundary-aware one. You write fewer prompts. You deal with fewer API contracts. And in the early phases, it works.

Then you go to production.

The agent starts making decisions based on patterns it learned from your entire codebase. It mutates state it wasn't supposed to touch. It triggers side effects in systems it didn't know existed. Your tests pass. Your deployment succeeds. And six hours later, customer transactions are failing silently.

The real cost isn't the agent's intelligence—it's the agent's reach. An intelligent system with access to your entire platform is more dangerous than a dumb system with the same access. Because it will find edge cases, race conditions, and state inconsistencies that humans never thought to test.

Microfrontend Boundaries as AI Safety

Here's what most teams don't realize: microfrontend architectures solve this problem by accident.

In a microfrontend system, each frontend module is a bounded domain. It has its own state management. It has its own API surface. It has an explicit contract with the rest of the system. The module doesn't see global state. It doesn't call arbitrary endpoints. It operates within a defined perimeter.

Now scope your AI agent to that same perimeter.

An agent running inside the checkout MFE:

Can only see checkout state
Can only call checkout APIs
Can only modify checkout flows
If it breaks, it breaks checkout—not the entire system

That's the pattern: agent boundary = MFE boundary.

The blast radius shrinks from "entire platform" to "single domain." Failure becomes containable. Recovery becomes predictable. Your mission-critical system survives.

Monolith vs. MFE-Scoped Agent: The Safety Trade-off

Aspect	Monolith + Unbounded Agent	MFE + Scoped Agent
Context Surface	Entire system state + all APIs	Low (limited context = fewer interpretations)
Hallucination Risk	High (misinterpreting global patterns)	Low (limited context = fewer interpretations)
Blast Radius	System failure	Single MFE failure
Rollback Scope	Entire deployment	Single MFE (instant)
Testing Determinism	Hard (agent behavior influenced by global state)	Easy (agent behavior bounded by MFE contract)
On-call Wake-up Risk	3 AM page for "agent broke everything"	Page only if checkout is down

The trade-off is real: you lose some agent flexibility. It can't orchestrate across five systems. But you gain something more valuable: operational predictability in mission-critical systems.

Determinism Through Architectural Isolation

Bounded state isn't just safer—it's more predictable.

When an agent's context is limited to a single MFE, its behavior becomes testable. You can:

Enumerate the state space. "What are all possible checkout states?" is answerable. "What are all possible system states?" is not.
Define the API contract. "These are the three operations the agent can perform," not "the agent can call anything."
Predict failure modes. You can reason about what happens when the agent misinterprets checkout data, because checkout data is bounded.

Determinism here means: given the same input, the same external conditions, and the same AI model, the agent will behave consistently. It won't have unexpected interactions with unrelated systems. It won't mutate state it wasn't supposed to touch.

In mission-critical systems, determinism is survival.

And when something does break—because it will—you can roll back instantly. Not the entire deployment. Not a ten-minute redeploy cycle. A single MFE, rolled back to the previous snapshot in 30 seconds.

The Infrastructure Layer: Deployment Reliability for AI

But there's a prerequisite: your microfrontend architecture needs to support instant rollback and canary releases.

This is where many teams fail. They have MFEs, but they can't deploy them independently. They can't roll back a single remote without touching the host application. They can't test a new agent version against 5% of users before the full rollout.

When your agent needs to be deployed, tested, and potentially rolled back—in production—you need deployment infrastructure that understands MFE semantics. Infrastructure that treats each MFE as an independently deployable unit with its own release cycle.

Orchestration of microfrontends isn't just about composition anymore. It's about supporting the operational requirements of AI-driven systems: rapid iteration, bounded scope, instant recovery.

Practical Checklist: Making Your Agents Deterministic

If you're running AI agents in a mission-critical environment, use this checklist:

Define agent scope = MFE boundary
- Which single MFE will the agent operate within?
- Does the agent's use case fit entirely inside that boundary?
- If no, reconsider scoping or multi-agent orchestration.
API contract = agent contract
- Document the exact APIs the agent can call (all of them)
- Document the exact state the agent can read (all of it)
- Make this contract explicit in prompts and system design
State isolation validation
- Can the agent accidentally mutate state outside its MFE?
- Are there shared data structures it might corrupt?
- Test this explicitly; don't assume architectural isolation.
Monitoring + rollback triggers
- Define what "agent went wrong" means for your domain (e.g., checkout completion rate drops 5%)
- Set up automated rollback triggers
- Test rollback in staging; verify it's actually fast
Canary release for agent versions
- Deploy new agent versions to 5% of users first
- Monitor domain-specific metrics, not just error rates
- Rollback immediately if metrics degrade
- Graduate to full rollout only after confidence period
Runbook for agent failure
- What do you do when the agent breaks?
- Who gets paged? When?
- How long does recovery take?
- Practice this in a staging environment.

Conclusion: Determinism as Architecture

The era of unbounded AI agents in production is ending. The era of scoped, boundary-aware, deterministic agents is beginning.

Microfrontend architectures give you the natural boundaries you need. They give you the architectural safety that mission-critical systems demand. But only if you treat them as such: not just as a way to split your frontend, but as a way to architect AI reliability.

Your agents are smarter than your code. They're also more unpredictable. Give them constraints. Give them boundaries. Give them MFE isolation.

Your mission-critical system will thank you when the agent's decision doesn't break the entire platform.

Module Federation with Vite in production: what changes

MFEOrchestrator — Thu, 08 Oct 2026 08:10:00 +0000

Module Federation started in Webpack, and for years that is where it stayed. It works on Vite now, through @module-federation/vite, and works well — but Vite's dev server and Vite's build are two different machines, and Module Federation has to satisfy both. Most production surprises live in that gap.

Does Module Federation actually work with Vite?

Yes. The plugin exposes the same concepts you already know — a host, remotes, exposes, shared dependencies — and a remote built by Vite can be consumed by a host built by Webpack, and the other way round. The container contract is what travels, not the bundler.

What differs is what happens underneath, and the honest summary is that Vite's dev server does not bundle. It serves native ES modules and transforms on demand. The build does bundle, through Rollup. So the code you exercise all day and the code you ship take different paths through the toolchain.

What breaks in production that worked in dev?

Dependency deduplication. In dev, the browser resolves modules and duplicates are cheap to miss. In the build, sharing is negotiated for real, and a shared library that was silently loaded twice becomes either a singleton conflict or a bundle that ships React more than once.
Module initialisation order. The dev server's on-demand transform can hide an import cycle that the bundled output makes fatal.
Missing externals. A dependency present in dev because something else pulled it in can be absent from a remote's build, and only fails when that remote is loaded — which may be a route most people never open.

None of these are Vite defects. They are the ordinary difference between resolving modules in a browser and linking them ahead of time — Module Federation simply gives that difference more surface.

How should you handle shared dependencies?

Share deliberately and share little. Everything that must be a singleton — the framework runtime, the router, whatever holds global state — should be shared and marked as such. Everything else is usually cheaper duplicated than coordinated.

The failure worth naming: a shared dependency with a loose version range across several independently released micro frontends means the singleton in production is whichever version happened to load first. That is not a configuration you chose; it is a race you are hosting.

Where do the remote URLs come from?

In most tutorials, from the bundler config — an object literal mapping each remote to a URL, committed to the host repository. It is the shortest thing that works, and it is also the decision that ends up costing the most.

Because that literal is the thing that has to change when you release. A new version of one remote means editing the host's config, rebuilding the host, and redeploying the shell — for a change that happened entirely somewhere else. It is the same trap described in the piece on composition versus deployment, and Vite does not change it either way.

The fix is not Vite-specific either: generate that map instead of writing it, from configuration fetched at runtime. The remote names stay in the build, because names are structural. The URLs do not have to.

What should you check before shipping?

Build every remote and load them from a built host, not the dev server. This is the single check that catches most of the list above.
Inspect the output for duplicated framework copies. If React appears twice, sharing is not doing what you think.
Pin shared dependency versions across micro frontends, or accept that the singleton is decided by load order.
Open every route that lazily loads a remote. A remote that is never loaded in testing is a remote that was never tested.
Confirm the remote URLs are resolved at runtime, so a release does not require rebuilding the host.

Module Federation on Vite is production-ready. It is the assumption that the dev server tells you what production will do that is not.

Federation Solved Composition. Nobody Solved Deployment Reliability

MFEOrchestrator — Thu, 08 Oct 2026 08:09:57 +0000

Why your microfrontend framework isn't solving your biggest operational problem—and what you're missing

The Conversation I Keep Having

Over the past five years, I've had the same conversation with dozens of engineering teams, over and over:

Them: "We're adopting Module Federation. Our team just shipped three new MFEs last quarter. Deployment velocity is great."

Me: "Nice. How long does a rollback take?"

Them: pause "Uhh... if something goes wrong, we have to rebuild the entire frontend, run the pipeline, and redeploy. Maybe 10–15 minutes?"

Me: "And canary releases?"

Them: longer pause "We built custom tooling for that. It's... fragile. Each team has their own version."

The pattern is consistent: Every team we talk to is strong on composition and weak on operational reliability.

What Happened: Federation Won, Then Stopped

Module Federation (Webpack, Vite, others) solved a real problem: How do you compose independent frontend modules at runtime?

The answer was elegant:

Build each MFE independently
Define public contracts (shared dependencies, APIs)
Load at runtime via manifest
Compose at the URL/slot level

Problem solved. Netflix, Meta, Shopify, Airbnb—all operating at scale with federation frameworks. Modern, modular, clean architecture.

But here's what federation didn't solve:

The Unsolved Problem: Safe, Fast Deployment

Federation is about composition. It doesn't say anything about orchestration.

Think about it:

Composition: "Which modules load in which slots, and how do they communicate?"
Orchestration: "How do we deploy module versions safely, roll them back, and monitor what's happening?"

These are different problems. Federation frameworks are optimized for the first. The second? You're on your own.

What That Looks Like in Practice

Here's a typical MFE deployment workflow today:

1. Developer commits fix to MFE "Checkout"
2. CI/CD pipeline triggers (full frontend build, not just Checkout)
3. Webpack builds all MFEs: 3–5 minutes
4. Artifacts pushed to CDN/registry
5. Deployment triggers (frontend reconciliation, cache invalidation)
6. Live. Total time: 10–15 minutes.

If something breaks mid-deployment:
   → Rebuild, redeploy. Same 10–15 minutes to rollback.

Meanwhile, in the backend:

1. Developer commits fix to a service
2. CI/CD pipeline triggers (just that service)
3. Build: 1–2 minutes
4. Artifact pushed
5. Kubernetes rolling update: ~30 seconds
6. If bad: rollback to previous version: ~30 seconds
7. Total MTTR: minutes (not from scratch; pre-built versions exist)

The backend learned decades ago: Decouple building from deploying. But the frontend never got that memo.

Why This Matters (Beyond Speed)

It's not just about milliseconds. Slow deployments create operational debt:

1. Every team builds custom rollout tooling

Since federation doesn't give you canary releases, each team invents their own:

Hand-rolled traffic shifting (5% → 25% → 100%)
Custom health checks and dashboards
Manual rollback logic
Feature flags scattered across codebases

Result: Fragile, team-specific, expensive to maintain.

2. All-or-nothing deployments

A fix in "Checkout" forces you to rebuild and redeploy the entire frontend. Yes, you have module federation, but without a safe deployment layer, you lose the granularity it promises.

Risk profile: One small bug in one MFE can take down your whole frontend.

3. Incident response becomes firefighting

A production incident at 2 AM. Your Checkout MFE is leaking memory. Do you:

Wait 15 minutes for a full rebuild and redeploy?
Revert the entire frontend (losing unrelated deploys from the last hour)?
Blame the framework and move on?

Most teams do a combination of all three.

4. Platform engineering scales poorly

As you add more MFEs, the coordination overhead grows:

More teams building custom deployment logic
More manual orchestration between deployments
More incidents caused by timing/coordination bugs
More time spent on toil instead of features

Federation and Orchestration Are Different

Let me be direct: This isn't a federation framework problem.

Federation frameworks are doing what they're designed to do—composing modules at runtime. The problem is that the industry conflates "I have module federation" with "My frontend deployment is reliable."

These are separate concerns:

Question	Federation Answers	Orchestration Answers
"How do I load modules at runtime?"	✅
"How do I deploy a module version safely?"		✅
"How do I roll out a change gradually?"		✅
"How do I rollback quickly?"		✅
"How do I know what's deployed?"		✅

You need both. Federation for composition. Orchestration for safe deployment.

Right now, most teams have federation. They're building orchestration ad-hoc, per-team, with custom code.

The Kubernetes Parallel (and Why It Doesn't Apply)

Some teams say: "Why not just use Kubernetes for the frontend?"

Valid question. Kubernetes is extraordinary for orchestration—but at the container level. It operates on:

Pods (not components)
Replica sets (not versions)
Rolling updates (not canary with business metrics)

So when you apply Kubernetes thinking to the frontend, you get:

Container per MFE? Now every MFE is a "service."
Rolling updates? You're waiting for container reconciliation—5+ minutes.
Canary? You need a service mesh (Istio). Now you've added complexity.

Result: Kubernetes works, but you're bending your frontend to fit a container orchestration model, not the other way around.

The frontend needs orchestration at the component/bundle level, not the container level.

The Real Cost (In Hours)

Let's quantify what you're actually paying for:

Activity	Hours/Week	Teams Affected
Building custom rollout tooling	3–5	Platform team
Maintaining per-team deployment scripts	2–4	Each team
Incident response (extra time due to slow rollback)	1–3	On-call
Debugging deployment coordination issues	2–4	DevOps/Platform
Total	8–16	Org-wide

For a 20-person org, that's 160–320 hours/year of engineering time spent on tooling that the backend solved in the 1990s.

What Should Exist (And Doesn't)

If MFE deployment were solved, here's what you'd have:

Immutable snapshots of your MFE versions (not rebuilt every deploy)
Safe promotion: Deploy to production without a rebuild
Instant rollback: Revert to a previous version in ~30 seconds (not rebuild time)
Canary releases: Built-in, no custom per-team tooling
Observability: See what's deployed and rollout status in real-time

This exists for backends (Docker images, Kubernetes, etc.). It doesn't exist for frontends as a standard, integrated layer.

A Diagnostic: Check Your Own Setup

If any of these sound familiar, you're manually orchestrating MFE deployments:

You have custom scripts for canary releases
Rollback requires re-running your CI/CD pipeline
You don't have a shared "deployment status" view
Different MFE teams use different rollout processes
Your MTTR (mean time to recovery) is in minutes, not seconds
You've had "cascading failures" where one MFE's deployment issue affected others

If you check even 2–3 of these, you're incurring operational debt that federation won't fix.

The Gap

Federation solved: "How do I structure my code?"

The unsolved gap: "How do I deploy my code safely?"

The irony: The backend solved this 30 years ago. But every MFE team rebuilds the solution from scratch.

What's Next

We're working on something to close this gap. The idea: a control plane for microfrontends that treats deployment and orchestration as a first-class concern—not an afterthought, not a per-team rebuild.

In the meantime, ask yourself: If your backend team managed deployments the way your frontend does, would you accept it?

If the answer is no, you've identified the problem.

Follow along. We'll share what we're building.

Share Your Experience

If you're managing MFE deployments: What's your biggest pain point? How long does a rollback actually take? How much custom tooling are you maintaining?

The more I hear, the clearer the picture becomes.

How to roll back a micro frontend in 30 seconds (without rebuilding the host)

MFEOrchestrator — Thu, 08 Oct 2026 08:09:52 +0000

The release went out twenty minutes ago. Checkout throws on Safari, the error rate is climbing, and someone has already asked the question everybody dreads: how fast can we undo this?

If your micro frontends load through Module Federation and the version each environment serves lives in the host's source, the honest answer is ten to fifteen minutes — on a good day, with CI free and nobody else's pipeline ahead of yours. This is about why that number is what it is, and how to make it thirty seconds.

Why is rolling back a micro frontend so slow?

Because in most setups the rollback is not a rollback. It is a redeploy. The host holds a list of remotes — a file, usually committed — mapping each micro frontend to a URL. Change which version you serve and you have changed the host's source. Changing the host's source means building the host again.

So the fix for a broken checkout widget is a full rebuild and redeploy of the shell containing it. The blast radius of the recovery is larger than the blast radius of the bug.

Where the fifteen minutes actually go

Worth breaking down, because the instinct is to blame the build, and the build is rarely the biggest share.

Someone decides what to revert. Not mechanical: the last deploy may have carried three micro frontends, and only one is broken.
Revert the commit, open a PR. If the branch is protected — and on a host application it should be — that needs a review.
Wait for a CI runner. On a shared plan at three in the afternoon, this is dead time you do not control.
Install, build, test. The host's build is the whole shell: every dependency, every micro frontend reference.
Deploy, invalidate the CDN, wait for the edge to actually drop the old bundle.

Only step four is engineering. The rest is queueing and process, which is why a faster build machine barely moves the number.

What does Module Federation actually give you?

Runtime loading, and that is genuinely a lot: the host fetches a remote's bundle when it needs it, and shared dependencies get negotiated rather than duplicated.

What it does not give you is a decision. Module Federation loads whatever URL you point it at. It holds no opinion about which version staging should serve versus production, keeps no record of what was live yesterday, and offers no way to change the answer without changing the code that contains it. Composition is solved. Version resolution is left as an exercise.

What makes a thirty-second rollback possible?

One change: the version an environment serves stops being a build-time constant and becomes runtime data.

Concretely, the host stops importing a remotes map and starts fetching one. On startup it asks a single question — which versions should I load right now? — and gets back a small JSON document. The bundles do not move; they were uploaded already, immutable already, sitting behind a CDN already. The only thing a rollback changes is which of them the answer points to.

That is why it is fast. Nothing is rebuilt because nothing needs building: the version you are rolling back to was built weeks ago and never deleted.

How do you roll back in thirty seconds?

Find the environment serving the broken version.
Pick the previous version from its history. It is still there — immutable artifacts are not garbage collected on deploy.
Point the environment at it, and confirm.
The next page load fetches the new configuration and mounts the old bundle.

No PR, no CI, no host deploy. The rollback touches one record, and that record is the only thing that was ever environment-specific.

Does this work with both Webpack and Vite?

Yes, and it is the same shape in both. Module Federation is a first-party plugin in Webpack and Rspack, and reaches Vite through @module-federation/vite. What differs is where the remotes map is declared, not that it is declared.

The change is identical either way: instead of writing the remotes object literally into the bundler config, you generate it from configuration fetched at runtime. The bundler still needs the remote names at build time — that part is genuinely static — but the URLs behind those names do not have to be.

What can still go wrong?

Plenty. A piece that says otherwise is selling you something.

Shared dependency drift. If the broken version bumped a shared library and the host negotiated around it, rolling back one remote can leave the singleton at a version the older code never saw.
In-flight sessions. Users mid-session keep the bundle their browser already holds until they reload. The rollback is instant for new page loads and eventual for everyone else.
Configuration caching. If the runtime config sits at the edge with a long TTL, your fast path is only as fast as that TTL. Keep it short, or make invalidation part of the rollback.
Contract changes. If the broken release also changed an API contract, the backend has moved on. Rolling the frontend back does not roll the contract back.

None of this makes the approach worse than rebuilding the host. The rebuild has every one of these problems too — plus the fifteen minutes.

And if you would rather not need the rollback?

A rollback is the blunt instrument: something is broken for everyone, and you are undoing it. The considered version of the same mechanism is a canary release. Once the version an environment serves is runtime data, it can also be a different answer for different users — which is how you find out a release is bad while it is still reaching two percent of traffic. We wrote about how that works, and what it costs separately.

Do you need a control plane for this?

No. The mechanism is not complicated, and you can build it: a JSON document in object storage, a fetch on host startup, something to write the file.

What you end up maintaining is everything around it. Somewhere to see which version each environment serves without opening a bucket. A history, so “the previous version” is a fact rather than a memory. Permissions, because whoever can write that file can change production. An audit trail, for when someone asks who rolled back and when. Validation, so a typo in a version string fails loudly instead of serving a blank page. A path for CI to publish a build and register it in one step.

That is the part that takes the time, and it is the part every team rebuilds. MFE Orchestrator is our answer to it — open source, self-hostable — but the idea outlives the tool: as long as the version lives in the host's build, your rollback time is your host's deploy time. Move the decision out of the build and the number collapses to whatever it takes to write one record.

Thirty seconds is not a marketing figure. It is what remains once you stop rebuilding an entire application in order to change your mind about which version of one widget to serve.