How does SSG work in a monorepo or multi-zone Next.js architecture?

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.

Core Concepts

1
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.
2
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.
3
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.

Monorepo Structure for SSG Apps

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 .

Sharing Data Fetching Logic for SSG

Multi-Zone Architecture with SSG

1
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.
2
URL composition: Zones are combined via URL rewriting (e.g., using Next.js rewrites in next.config.js or a reverse proxy like Nginx). For example, /blog/* routes to the blog zone, while /store/* routes to the store zone .
3
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 .
4
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 .

Multi-Zone Configuration Example

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 .

Sharing Layouts via Monorepo Package

Advanced Pattern: Pre-rendering Variations with Middleware

1
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 .
2
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.
3
Example: Generate static pages for /site/dark and /site/light in each zone, then middleware rewrites / to the appropriate variant based on user cookie.

Multi-Zone Personalization with Pre-rendered Variants

Build and Deployment Considerations

1
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 .
2
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.
3
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.
4
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.

Difficulty: 8/10

Topics: Static Site Generation, Monorepo architecture, Multi-zone deployment

Scenario Questions

0-2 years experience

1
If you add a new page to a Next.js app inside a monorepo, what steps do you need to take for it to be statically generated?
2
What happens when you run next build in a monorepo that contains multiple packages, and how does Next.js locate the page components?

2-5 years experience

1
You notice that after moving a shared UI component to a separate package, the SSG build fails with a module not found error. How would you debug and fix it?
2
When deploying the same Next.js site to two geographic zones, you see different HTML content for the same route. What could cause this inconsistency and how would you resolve it?

5-8 years experience

1
Design a CI pipeline for a monorepo that builds and deploys a Next.js SSG site to multiple edge locations while minimizing build time. What tools and caching strategies would you use?
2
Explain the trade‑offs between running a single global SSG build versus per‑zone builds for a large e‑commerce catalog. How do you decide which approach to take?

8+ years experience

1
Your organization wants to migrate a legacy multi‑repo Next.js codebase into a monorepo with multi‑zone static deployments. Outline the migration plan, focusing on build orchestration, asset distribution, and long‑term maintainability.
2
At scale, how would you architect the static asset pipeline to ensure cache coherence across CDN edge nodes while supporting incremental static regeneration for frequently updated pages?

Follow-up Questions

❓How would you handle a failing SSG build caused by a shared library change?
❓What would you monitor in production to know if your multi‑zone static assets are being served correctly?
❓Can you describe a strategy to reduce build times when the monorepo grows large?