Self host Next.js vs Vercel: the bill and four rebuilds

The obvious self host Next.js vs Vercel comparison prices Vercel at its on-demand bandwidth rate of $0.15 per GB after the first 1 TB. Vercel now sells a Flat Rate CDN that covers up to 50 TB of transfer for $20 to $300 a month, and existing Pro teams were not moved onto it automatically. Check which one you are on before you price a migration. Then price the four things Vercel does for you that you would have to rebuild.

By the end of this post you will have a worked bill from published prices, the four rebuilds in the order they tend to break, and a short list of conditions under which leaving is the right call. All prices are as of 28 October 2026.

Self host Next.js vs Vercel: run the bill before the migration

The Vercel side of the comparison is published, so start there. These are the Pro plan figures a 60-person SaaS team actually pays against, read from Vercel's pricing page and the Pro plan documentation.

Line item	Included on Pro	Price after that
Platform fee	1 deploying seat and $20 usage credit	$20 a month
Extra deploying seats	Viewer seats are free	$20 a month each
Fast Data Transfer	1 TB a month	From $0.15 per GB
CDN requests	10M a month	From $2 per 1M
Fluid Active CPU	None listed	From $0.128 per hour
ISR writes / reads	None listed	From $4 / $0.40 per 1M

Vercel Pro pricing: "from" means the cheapest region

Every usage price on that page says "starting at". The regional pricing table puts Fast Data Transfer at $0.15 to $0.35 per GB and Active CPU at $0.128 to $0.221 per hour depending on the region. Washington D.C. (iad1) is the floor at $0.15 per GB. Mumbai (bom1) charges $0.20 per GB, $2.20 per million CDN requests and $0.14 per Active CPU hour. If your users are in India or the Gulf, price your own region, not the headline.

Vercel Pro bandwidth overage: the flat rate most comparisons miss

Flat Rate CDN replaces per-unit billing for CDN requests and Fast Data Transfer with a capacity tier. Pro includes 1M requests and 1 TB. The paid tiers are $20 a month for 10M requests and 50 TB, $100 for 50M and 50 TB, and $300 for 150M and 50 TB. If a whole billing cycle runs over capacity, Vercel moves you up a tier at the start of the next cycle; a one-day spike does not.

The catch is in the 8 September 2026 GA announcement: new Pro teams have it on by default, but existing teams are not switched and have to opt in from Billing settings. A team that has been on Pro for a year and watched its bandwidth line grow is exactly the team most likely to still be on on-demand pricing. Media-heavy or download-heavy workloads are excluded from Flat Rate CDN, so this fix does not apply if most of your bytes are files or video.

Is self hosting Next.js cheaper than Vercel? A worked example

Self hosting Next.js is cheaper on delivery only when you compare against Vercel's on-demand rate; against Flat Rate CDN the gap is close to zero at moderate traffic. The example below uses published prices only. Assumptions: 3 TB (3,000 GB) out and 30M requests a month, US region, five deploying seats on Vercel, and AWS CloudFront as the self-hosted CDN. Compute is excluded on both sides because it depends entirely on your workload.

Monthly line	Vercel on-demand	Vercel Flat Rate CDN	AWS CloudFront
Seats (5 deploying)	$100	$100	$0
Data transfer (2,000 GB over the free 1 TB)	$300	$100 tier (50M / 50 TB)	$170
Requests (20M over the free 10M)	$40	In tier	$20
Total before compute and credit	$440	$200	$190

The CloudFront column uses AWS's pay-as-you-go rates: 1 TB and 10M requests free each month, then $0.085 per GB in the US and Europe and $0.0100 per 10,000 HTTPS requests. In India the transfer rate is $0.109 per GB. The Flat Rate column needs the $100 tier because 30M requests exceeds the $20 tier's 10M. Vercel's $20 monthly credit can offset usage on top of this.

So on delivery, the honest comparison is $200 against $190 for this traffic profile, not $440 against $190. The difference you save by leaving is what has to pay for the rebuilds below, plus the people who run them. If you are on on-demand pricing today, toggling Flat Rate CDN is a billing change; a migration is an engineering project.

What breaks when you move Next.js off Vercel

A single next start process on one machine with a persistent disk works out of the box. The Next.js self-hosting guide, updated 15 October 2026, is explicit that the trouble starts when you run multiple instances, use ephemeral compute or put a CDN in front, which is what any move to Kubernetes or AWS ECS involves. Four things then need building.

1. Next.js ISR cache across multiple instances needs a shared cacheHandler

The Next.js server cache, which ISR uses, lives on each instance's local disk by default with a 50 MB in-memory layer. On Kubernetes, the guide says, "each pod will have a copy of the cache", so pods serve different versions of the same page. The fix is a custom cacheHandler with cacheMaxMemorySize: 0, backed by a store every instance can reach, such as Redis or S3.

The guide lists what a production handler must do, and it is more than a key-value wrapper. It has to bound its size, serialize Buffer and Map values that JSON.stringify cannot round-trip (otherwise you see errors like segmentData.get is not a function on client navigation), index entries by tag, and handle storage timeouts. It also has to implement refreshTags(), because by default revalidateTag() on one instance only invalidates that instance.

The store has a price too. ElastiCache Serverless for Valkey in US East charges $0.084 per GB-hour of data stored, so every gigabyte the shared cache holds costs about $61 a month at 730 hours, before request charges. On Vercel this layer is billed as ISR reads and writes and you do not run it.

2. Next.js Server Actions encryption key, self hosted, must match on every instance

Next.js encrypts the variables a Server Action closes over and, by default, generates a new key for each build. If two instances hold different keys, an action encrypted by one cannot be decrypted by the other and users get "Failed to find Server Action" errors. You set NEXT_SERVER_ACTIONS_ENCRYPTION_KEY to a base64 value of 16, 24 or 32 bytes at build time. The data security guide suggests openssl rand -base64 32 and calls this an advanced case that needs key rotation, which means a secret your platform team now owns.

3. Version skew turns into a full page reload

Self-hosted, you set deploymentId so static assets carry ?dpl= and navigations send an x-deployment-id header. When the client and server disagree, Next.js triggers a hard navigation, and component state such as useState is lost. Vercel's Skew Protection does something different: it keeps routing old clients to the old deployment, by default for one day, so their session carries on. Matching that yourself means keeping old builds' assets and servers reachable during a rollout, which is a deployment-pipeline project, not a config flag.

4. Streaming needs every proxy to stop buffering

App Router streaming and Partial Prerendering only work if nothing between the user and Next.js buffers the response. For nginx the guide's answer is the X-Accel-Buffering: no header. It also warns that load balancers must support chunked transfer or HTTP/2 streaming, and that AWS ALB with Lambda integration may buffer by default. Without streaming, PPR's static shell arrives with the dynamic content after the full render, which removes the time-to-first-byte gain you adopted it for.

The same guide recommends a reverse proxy in front of Next.js anyway, to handle malformed requests, slow-connection attacks and rate limiting, and a 10 to 30 second drain period on shutdown so after() callbacks finish. Both are yours to configure and test.

The fifth cost: the 3 November security release is yours to roll out

Next.js announced on 27 October that a scheduled security release on Tuesday 3 November 2026 will fix seven medium-severity vulnerabilities, with advisories, affected versions and upgrade instructions published alongside it. The post recommends upgrading once the release is available. It says nothing about whether apps hosted on Vercel are protected in the meantime, so do not plan on that either way.

What changes when you self host is the surface around the framework. The reverse proxy, the cache store, the container base image and the rollout pipeline are all yours to patch, and the advisories will tell you which of them matter only on the day. Our note on the self-hosted exposure in Next.js 16.3.8 walks through how that triage went for an earlier release.

Can Vercel deploy a Dockerfile? Yes, but not your Next.js app by default

Vercel's 27 October changelog says a plain root Dockerfile now deploys on its Container runtime when no other framework is detected. The runtime is in beta, runs on Vercel Functions and is billed on Active CPU. The container runtime docs add that when a project matches Next.js, Vercel keeps Next.js unless you override the framework, and that Static IPs and Secure Compute are not yet supported for container images.

That matters to this decision in one way: the "we need Docker for portability" argument no longer forces you off Vercel, because the same image can run there or on your own cluster. It does not make Vercel a Kubernetes replacement. A container on Vercel scales down after five minutes idle in production and gets a 30-second SIGTERM grace period, which suits request-driven services rather than long-running workers. For those, see our post on Vercel Daemons and background workers.

When leaving Vercel is the right call, and when it is not

The strongest case for leaving is not the bandwidth line. It is that you already run a cluster, already operate Redis and a CDN, and Next.js is one more workload on infrastructure your team maintains anyway. In that position the four rebuilds are configuration on top of existing tooling, and the seat fees and per-unit charges are pure overhead. If you are standing that cluster up for the first time, our Kubernetes implementation work starts from exactly these requirements.

Leaving also makes sense when your traffic is mostly large files or media, which Flat Rate CDN excludes, or when you need fixed egress IPs or data residency that the Vercel features you use do not cover.

Leaving is the wrong choice if your traffic fits a Flat Rate tier and you have not switched to it, if you have no one who will own a cache store and an encryption key at 2 a.m., or if your app relies on long user sessions that a skew-triggered reload would break. In those cases the migration spends engineering time to save roughly the difference shown in the worked example.

Next.js self hosting checklist before you commit

1. Pull last month's Vercel invoice and check whether Flat Rate CDN is enabled. If not, price your usage against the tiers.
2. Price your own region, not the "from" figure: transfer runs from $0.15 to $0.35 per GB.
3. Choose and size the shared cache store, and decide who implements refreshTags().
4. Generate and store NEXT_SERVER_ACTIONS_ENCRYPTION_KEY, with a rotation plan.
5. Decide whether hard reloads on version skew are acceptable, or budget for keeping old builds reachable.
6. Test streaming end to end through every load balancer and proxy.
7. Name the person who applies the 3 November release and every one after it.

If that list is longer than the saving, stay and switch tiers. If the saving still wins, or you need control Vercel will not give you, our web app development team builds Next.js apps on Docker, Kubernetes and AWS, with Redis in the same stack. We can price your bill, scope the four rebuilds against your actual app and tell you which side of the line you are on before anyone writes a Helm chart.