How Next.js ISR works outside Vercel in 2026

ISR works outside Vercel, because it's part of Next.js and not a Vercel service. What changes is the storage: on your own server the regenerated pages sit in a cache on that server's disk, which is fine for one next start process and breaks once you run several instances or a serverless setup. Managed hosts such as Eurobase, Netlify and Sliplane handle that storage for you; on your own infrastructure you add a shared cache handler or use OpenNext.

ISR outside Vercel at a glance

Platform	Where ISR pages live	How a revalidation reaches every copy	What you set up
Vercel	Durable ISR cache next to your Function region, one per deployment	Handled by Vercel	Nothing
Eurobase	Stored on Eurobase, one cache per deployment	Handled by Eurobase, up to 10 revalidations or purges a second per project	Nothing, unless your repository has its own Wrangler config
Netlify	Netlify's caching for the Full Route Cache and Data Cache	Revalidate by path or by tag	Nothing, the adapter is added during the build
Sliplane	On the disk of one always-on next start container	One container, so there's nothing to sync	Nothing
One next start server you run	In memory and on that server's disk	One process, so there's nothing to sync	A persistent disk
Several instances or Kubernetes	A copy in every instance by default	Not shared until you add a cache handler with refreshTags	A shared store such as Redis or S3
OpenNext on AWS	S3, with a CDN in front	You invalidate CloudFront paths yourself	The OpenNext build, S3 and the invalidation code
OpenNext on Cloudflare	R2, KV or read-only static assets	A queue and a tag cache you configure	Bindings in your Wrangler config

Behaviour is from each provider's own documentation, checked on 10 November 2026.

What happens during an ISR request

The Next.js guide describes the cycle like this. Pages listed by generateStaticParams are rendered at build time and cached. When the revalidate time has passed, the next visitor still gets the cached, stale page, and Next.js renders a fresh one in the background. Once that render succeeds, later visitors get the new page. If it fails, the last good version keeps being served and Next.js tries again on a later request.

On-demand revalidation works differently. revalidatePath and revalidateTag mark entries as invalid, and the page is regenerated on the next request to it, not straight away. The docs also explain that revalidatePath is built on cache tags, so both depend on the same tag bookkeeping.

Three limits apply on every host. ISR needs the Node.js runtime, it doesn't work with a static export, and Next.js doesn't run Proxy for on-demand ISR requests, so rewrites in proxy.ts aren't applied to them.

What to check before you trust ISR on a new host

• Where the cache is stored. Memory and local disk vanish when a container restarts or a serverless instance goes away. Ask whether regenerated pages survive a restart.
• Whether every copy hears about a revalidation. The Next.js docs say a revalidateTag call on one instance only clears that instance's cache unless your handler syncs tags through shared storage.
• Background work after the response. OpenNext's AWS docs point out that the standard next start output regenerates in the background, which doesn't fit a serverless function that stops after it answers.
• A CDN in front. ISR responses carry s-maxage and stale-while-revalidate. If a CDN caches them, you also have to purge the CDN when you revalidate, or visitors keep the old page.
• What a new deployment does to the cache. Vercel and Eurobase keep one cache per deployment. On your own servers, the Next.js guide asks you to boot every container from the same build, and a deploymentId makes browsers holding an older build do a full reload instead of a broken client-side navigation.

Running `next start` on one server

This is the simplest case, and the Next.js self-hosting guide says ISR works with no configuration for a single next start instance with a persistent local disk. Cached entries go to memory, 50 MB by default, and to disk. Set NEXT_PRIVATE_DEBUG_CACHE=1 to log cache hits and misses while you test.

The catch is scale. A second instance has its own disk and its own copy of every page.

Running several instances or Kubernetes

Each pod keeps its own cache, so two visitors can see two versions of a page. The fix in the Next.js docs is a custom cacheHandler in next.config.js, with cacheMaxMemorySize: 0 to turn off the in-memory copy. The handler implements get, set, revalidateTag and resetRequestCache, and the docs list what a production one needs:

1. A store every instance can reach, such as Redis or S3.
2. A size limit, with a TTL or eviction.
3. Serialization that keeps Buffer and Map values intact, or client-side navigation fails with errors like segmentData.get is not a function.
4. An index of entries by tag, kept in the shared store.
5. Handling for timeouts and dropped connections.

For App Router apps, also implement refreshTags(), which runs before each request and pulls invalidations from the shared store. Pages using use cache need cacheHandlers, a separate setting. Every instance also needs the same NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, or Server Actions fail across instances.

OpenNext on AWS or Cloudflare

OpenNext is an open-source adapter that replaces the file system cache with cloud storage. On AWS, ISR files go to S3, and when you revalidate on demand you also invalidate the matching CloudFront paths in your own code. OpenNext's page quotes CloudFront's price for that: the first 1,000 paths a month are free, then $0.005 per path.

On Cloudflare, @opennextjs/cloudflare splits ISR into an incremental cache, a queue that deduplicates time-based revalidations, and a tag cache for revalidateTag and revalidatePath. Its docs suggest R2 for the incremental cache, warn that KV is eventually consistent, and note that the static assets option is read-only, so pages can't be revalidated there.

Managed hosts that handle ISR for you

Eurobase builds Next.js 14.2.35 or later with OpenNext and runs it on V8 isolates on European infrastructure run by Scaleway, a French provider. When your repository has no Wrangler config, ISR pages, fetch caching and use cache data are stored on Eurobase, and revalidateTag and revalidatePath behave as they do in Next.js. Your revalidation calls and cache purges share a limit of 10 a second per project, with bursts of 100. Each deployment, rollbacks included, begins with nothing cached. A page built with Cache Components renders on every request, and next/image doesn't resize. Eurobase is a business registered in Warsaw, Poland. Its plans are Free, then €10 a month for Starter and €20 a month for Pro, both + VAT. There are no usage charges today: work over a limit is refused, and apps on V8 isolates stop until the monthly reset.

Netlify lists ISR as fully supported. Its adapter creates a serverless function for rendering and wires up caching for the Full Route Cache and Data Cache, with revalidation by path or by tag.

Sliplane runs next build and next start in one long-running container. Its Next.js page says the ISR cache stays on disk and revalidatePath and revalidateTag work without an extra service. Its app runtime starts from €9, and its European servers are in Germany and Finland.

How to choose

• One container is enough for your traffic: run next start yourself or on Sliplane, and ISR works as it does locally.
• You need several instances on your own servers: budget time for a shared cache handler and test client-side navigation after every revalidation.
• You want serverless without writing cache code: Eurobase or Netlify handle storage and tags, and OpenNext does it on AWS or Cloudflare if you run the pieces.
• You need a European provider: compare Next.js hosting in Europe and European Vercel alternatives.

Frequently asked questions

Is ISR a Vercel-only feature?

No. ISR is part of Next.js and works with next start on any server. Vercel adds durable storage and request collapsing on top, so a self-hosted setup has to provide its own storage once it grows past one instance.

Why does revalidatePath work locally but not in production?

Usually because production runs more than one instance. Each one has its own cache, and the call only clears the cache of the instance that received it. Move the cache to a shared store and sync tags with refreshTags().

Does ISR work on serverless or edge runtimes?

Next.js supports ISR only on the Node.js runtime. Serverless setups need an adapter that stores pages outside the function and handles regeneration, which is what OpenNext, Netlify's adapter and Eurobase's build do.

Do I need Redis for ISR?

Not on a single server with a persistent disk. Once you run several instances, the Next.js docs point to a shared store such as Redis or S3 and link a Redis cache handler example.

What happens to cached pages when I deploy?

On Vercel and Eurobase each deployment gets its own cache, so visitors never see pages from the old build. On your own servers, boot every container from the same build, as the Next.js guide asks, and set deploymentId so browsers on an older build reload cleanly.

Sources

• Next.js self-hosting guide and Next.js ISR guide
• Vercel ISR docs
• OpenNext caching on AWS and OpenNext caching on Cloudflare
• Next.js on Netlify
• Sliplane Next.js hosting in Europe
• Next.js hosting on Eurobase, Eurobase cache docs, Deploy a Next.js app, Plans and limits and Eurobase pricing