Vercel Alternatives

The email that ends most Vercel love stories lands on the first of the month. Mine arrived a while back, after a client's launch went better than planned: one modest Next.js marketing site, one unusually good week of traffic, and a bill that had quietly drifted from $20 to somewhere north of $300. Nothing had broken. Nothing was misconfigured, except my assumption that a $20 seat price meant $20 a month.

I've been wary of flat-rate illusions ever since. And to be fair to Vercel before I explain when to leave it: the platform is genuinely good at what it does. Git push to a global deployment in seconds, preview URLs for every pull request, first-class Next.js support, image optimization and edge middleware baked in. Plenty of teams should never move off it. But the billing model has a shape you need to understand before you commit, and some workloads simply don't fit it.

This piece is about both sides: when leaving makes sense, when it doesn't, where I'd go instead, and how to move without taking your site offline.

When it makes sense to leave Vercel

When the bill stops being predictable

Vercel's pricing is metered at every layer. The Pro plan is $20 per user per month at time of writing, and on top of that sit usage charges: bandwidth, edge requests, function invocations, image optimization, builds. Pro teams get a monthly usage credit (reported at $20) that absorbs some overage, but a popular month can run through it quickly.

What makes this painful is variance. If your monthly bill swings from $45 to $320 and back down because one page hit the front page of Hacker News, you don't have a hosting cost — you have a revenue share with randomness. In my own testing of client sites, the surprise never comes from the traffic you planned for. It comes from a bot crawl, an unoptimized hero image with forty variants, or edge middleware running on every request to flip an A/B flag. Each is individually cheap. Multiplied by millions of requests, they are not.

If you find yourself checking the usage dashboard daily, or your finance person has asked you to cap this somehow, that's the signal. Vercel does offer budget tooling and spend caps, but a capped site that pauses is worse than a predictable one.

When the Hobby plan's fine print catches up with you

The Hobby plan is free, and for personal projects it's a genuinely generous offer. But read the terms: Hobby is restricted to personal, non-commercial use. By Vercel's own fair-use guidelines, that excludes ads, affiliate linking as a primary purpose, selling anything, and even donations — and it excludes projects where someone was paid to build the site. If your portfolio site quietly becomes a small business, you are on the wrong plan.

There's a second edge: Hobby has hard monthly allowances for things like function invocations and image transformations, and when you blow through them, the usual consequence is waiting until the next 30-day window rather than paying. For a hobby project that's fine. For anything with a deadline, it's not.

When the platform gets in the way

Three recurring complaints from teams I've worked with:

• Team costs. Seats are billed per user. A five-person team is five $20 seats before a single request is served. That's cheap against salaries and still annoying when a part-time contractor needs deploy access.
• Compliance and data location. If your customers are European hospitals, banks, or public-sector buyers, "where does the data live and who can access it" becomes a legal question. I've watched a deal die over exactly this. Vercel's infrastructure is US-centric by default; there are EU regions for compute, but enterprise procurement doesn't always accept the answer.
• Lock-in by convenience. Edge Config, blob storage, cron jobs, environment wiring — each is easy to adopt and a chore to extract. Not a problem until you want to self-host on a VPS in Germany or move to AWS, at which point you discover how much of your app is just a Vercel thing.

There's also the plain architectural case: long-running processes, WebSockets, arbitrary containers, background workers that shouldn't be serverless functions. I've seen teams build elaborate workarounds — queue-driven architectures, external socket services — to keep something on Vercel that wanted to be a process. The workaround usually costs more than the hosting it saved. Vercel's model is request/response. If your app wants to hold a socket open for twenty minutes, the platform is fighting you.

When you've outgrown the reasons you arrived

Sometimes nothing goes wrong — the fit just quietly ends. I see this most with sites that started as ambitious Next.js apps and settled into content: a marketing site and a blog, barely any dynamic rendering, almost no server work. If the traffic is a few thousand visits a month and the build is mostly static, you are paying platform prices for shared-hosting work. Moving to a small always-on server or a static host usually cuts the bill by an order of magnitude, and the maintenance cost is one box to patch or one host to call. The reverse happens too: teams that arrived for free hosting and now run a real business on Hobby terms they no longer meet. Both are clean exit signals.

When you should stay

Honest counterpoint, because I see people flee too early:

• Your bill is under roughly $100 a month and stable. At that level, the developer time you'd spend self-hosting costs more than the overage risk. Vercel's developer experience is legitimately excellent.
• You're on Next.js and you use its features. ISR, streaming SSR, edge middleware, image optimization — reimplementing these elsewhere is real work. Next.js runs outside Vercel, but the sharp edges are yours to sand.
• Your traffic is genuinely global. The edge network is the product. A small VPS in one region will lose on latency for worldwide audiences.
• Nobody on the team wants to own infrastructure. I like a well-run server as much as anyone. But if nobody will patch it at 2am, paying for a managed platform is rational.

One more: if you're pre-revenue and on Hobby within its rules, stay. Free hosting with zero ops is the correct answer for a portfolio site.

What staying costs, for the record: on Pro, budget the $20 seat plus whatever your traffic shape draws in usage, and set a spend alert in the first week rather than discovering the pattern in an invoice. Vercel's budget tooling will email you at thresholds you choose. The teams I've seen happiest on the platform are the ones who set those alerts before their first busy month.

The alternatives

These are the options I'd actually put in front of someone moving off Vercel. Pricing is what I could verify at time of writing — check current rates before budgeting.

A note on how to use the numbers below: with usage-based platforms, the headline price is a floor and your traffic shape sets the bill, while flat per-server platforms bill the same in month thirteen as in month one. Where I quote per-GB or per-seat figures, assume they move; where I quote plan prices, assume they're slower to change but still verify.

Render — the closest "just deploy my app" swap

Render runs web services, workers, cron jobs and Postgres on one platform, and the entry paid tier is a Starter web service at $7/month (0.5 vCPU, 512 MB) at time of writing, with Standard around $25/month for 1 vCPU and 2 GB. There's a free tier, but free web services spin down after idle periods and take a while to wake up — fine for demos, bad for production. Egress beyond the included transfer is billed per GB.

Who it's for: full-stack apps and APIs that want persistent services and a managed database without becoming a sysadmin. It's less edge-fast than Vercel for global static sites, and more predictable for server-backed apps.

Railway — usage-based, billed by the second

Railway charges a subscription that doubles as usage credit: Hobby is $5/month including $5 of resource usage, Pro is $20/month including $20, with per-second metering for CPU, memory and egress beyond that. It's excellent for side projects and small teams — one clean deploy flow, private networking, volumes.

The trap to know: the subscription is a minimum, and merely stopping deployments doesn't stop billing if services still exist. Set a spend cap on day one. I do this on every Railway account I open.

Netlify — the natural swap for static and JAMstack sites

If your Vercel project is mostly static with serverless bits, Netlify is the one-for-one comparison. Its current pricing is credit-based: a Free plan with 300 monthly credits, Personal at $9/month, and Pro starting at $20/month with unlimited seats — Netlify removed per-seat charges in 2026, which matters if team-seat cost is part of why you're leaving. Bandwidth and web requests draw down credits; when they run out, paid plans can auto-recharge.

Who it's for: marketing sites, docs, blogs, and apps where the backend lives elsewhere. Not for long-running servers or WebSocket workloads.

Cloudways — managed servers when you want out of serverless entirely

Cloudways (a DigitalOcean company) sells managed cloud servers on DigitalOcean, Vultr, Linode/Akamai, AWS or Google Cloud. At time of writing a 1 GB DigitalOcean Standard server runs about $11/month and a Premium NVMe one about $14/month, billed hourly with a monthly cap and no renewal jump. You get a tuned stack, staging, backups, SSH, and a control panel.

Who it's for: WordPress, WooCommerce, Laravel and PHP apps, or anything that wants a persistent server with someone else handling patching. It's not a Next.js deployment platform — you'd run the app yourself on the server.

Kamatera — build-to-order cloud servers

Kamatera lets you size a server to the spec you need and bills monthly or by the hour. The Basic preset was $4/month at time of writing (1 vCPU, 1 GB RAM, 20 GB NVMe, 5 TB transfer), with a 30-day trial worth up to $100 of usage. Note the cheap preset uses budget CPUs — the general-purpose tier is around $25/month.

Who it's for: people who want root access and exact control over CPU, RAM and region, and who are comfortable running their own stack.

Akamai Cloud (Linode) — predictable bandwidth economics

The classic Nanode is $5/month at time of writing (1 shared vCPU, 1 GB RAM, 25 GB storage, 1 TB transfer), and bandwidth beyond the allowance is billed at a low per-GB rate. Billing is hourly up to the monthly cap.

Who it's for: bandwidth-heavy, predictable workloads — APIs, small services, side projects where a fixed $5/month beats a metered surprise. It's a Linux box: the deployment pipeline, TLS, and scaling are yours. If you've never run a server, add a weekend of learning to the price; if you have, it's a very short afternoon.

How to switch without downtime

Moving off a deployment platform is easier than moving off shared hosting, but the details matter. The sequence I use:

1. Pick the target and deploy in parallel first. Never cancel Vercel before the new stack serves traffic. Get the app running on the new provider on a temporary domain and load-test it with production-like traffic.
2. Audit the Vercel-specific features you use. Make a list: ISR revalidation, edge middleware, image optimization, cron, blob storage, environment variables, preview branches. For each, decide the replacement. Often it's moving middleware into the app, or swapping image optimization for a build-time step.
3. Migrate stateful things early. Databases, object storage, uploaded files. Copy, verify counts and checksums, then set up ongoing sync so the cutover doesn't lose writes.
4. Lower your DNS TTL a day or two before cutover. If your TTL is a week, start early. This is the single most common cause of a migration that takes three days to finish.
5. Cut over at a quiet hour. Switch the DNS record, keep the Vercel deployment alive as a rollback, and watch error rates and logs for at least 48 hours. Don't delete anything until a full business cycle has passed cleanly.
6. Then decommission. Remove the domain from Vercel, downgrade the team, and keep a written note of what you migrated in case you need to reverse it.

Two mistakes I've made, so you don't have to: flipping DNS before the new stack had ever served a production-like load test (the cutover became the load test), and deleting environment variables from the old project before the new deployment was confirmed working. Keep both platforms fully configured until the dust settles — the storage costs less than the downtime.

For static sites, steps 1 through 6 are an afternoon. For apps using middleware and edge storage, budget days, not hours.

How we evaluate hosting providers

We do this the same way every time, and the headline is always renewal pricing, not the introductory number. I read the provider's own pricing and terms pages first, note what the plan costs on day one and on day 300, and quote both — where a figure moves or I can't pin it down, I say "at time of writing" rather than inventing one. Second, I look at what breaks at scale: metered overages, seat charges, resource ceilings, and support quality when something actually goes wrong. Third, I weigh lock-in and migration effort, because the cheapest plan is a bad deal if leaving costs a week of engineering. No provider pays for placement here, and when a platform is the right answer I say so — including the one this article is about.