# How Next.js ISR works outside Vercel in 2026

Last updated: 2026-11-10

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](/i/nextjs-hosting-europe) and [European Vercel alternatives](/i/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](https://nextjs.org/docs/app/guides/self-hosting) and [Next.js ISR guide](https://nextjs.org/docs/app/guides/incremental-static-regeneration)
- [Vercel ISR docs](https://vercel.com/docs/incremental-static-regeneration)
- [OpenNext caching on AWS](https://opennext.js.org/aws/inner_workings/caching) and [OpenNext caching on Cloudflare](https://opennext.js.org/cloudflare/caching)
- [Next.js on Netlify](https://docs.netlify.com/build/frameworks/framework-setup-guides/nextjs/overview/)
- [Sliplane Next.js hosting in Europe](https://sliplane.io/nextjs-hosting-europe)
- [Next.js hosting on Eurobase](/hosting/nextjs), [Eurobase cache docs](/docs/cache), [Deploy a Next.js app](/docs/guides/nextjs), [Plans and limits](/docs/plans) and [Eurobase pricing](/pricing)