TL;DR: For many Next.js products, multi-zones are the safest micro frontend starting point because they split a domain by route ownership. Module Federation can share runtime modules, but it adds coordination and compatibility risk. Choose the architecture based on team boundaries, deployment independence, routing, SEO, and operational maturity.
Why Teams Split a Next.js App
Micro-frontends become worth discussing when one Next.js repository has more teams than it can comfortably hold: release trains collide, builds slow down, and a change to the marketing site waits on the dashboard team. The goal is to let several teams ship independently while users still see one product on one domain.
The official Next.js docs describe Multi-Zones as an approach to micro-frontends where separate Next.js applications serve different route sets under one domain.
Main Options
| Option | Best For | Tradeoff |
|---|---|---|
| Single Next.js app | small to mid-size product teams | less independent deployment |
| Multi-zones | route-level ownership under one domain | needs routing/proxy coordination |
| Module Federation | runtime module sharing across apps | higher compatibility and operational complexity |
| Separate domains | strong product separation | weaker unified UX and SEO control |
What Are Next.js Multi-Zones?
A zone is a separate Next.js app responsible for a set of routes. For example:
software.example.com/ -> marketing app
software.example.com/docs -> docs app
software.example.com/dashboard -> product app
software.example.com/blog -> content app
Each app can have its own repository, deployment, build pipeline, and owning team while still appearing under the same domain.
Multi-Zones vs Module Federation
| Area | Multi-Zones | Module Federation |
|---|---|---|
| Split boundary | URL paths | runtime modules/components |
| Operational model | separate apps behind routing | shared modules loaded at runtime |
| SEO fit | strong for route-owned pages | depends on rendering and integration |
| Team autonomy | high | medium to high |
| Complexity | moderate | high |
| Best first use | docs, blog, dashboard, admin split | shared shell or component runtime needs |
Webpack's Module Federation lets separate builds expose and consume code from each other. That is powerful, but a product team should not start there unless runtime sharing is actually the business requirement.
Implementing Multi-Zones Step by Step
Take a product where the main app owns / and the dashboard, and a separate blog app owns /blog. The blog is its own Next.js project with its own repository and deployment.
1. Give the child zone its own asset path. Without this, both apps serve /_next/... and the browser loads the wrong JavaScript:
// blog app: next.config.js
module.exports = {
assetPrefix: '/blog-static',
};
Its pages live under app/blog/..., so the routes it serves already start with /blog.
2. Route the child's paths from the main app. The main app proxies the blog's pages and assets with rewrites:
// main app: next.config.js
const BLOG_ORIGIN = process.env.BLOG_ORIGIN; // for example https://blog-zone.internal.example.com
module.exports = {
async rewrites() {
return [
{ source: '/blog', destination: `${BLOG_ORIGIN}/blog` },
{ source: '/blog/:path+', destination: `${BLOG_ORIGIN}/blog/:path+` },
{ source: '/blog-static/:path+', destination: `${BLOG_ORIGIN}/blog-static/:path+` },
];
},
};
You can do the same routing at the edge instead (a CDN, a load balancer, or Vercel's microfrontends routing). The rule is identical: each path prefix has exactly one owning app.
3. Use plain anchors for links that cross zones. next/link performs client-side navigation inside one app. A link from the main app to /blog is a jump to a different application, so it must be a normal <a href="/blog">, which triggers a full page load. Links within a zone keep using next/link.
4. Share sessions through the domain. Because every zone is served from the same domain, a session cookie set with Path=/ and the right Domain is sent to all zones. Each zone must validate it the same way, so keep session verification in a shared package rather than reimplementing it per app.
5. Keep SEO consistent. Each zone emits its own metadata and canonicals, so agree on one canonical host, one robots policy, and one sitemap index that lists every zone's sitemap. A zone that forgets this can quietly drop its pages out of search.
Migrating Gradually With Zones
Zones are also the safest way to rewrite a large frontend without a big-bang release. Stand up the new app as a zone, move one route prefix to it (often /settings or /docs), watch errors and Core Web Vitals for that path, then move the next prefix. If something breaks, rolling back is a one-line change to the rewrite rules.
Where Module Federation Fits
Module Federation shares code at runtime: one build exposes components, and another build loads them while the page runs. It suits a shared shell, such as a navigation bar that many teams must update without redeploying every app.
Check framework support before you commit to it. The @module-federation/nextjs-mf plugin targets the Pages Router and does not support the App Router, so an App Router product usually gets better results from Multi-Zones plus a versioned shared component package. When you do use federation, pin shared singletons such as react and react-dom to one version across every build, because two copies of React on one page break hooks and context.
When Micro Frontends Are Worth It
Use micro frontends when:
- teams own clearly different product areas,
- builds or deploys are slowing delivery,
- one section has very different dependencies,
- a rewrite must happen gradually,
- independent release cycles matter.
Avoid micro frontends when:
- the team is small,
- the app has no clear domain boundaries,
- shared design system work is immature,
- deployment and observability are already weak,
- the goal is only to follow a trend.
Architecture Checklist
| Decision | What To Define |
|---|---|
| Route ownership | which app owns which paths |
| Shared UI | design tokens, components, versioning |
| Auth | session strategy across zones |
| Analytics | consistent events and attribution |
| SEO | metadata, canonicals, sitemaps, redirects |
| Observability | errors and performance per zone |
| Deployment | rollback and preview strategy |
When SoftwareCrafting Can Help
We help product teams structure Next.js apps, rebuilds, SaaS dashboards, and multi-team frontend architectures. See our Next.js development company page or send your frontend architecture problem.
Sources
Frequently Asked Questions
Does Next.js support micro frontends?
Yes. The official Next.js docs document Multi-Zones as a micro frontend approach where different Next.js apps serve different paths under one domain.
Is Module Federation required for Next.js micro frontends?
No. Multi-zones are often simpler and safer when your split is route-based.
How do I link between Next.js zones?
Use a plain <a> element for any link that crosses into another zone, because next/link can only navigate within the current app. Links inside a zone can keep using next/link.
Will micro frontends improve performance?
They can reduce build and ownership complexity, but runtime performance depends on routing, shared assets, caching, and JavaScript weight.
Are micro frontends good for startups?
Usually not early. Startups should first prefer a clean modular app unless team size or rewrite pressure justifies the split.