SSG in monorepos enables shared code and parallel builds, while in multi-zone architectures each zone independently pre-renders its pages but navigation between zones requires full page reloads
In a monorepo, SSG works by allowing multiple Next.js applications to share code through internal packages while maintaining independent static generation at build time. In a multi-zone architecture, each zone operates as a separate Next.js application with its own static generation process, and these zones are composed together—typically via routing rules or a reverse proxy—to form a unified site. The key distinction is that monorepos focus on build-time and code organization, while multi-zone focuses on runtime composition and deployment isolation.
Monorepo: A single repository containing multiple packages or applications, enabling code sharing, consistent tooling, and coordinated versioning . SSG pages in different apps can share UI components, utilities, and data fetching logic through internal packages.
Multi-zone: An architecture where multiple Next.js applications (zones) are deployed separately but composed to appear as a single site, typically via URL rewriting or a reverse proxy. Each zone handles its own routing and static generation independently.
Key difference: Monorepo is about development organization and code sharing; multi-zone is about deployment composition and runtime concerns. They can be used together or separately.
In a monorepo, SSG benefits from shared packages that can be used across multiple static apps. For example, a blog-app and a marketing-app can both import UI components from a shared ui-lib package and data utilities from a core-lib package . This eliminates code duplication and ensures consistency across static sites. During build time, each app runs its own generateStaticParams and data fetching, but they can reuse the same underlying data access patterns. Tools like Turborepo optimize this process by caching build outputs—if a shared package hasn't changed, apps that depend on it can skip rebuilding, significantly speeding up CI/CD for large SSG sites .
Independent builds: Each zone builds its own static pages independently, with its own
generateStaticParams, ISR configuration, and deployment pipeline. Zones don't share build processes.URL composition: Zones are combined via URL rewriting (e.g., using Next.js rewrites in
next.config.jsor a reverse proxy like Nginx). For example,/blog/*routes to the blog zone, while/store/*routes to the store zone .No client-side transitions: When navigating between zones, a full page reload occurs because zones are separate applications. This is a key limitation compared to a single Next.js app .
Shared layouts challenge: Global UI like headers and footers cannot be shared across zones without duplication or microfrontend techniques, as layouts cannot be "inherited" across application boundaries .
One of the most common questions in multi-zone architecture is how to share global layouts (headers, footers) across zones while maintaining SSG benefits. Currently, there is no official support in Next.js for a true "shell + multiple zones" architecture where a shared layout remains mounted during client-side navigation between zones . Moving between zones always triggers a full page reload because each zone is a separate application. However, you can work around layout duplication by creating a shared UI package in a monorepo and importing it into each zone, ensuring visual consistency even though each zone renders its own layout at build time .
In a monorepo or multi-zone setup, you can combine SSG with middleware for personalization across apps. Pre-render all possible variations of a page (e.g., dark/light themes, A/B test variants) at build time using
generateStaticParams, then use middleware to rewrite requests to the appropriate static version based on cookies or headers .This pattern works across zones if each zone implements the same strategy. For example, both blog and store zones can pre-render theme variants and use middleware to serve the correct one, ensuring a consistent personalized experience even though navigation reloads the page.
Example: Generate static pages for
/site/darkand/site/lightin each zone, then middleware rewrites/to the appropriate variant based on user cookie.
Parallel builds: In a monorepo with multiple SSG apps, use Turborepo or Nx to run builds in parallel, significantly reducing total build time. Caching ensures unchanged apps aren't rebuilt .
Independent deployments: Each zone can be deployed independently, which is useful for large teams. A change to the blog zone doesn't require rebuilding or redeploying the store zone.
Vercel support: Vercel natively supports monorepos and multi-zone deployments. Each app can be configured as a separate project with its own git triggers and build settings.
Preview deployments: Monorepo tooling can generate preview URLs for affected apps only, making it easier to test changes across zones before production deployment.
At Next.js Conf 2024, Peloton shared their multi-year migration from a client-side-only app to Next.js within a large monorepo . They achieved improved page performance and developer productivity by leveraging SSG for content-heavy pages while maintaining shared components and utilities across their application suite. This demonstrates that SSG in a monorepo context scales effectively for enterprise applications with multiple teams and codebases.