Vercel alternatives: when to leave, and the realistic options

When Vercel is the right choice

Be honest about this first. Vercel gives you git-push deploys, preview environments for every pull request, a global CDN and first-class Next.js support with almost no configuration. For a small team building a Next.js frontend, that convenience is worth a premium – often more than the engineering time it would take to replicate it.

If your bill is a small fraction of payroll and your app fits within the function model, stay. Migrating to save a modest amount a month while spending weeks of engineering time is a bad trade.

Signs you’re outgrowing it

• “Vercel too expensive” is a recurring conversation. Vercel charges a platform fee and per-seat charges for team members who deploy, plus metered usage across several dimensions – function execution, data transfer, edge requests, image optimization and more. Traffic spikes, bot crawls, large uncached responses and image-heavy pages can each drive one of those meters, and the bill can grow faster than revenue.
• You’re fighting function limits. Serverless functions have execution time, memory and payload limits that depend on your plan. Long reports, large file processing, PDF generation and AI calls that stream for minutes push against them.
• You need a real backend. Always-on job workers, processes that run for hours and long-lived stateful connections still fit poorly with the function model. Vercel has added WebSocket support, Workflow and Queues, but connections close at the function’s maximum duration and state has to live elsewhere, so teams with heavy backend needs often end up on a second platform anyway.
• Database connection churn. Many short-lived function instances opening Postgres connections exhaust the database without a pooler.
• Compliance or data residency requirements that need you in a specific cloud account or region.

Cloudflare (Workers and Pages)

Cloudflare runs your code on its edge network in V8 isolates, with static assets served from the same CDN. Pricing centers on requests and CPU time rather than wall-clock duration or bandwidth, which makes it notably cheap for high-traffic, mostly cached sites and for functions that spend most of their time waiting on network calls. This site is served from Cloudflare Pages.

The trade-off is the runtime. Workers aren’t a full Node.js environment – Node compatibility is good and improving, but not complete – so check your dependencies. Next.js doesn’t run natively: Cloudflare now recommends vinext, its Vite-based reimplementation of the Next.js API, for new apps, and keeps the OpenNext adapter for existing ones – test compatibility either way. For data, Cloudflare has D1 (SQLite), KV, R2 object storage, Queues and Hyperdrive for pooling connections to an external Postgres. Cloudflare now steers new projects toward Workers with static assets rather than Pages.

Best for: content-heavy and high-traffic sites, edge APIs, and teams willing to adapt to the runtime.

Netlify

The closest like-for-like replacement: git-based deploys, preview URLs, serverless and edge functions, forms and a CDN. Next.js support is good and maintained through Netlify’s own adapter. Pricing is credit-based – each plan includes monthly credits that deploys, bandwidth and compute draw down – and it has changed more than once since late 2025, so model it against the current pricing page rather than older comparisons.

Best for: teams who like the Vercel workflow, run frameworks other than Next.js (Astro, SvelteKit, Remix), and want a second option without retooling. It won’t solve backend or function-limit problems any better than Vercel.

Render, Fly.io and Railway

These are application platforms rather than frontend platforms. You run long-lived services – a Next.js server, an API, workers, cron jobs – often next to a managed Postgres and Redis.

• Render bills mostly per instance size, with managed Postgres, background workers, cron jobs and preview environments. Simple and predictable, and the closest to the old Heroku experience.
• Fly.io runs containers as lightweight VMs in regions you choose, billed by the resources you run. Good for running close to users in several regions, with more operational knobs to turn.
• Railway bills by resource usage, with a fast developer experience and easy service composition.

Best for: products where the frontend and backend live together, or where you need workers, WebSockets and persistent connections. Pair them with a CDN in front for static assets. I cover moving between these platforms in Heroku migration work, since the trade-offs are the same.

Self-hosting on AWS or Google Cloud

Next.js runs fine as a Node server in a container: next build with standalone output, a Docker image, and a CDN in front. On AWS, that means ECS on Fargate behind CloudFront, or a serverless deployment via OpenNext and SST on Lambda. Amplify Hosting is AWS’s managed option. On Google Cloud, Cloud Run behind Cloud CDN is the simplest equivalent and scales to zero.

You can also run it on plain servers with Kamal, Coolify or Dokku, which can be the cheapest option by far for steady traffic.

The costs are operational. You own builds, preview environments, cache invalidation, scaling and monitoring. A few Next.js features need extra work self-hosted: ISR and the data cache need a shared cache handler when you run more than one instance, and image optimization works out of the box with next start but runs on your own CPU with a per-instance cache, so at volume you may want a shared cache handler or an external image service.

Best for: teams at a scale where cloud credits, committed-use discounts or existing infrastructure make the economics compelling, and who have DevOps capacity – in-house or through DevOps consulting.

Before you migrate: cut the bill where you are

Many “Vercel too expensive” problems are configuration problems, and fixing them is cheaper than moving:

• Make pages static or cached wherever possible; check which routes are rendering dynamically when they don’t need to.
• Set proper Cache-Control headers so the CDN serves repeat requests – see caching strategy.
• Block or rate-limit abusive bots and crawlers before they reach functions.
• Serve large files and media from object storage and a CDN, not through functions.
• Move long-running work to a queue and a worker on a cheaper platform.
• Turn on spend management and usage alerts so surprises arrive as a notification, not an invoice.

If you’ve done all that and the numbers still don’t work, migrate. If you want help modeling the options or running the move, that’s part of my cloud cost optimization and cloud migration work.

Migration checklist

1. Inventory Vercel-specific features in use: middleware, ISR, image optimization, edge config, cron, analytics.
2. Pick the target per workload – static assets, server rendering, APIs and background jobs may land in different places.
3. Recreate preview deployments; teams miss them more than anything else.
4. Move environment variables and secrets into the new platform’s secret manager.
5. Run the new deployment in parallel on a subdomain and compare responses and performance.
6. Lower DNS TTLs in advance, cut over, and keep Vercel running until you’re confident.

Related

• Picking a Heroku alternative and moving to it without downtime
• AWS cost optimization without breaking production
• Cloud migration consultant for near-zero-downtime moves to AWS and GCP
• DevOps consulting for teams without a platform team
• Choosing a caching strategy that won’t bite you later
• Zero downtime deployment, including the database