The best Vercel alternatives in 2026

Almost everyone searching for a Vercel alternative is doing it for one of three reasons: the bill grew faster than the traffic, a workload doesn't fit the function model, or someone in a compliance review asked where the code runs. Those lead to different answers, and the generic 'top 10 alternatives' list serves none of them well.

I build PandaStack, which is one of the options below. I'll flag where it fits and — more usefully — where it doesn't.

What Vercel is doing that you'll be doing

Vercel's product is mostly invisible, which is why migrations underestimate it. Before you compare anything, count how many of these you depend on.

• A global CDN with automatic cache invalidation on deploy. This is the big one and it's genuinely good.
• Image optimisation — resizing, format negotiation, and caching, as a service.
• Preview deployments per pull request with a unique URL, plus comments on them.
• Instant rollback to any previous deployment, because every deployment is kept and addressable.
• Edge middleware running before the cache.
• ISR with a cache shared across all instances and regions, and on-demand revalidation that actually reaches all of them.
• Framework-version tracking: Next.js features work the day they ship.

Pick by why you're leaving

Leaving because of cost

First, find out what's expensive. Vercel bills bandwidth, function invocations and duration, and image optimisation separately, and one of those is usually dominating. It's frequently bandwidth from a heavy asset or bot traffic that never touches a function.

If it's bandwidth, a CDN in front of a modest origin fixes it for a small fraction of the price, and that's true whether the origin is a container PaaS, a microVM, or a VPS. If it's function invocations, the answer is a long-lived server: one process serving many requests has a completely different cost curve than per-invocation billing, and the crossover point arrives earlier than most people expect. If it's image optimisation, move it to a CDN that includes it.

Leaving because the workload doesn't fit

Functions have a maximum duration, no persistent process, no filesystem you can rely on, and no way to hold a socket. If you need background jobs, WebSockets, a long-running build, a queue consumer, or an in-memory cache shared across requests, you don't need a cheaper Vercel — you need a server.

Container PaaS platforms — Render, Railway, Fly.io, Koyeb, Northflank — are the direct answer here. Your Next.js app builds with `output: 'standalone'` and runs as `node server.js`, and everything that was awkward becomes ordinary.

Leaving because of isolation or data-residency requirements

This is where microVM platforms come in, and it's my category, so weigh accordingly. If your app runs code it didn't write — an agent executing generated code, a customer-supplied transform, a notebook backend — a shared-kernel function runtime is a hard thing to defend in a security review. A microVM gives each workload its own kernel, and because a machine can be created through snapshot-restore in about 179ms at p50, per-request or per-tenant isolation is affordable rather than aspirational.

If you're a marketing site with a contact form, this is not your category and I'd point you at the CDN-plus-static options.

The shortlist, honestly

• Netlify — the closest like-for-like. Same shape, similar DX, different pricing. A migration measured in hours, and a similar structural cost model, so check it solves your actual problem.
• Cloudflare — cheapest bandwidth in the industry and an excellent CDN. Server code runs in V8 isolates rather than Node, so audit native dependencies and database drivers before committing.
• Container PaaS (Render, Railway, Fly.io, Northflank, Koyeb) — a real server, predictable pricing, background work included. You add a CDN and an ISR cache handler yourself.
• MicroVM platforms (Fly Machines, PandaStack) — a real server with a kernel boundary. Right when isolation is a requirement or the app provisions environments at runtime.
• Self-managed on a cloud VM — cheapest at scale, most attention required. Reasonable if you already have a platform team.
• Staying on Vercel with the expensive thing fixed — genuinely the best answer more often than a vendor will tell you. A CDN in front of your assets, or one heavy route moved off, frequently removes the reason to migrate.

How to migrate without a bad week

1. Build with `output: 'standalone'` locally and run `node .next/standalone/server.js`. If that works, your app is portable; if it doesn't, fix that before choosing a platform.
2. Inventory your environment variables and mark which are needed at build time. NEXT_PUBLIC_* values are inlined during the build, and a platform that injects them only at runtime will hand you undefined values in the browser bundle.
3. Set up the CDN before you cut over, not after. It's the piece with the most surprising defaults.
4. Configure an ISR cache handler backed by shared storage if you use revalidation, then test by revalidating and reloading a dozen times to check for flapping.
5. Run both platforms in parallel behind a traffic split for a full week, including a weekend, before moving DNS properly.

# Prove portability locally before choosing anything
# next.config.js: module.exports = { output: 'standalone' }
npm run build
node .next/standalone/server.js

# Then the deploy is just "run that command somewhere"
pandastack apps create --name web \
  --git-url https://github.com/acme/web \
  --start-cmd 'node .next/standalone/server.js'

The short version

Diagnose before you migrate. If bandwidth is the bill, a CDN fixes it wherever you host. If invocations are the bill, a long-lived server changes the curve. If the workload needs a process, go to a container PaaS. If the isolation boundary is a requirement, look at microVMs. And if Vercel works and the bill is fine, the correct number of weeks to spend migrating is zero.