Can Static Regeneration be used for virtual hosting?

[migueloller]

Imagine you're a website builder and hosting provider and you're using Next.js as the framework to render the websites. If you wanted to leverage Static Regeneration you would probably have to deploy each site as a separate Next.js app so that they can take advantage of all the static optimizations. If there are a lot of sites being created, though, that might be unnecessary overhead.

Would it be possible to leverage Static Regeneration for multiple hosts in a single Next.js server where the referenced pages can be matched not just by path but also by the Host header? There's no issue at the CDN layer since the host and path are both considered, but is Static Regeneration supported with custom servers in Next.js?

[Kostanos]

It is 2025, it seems this issue is still relevant. Anyone have some updates on this?

[maheshbhatiya73]

Hey everyone! This is a really interesting question, and it’s something a lot of folks building multi-tenant or virtual hosting platforms with Next.js wonder about.

Can Static Regeneration (ISR) work for virtual hosting?
Short answer: It’s tricky, but possible with some caveats.

Why is this challenging?
Next.js’s ISR works by generating static pages based on routes at build time or on-demand at the server level. Normally, these pages are keyed by the URL path, not by the host or domain.

When you want to serve multiple sites (virtual hosts) from a single Next.js app, you need the system to:

Differentiate not just by path (e.g., /about)

But also by Host header (e.g., site1.com/about vs site2.com/about)

This means your caching and regeneration logic must consider the host as part of the cache key.

What does Next.js support?
By default, Next.js ISR does not consider the Host header in its cache keys.

It’s designed primarily for single-domain apps or apps where the domain is static.

The CDN layer (like Vercel’s edge network) may cache based on Host + Path, but your Next.js server or serverless function needs to handle this explicitly to serve correct content per host.

Workarounds and approaches:
Separate apps per host — the simplest but least scalable way, as you mentioned.

Custom server with custom ISR logic — You can build a custom Next.js server that inspects the Host header and manages ISR caches accordingly, but this requires custom code and isn’t officially supported out of the box.

Use middleware or edge functions to rewrite or augment requests based on host, then let ISR handle pages keyed by modified paths that include the host info (e.g., /site1/about).

Multi-tenant routing inside Next.js — where you design your pages to load different data based on the host and render dynamically with some caching. This could reduce ISR benefits but works better for many hosts.

Is it supported with custom servers?
Custom servers let you control routing and request handling, but Next.js ISR itself assumes its own routing system, so fully integrating ISR with virtual hosting on a custom server can be complex and fragile.

=>
Out of the box, ISR doesn’t support virtual hosting with caching per Host header.

You’ll likely need a custom approach to incorporate Host into cache keys and regeneration.

Many projects either deploy separate apps per host or use dynamic rendering with caching.

The ecosystem and Next.js keep evolving, so keep an eye on updates!