Last updated 3 August 2026
Let us start with the obvious: Vercel builds Next.js, and on Vercel everything in the docs works exactly as written. If your project is a marketing site or an app with light traffic and you value never thinking about infrastructure, that is a good answer and this page is not trying to talk you out of it.
People move anyway, usually for one of three reasons: the bill became unpredictable as traffic grew, the app needs to sit next to a database and a worker rather than call them over the internet, or data has to stay somewhere specific. All three are real, and all three are solvable — but self-hosting Next.js means taking responsibility for a handful of features that Vercel was quietly providing.
This page is organised around those features, because they matter far more than the price per gigabyte. Get the standalone build, the ISR cache and the image optimizer right and Next.js is an ordinary Node service that any platform below will run happily.
At a glance
| Provider | From /mo | Free tier | Managed DB | Persistent disk | Deploy from |
|---|---|---|---|---|---|
| Vercel | $0 / $20 | yes (non-commercial) | via marketplace | Git | |
| Fly.io | ~$2 | Postgres (unmanaged app) | Dockerfile, buildpack | ||
| Railway | $5 | yes ($1 credits) | Git, Dockerfile, template | ||
| Render | $7 | yes (spins down) | Git, Dockerfile | ||
| Granite | $9 | from Advanced | Git, Docker image | ||
| Koyeb | $29 | limited | Serverless Postgres | Git, Dockerfile | |
| Google Cloud Run | usage-based | yes (monthly allowance) | via Cloud SQL | no (use GCS) | Container image |
Entry prices as published by each provider on 3 August 2026, sorted cheapest first. Usage, bandwidth and databases are billed on top almost everywhere — treat this column as a starting point, not a monthly bill.
PaaS, serverless or a plain VPS?
Vercel is a category of its own here, and pretending otherwise would be dishonest. It is the reference implementation: every feature works, and the trade is price predictability and the distance between your app and your data. Most teams that leave do so when one of those two starts to hurt, not because they found something cheaper.
A managed platform is where self-hosted Next.js normally lands. You run a plain Node server from a standalone build, and in exchange you get the database, the cache and the storage in the same project — which is what makes the ISR and uploads problems tractable rather than painful.
Serverless looks attractive because Node starts quickly, and it is the trickiest of the three for this framework. Scale-to-zero and incremental regeneration pull in opposite directions: the whole point of ISR is a warm cache, and the whole point of scaling to zero is not keeping one. It works, but only with a shared cache handler and eyes open.
Next.js is the whole product, traffic is moderate, infrastructure is not your problem
Vercel
Everything works as documented, at $20 per seat once it stops being personal.
Vercel
The app lives next to a database, a cache and uploads, and the bill should be predictable
Managed platform
A standalone build as an ordinary Node service, with its data in the same project.
Granite · Railway · Render
Mostly idle, or traffic arrives in unpredictable bursts
Serverless
Free while asleep — but the ISR cache needs a shared backend to survive.
Cloud Run · Koyeb
The options
Vercel
- Best for
- Anything where Next.js is the whole product and you would rather not think about infrastructure.
- Pricing
- Hobby is free forever but intended for personal, non-commercial projects. Pro is $20 per team member per month, including $20 of usage credit, with pay-as-you-go beyond it.
- First-party: ISR, on-demand revalidation, image optimization and middleware work exactly as documented, with no configuration at all.
- Preview deployments per pull request are excellent and genuinely hard to replicate.
- The edge network and CDN are included rather than assembled.
- Hobby is for personal, non-commercial projects, so anything real starts at $20 per team member per month.
- Usage-based bandwidth and function pricing is the source of the surprise-bill stories; it is manageable with spend limits, but you have to set them.
- Databases and workers live somewhere else, so a data-heavy app pays for every round trip across the public internet.
Fly.io
- Best for
- Running the Node server close to users in several regions on a small budget.
- Pricing
- Pay as you go. The smallest shared-cpu-1x machine with 256 MB RAM works out at roughly $2.02/month, billed per second.
- Multi-region and Anycast routing are first-class, which recovers some of the edge behaviour you lose leaving Vercel.
- Takes your Dockerfile, so a standalone build ships exactly as you built it.
- Per-second billing, and the cheapest machines are genuinely usable here — a standalone Next.js server's baseline is around a hundred megabytes, as the measurement below shows, so unlike heavier stacks the headline price actually applies.
- No free tier for new organisations since October 2024.
- Multi-region makes the ISR cache problem worse, not better — each region needs to agree on what is current, which means a shared cache handler.
- Postgres is a Fly app you run yourself.
Railway
- Best for
- Getting the app, a database and a cache running together quickly.
- Pricing
- Hobby is $5/month including $5 of usage credits; Pro is $20/month per workspace including $20 of credits. A free plan gives $1 of monthly credits, and there is a 30-day trial.
- Detects Next.js and builds it without configuration.
- Postgres and Redis sit in the same project, which is what an ISR cache handler needs.
- A free plan and a trial to evaluate on.
- Usage-based billing on top of the base fee is hard to forecast.
- No CDN of its own, so static assets want a CDN in front for anything traffic-heavy.
Render
- Best for
- A predictable monthly bill for a straightforward Next.js app.
- Pricing
- Free web services are available but spin down after 15 minutes without traffic. The cheapest paid instance, Starter, is $7/month for 0.5 vCPU and 512 MB RAM.
- A real free tier for evaluating, and simple fixed instance pricing after that.
- Managed Postgres, Redis, cron jobs and workers all in one place.
- Static assets are served through a CDN without extra setup.
- Free services spin down after 15 minutes idle.
- Fixed instance sizes mean you provision for the image optimizer's peaks rather than the app's small steady state, so the 512 MB Starter tier has less spare room than the baseline numbers suggest.
Granite
- Best for
- A Next.js front end that belongs next to its database, its cache and its uploads rather than calling them across the internet.
- Pricing
- Hobby is $9/month and includes $15 of monthly usage credits. Advanced is $39/month with $50 of credits, Professional $149/month with $200. Every plan has unlimited workspace seats.
- Postgres or MySQL, Valkey and S3-compatible storage run in the same project over internal DNS — Valkey is exactly what a shared ISR cache handler needs, and the bucket is where uploads belong.
- Flat plan pricing with usage credits, so the bill does not move with traffic spikes.
- Runs your own image, so the standalone build and its Node version are yours to pin.
- Background workers and cron jobs are first-class, which covers revalidation jobs and scheduled work.
- No free tier — the cheapest way in is $9/month.
- No global edge network: you pick a region, and visitors far from it pay the latency.
- Preview environments per pull request are not part of the workflow the way they are on Vercel.
Koyeb
- Best for
- Edge presence with scale-to-zero for a mostly-idle app.
- Pricing
- The Pro plan is $29/month; Scale is $299/month. Serverless Postgres has a small free allowance.
- Edge locations included, which helps recover global latency.
- Node cold starts are quick enough that scale-to-zero is tolerable here, unlike heavier runtimes.
- The highest entry price of the managed options.
- Scale-to-zero and ISR interact badly: a cold instance has an empty cache and regenerates pages a warm one would have served instantly.
Google Cloud Run
- Best for
- Bursty traffic where an idle app should cost nothing and you are comfortable in GCP.
- Pricing
- No monthly fee. You pay per request and per resource-second, with a monthly free allowance. Cloud SQL and networking are billed separately.
- Scales to zero and has effectively no ceiling.
- Takes any container, so a standalone build deploys unchanged.
- Per-request billing suits spiky marketing traffic.
- No persistent disk, so the default filesystem ISR cache is useless — a shared cache handler is mandatory, not optional.
- Every instance keeps its own in-memory state, so revalidation across instances needs deliberate design.
- Database, CDN and secrets are separate products you assemble and bill separately.
What a Next.js app actually needs from a host
- output: 'standalone'
- The single most important line in next.config when self-hosting. It produces a server bundle with only the dependencies actually used, so you ship that instead of the whole node_modules tree. It is the difference between an image measured in gigabytes and one measured in hundreds of megabytes.
- A shared ISR cache
- By default the incremental cache is written to the local filesystem. With one instance that is fine. With two, they disagree about what is current, revalidation happens twice, and users see pages flip between versions. Point a custom cache handler at Redis or Valkey before you scale past a single replica — or on any platform without a persistent disk, before you deploy at all.
- Image optimization
- next/image optimises on the server, and it is the most resource-hungry thing in a typical Next.js app. Self-hosted, that cost lands on your instance: an uncached burst of large images is the classic way to exhaust a small container. Give it headroom, put a CDN in front of it, or hand the work to an external loader.
- Build-time versus runtime env
- Anything prefixed NEXT_PUBLIC_ is baked into the bundle at build time. That means one image cannot serve staging and production with different public values — you either rebuild per environment or keep those values out of the client. This surprises almost everyone once.
- Middleware on every request
- On Vercel middleware runs at the edge before your app. Self-hosted it runs inside the Node server on every matched request, so its cost is now your cost. Narrow the matcher, and do not put anything expensive there.
- Small baseline, spiky peaks
- A standalone Next.js server idles in roughly a hundred megabytes — light next to an interpreted stack running several worker processes, and the reason the cheapest tiers stay viable longer here. What you actually size for is the image optimizer, which allocates per image while generating variants. Provision for the peak rather than the average, and keep a CDN in front so the peak is rare.
- Uploads and the filesystem
- The container filesystem is discarded on deploy and not shared between replicas, so anything a user uploads belongs in object storage from the first commit, not after the first data loss.
$ docker images next-app
REPOSITORY TAG SIZE
next-app naive 2.5GB
next-app standalone 416MB
So which should you pick?
Next.js is the product and you want zero infrastructure work. Vercel. Budget $20 per seat per month and set a spend limit on day one.
The bill got unpredictable, or the app needs to sit next to its data. This is where we would argue for Granite: a standalone build runs as a normal service, and Postgres, Valkey and S3-compatible storage are in the same project over internal DNS. Valkey doubles as the shared ISR cache, which is the one piece of self-hosting people usually get wrong. Flat plans from $9/month, so a traffic spike changes your graphs and not your invoice.
Global audience on a small budget. Fly.io, accepting that multi-region makes the shared cache mandatory rather than optional.
Mostly idle, bursty, and already in GCP. Cloud Run — with a cache handler configured before the first deploy, because there is no disk to fall back on.
Running an API behind the front end? The Go and Django comparisons cover the same platforms from the back-end side, and the app platform page covers workers and cron jobs.
Hosting for other stacks
Six ways to run a Go binary, from a $2 machine to scale-to-zero — and why Go stays cheap longer.
Seven options weighed on the things Django actually needs: media storage, a real Postgres, Celery workers and enough memory for gunicorn.
Six platforms plus Kamal, weighed on what Rails really needs: a release phase for migrations, a job runner, Active Storage and enough memory for Puma.
Laravel Cloud and six alternatives, weighed on queue workers, the scheduler, writable storage and the caches you must rebuild on every deploy.