hello event

As Next.js applications scale to enterprise levels, monolithic architectures become bottlenecks. More teams, complex deployment pipelines, and growing codebases slow development velocity.

Next.js Multi-Zones provide an elegant solution: multiple independent Next.js applications serving different URL paths under a single domain. This micro-frontend approach maintains SEO and performance while enabling team autonomy.

In this comprehensive guide, we'll explore Multi-Zones from concept to production implementation, including the latest Next.js 15 features.

1. What Are Multi-Zones? 🤔

A Zone is a standalone Next.js application that serves a specific set of URL paths under a shared domain. Multi-Zones enable micro-frontend architecture by allowing different parts of your application to be developed, built, and deployed independently.

Key Characteristics:

• Path-based routing: Different URL prefixes map to different Next.js applications
• Independent deployments: Each zone has its own CI/CD pipeline and release cycle
• Framework flexibility: Zones can use different Next.js versions or even different frameworks
• Unified user experience: Users perceive the application as a single cohesive website

Example Architecture:

example.com/           → Main marketing app (Next.js 15)example.com/dashboard/* → Dashboard app (Next.js 14)  example.com/blog/*     → Blog app (Next.js 15)example.com/admin/*   → Admin panel (different framework)

Each zone operates as a completely independent application with its own:

• Repository and version control
• Build process and deployment pipeline
• Dependencies and package.json
• Development team and release schedule

2. Why Use Multi-Zones? 🚀

A. Team Scalability

Large teams often struggle inside a single repository.

With Multi-Zones:

• Each team owns its own app
• Deployments are fully independent
• No shared build bottlenecks

This setup works exceptionally well for enterprise-scale products.

B. Clear Architectural Boundaries

Different parts of a product often serve different purposes:

• Marketing website
• Authenticated dashboard
• Admin panel
• Documentation or blog

Multi-Zones allow each area to evolve independently, with architecture that mirrors real business domains.

C. Gradual Migration

Migrating a legacy system to Next.js?

Multi-Zones let you:

• Keep the legacy app running
• Introduce a new Next.js zone
• Migrate routes incrementally

No risky “big rewrite” required.

3. How Multi-Zones Work Under the Hood ⚙️

Multi-Zones operate through external routing rather than internal Next.js routing. The magic happens at the infrastructure layer:

Routing Mechanisms:

Reverse Proxy (Recommended):

• Vercel: Built-in Multi-Zones support with zero configuration
• NGINX: Custom routing rules in configuration
• Cloudflare Workers: Edge-based routing for global performance

Next.js Rewrites (Alternative): You can use one Next.js application as the router using next.config.js rewrites:

// next.config.js - Main app routingmodule.exports = {  async rewrites() {    return [      {        source: '/blog/:path*',        destination: 'https://blog-app.vercel.app/blog/:path*'      },      {        source: '/dashboard/:path*',         destination: 'https://dashboard-app.vercel.app/dashboard/:path*'      }    ]  }}

Asset Prefixing (Critical):

Each zone (except the default one) must configure an assetPrefix to avoid resource conflicts:

// next.config.js - Blog zonemodule.exports = {  assetPrefix: '/blog',  // Next.js 15+ automatically handles static asset routing}

Next.js 15 Update: In versions prior to 15, additional rewrites were needed for static assets. Next.js 15 automatically handles this, making setup significantly simpler.

4. Complete Implementation Example 🛠️

Let's walk through a complete two-zone setup with code examples:

Zone 1: Main Marketing App

Handles: /* (catch-all for unmatched routes)

// main-app/next.config.jsmodule.exports = {  // No assetPrefix needed for default zone  async rewrites() {    return [      {        source: '/blog/:path*',        destination: 'https://blog-app.vercel.app/blog/:path*'      }    ]  }}

Zone 2: Blog App

Handles: /blog/*

// blog-app/next.config.jsmodule.exports = {  assetPrefix: '/blog',  // Next.js 15+ automatically serves static assets at /blog/_next/}

// blog-app/src/app/layout.jsexport default function RootLayout({ children }) {  return (    <html lang="en">      <head>        <base href="/blog" /> {/* Critical for relative paths */}      </head>      <body>{children}</body>    </html>  )}

Deployment Configuration:

Vercel (Simplest):

{  "rewrites": [    { "source": "/blog/(.*)", "destination": "https://blog-app.vercel.app/blog/$1" }  ]}

NGINX:

location /blog/ {    proxy_pass https://blog-app.vercel.app/blog/;    proxy_set_header Host $host;}

5. Navigation and Linking Strategies 🔗

Understanding navigation behavior is crucial for Multi-Zones success:

Navigation Types:

Soft Navigation (within same zone):

• Uses Next.js <Link> component
• No page reload - instant client-side transition
• Prefetching and optimized loading

Hard Navigation (between zones):

• Requires standard <a> tags
• Full page reload - resources unload and reload
• Necessary for cross-zone transitions

Implementation Examples:

// Correct: Standard link for cross-zone navigation<a href="/blog" className="text-blue-600 hover:underline">  Visit Our Blog</a> // Avoid: This will try to prefetch and soft navigate, causing issues<Link href="/blog">  Visit Our Blog</Link> // Correct: Smart navigation componentfunction SmartLink({ href, children, ...props }) {  const isSameZone = href.startsWith('/dashboard'); // Your zone detection logic    return isSameZone ? (    <Link href={href} {...props}>      {children}    </Link>  ) : (    <a href={href} {...props}>      {children}    </a>  );}

Performance Considerations:

• Bundle splitting: Each zone loads only its own JavaScript
• Caching: Browser caches zones independently
• Prefetching: Only works within the same zone
• State preservation: Application state resets during cross-zone navigation

6. Advanced Patterns: Sharing and Coordination 🎨🔐

While zones are independent, strategic sharing maintains consistency and reduces duplication:

Design System & UI Sharing

// Shared package: @company/design-system// Each zone installs as dependency // Usage in any zone:import { Button, Card } from '@company/design-system';import { CompanyLogo } from '@company/brand-assets';

Authentication Strategy

// Shared auth libraryimport { auth } from '@company/auth-library'; // All zones use same top-level domain:// .example.com cookies are accessible across all zones // Secure cross-zone auth flowfunction login(returnUrl = '/') {  // Redirect to central auth zone  window.location.href = `/auth/login?return=${encodeURIComponent(returnUrl)}`;}

API Services & Data Fetching

// Shared API client with automatic zone awarenessimport { api } from '@company/api-client'; // Zone-aware API callsconst userData = await api.get('/api/user');const products = await api.get('/api/products'); // The API client handles:// - Authentication tokens// - Zone-specific API endpoints  // - Error handling and retries

Feature Flag Coordination

// Shared feature flag serviceimport { features } from '@company/feature-flags'; // Consistent feature rollout across zonesif (features.isEnabled('newCheckout')) {  // Show new checkout experience}

Best Practices for Sharing:

• Monorepo: Use tools like Nx, Turborepo, or Yarn Workspaces
• Package versioning: Semantic versioning with careful breaking changes
• Backward compatibility: Maintain support for older zone versions
• Documentation: Clear migration guides and changelogs

7. When You Should NOT Use Multi-Zones ⚠️

Multi-Zones introduce operational complexity.

Avoid them if:

• Your app is small or medium-sized
• One team owns the entire codebase
• Seamless client-side navigation is a hard requirement

In these cases, a single Next.js app or a monorepo is usually the better choice.

Summary

Multi-Zones are a scaling strategy, not a default architecture.

They are most effective when:

• Teams are large and autonomous
• Product domains are clearly separated
• Independent deployments are essential

If your Next.js application is becoming hard to scale organizationally, Multi-Zones might be the architectural unlock you need