Column

A Vercel bill that quietly doubles isn't a billing surprise — it's usage growth finally showing up as a line item. Before you decide what to do about it, it helps to know exactly what you're paying for, and what leaving would actually cost you in engineering time.

This isn't an argument for or against Vercel. It's a framework for the moment when the invoice lands on your desk and someone asks, "should we be paying this much?"

What actually drives a Next.js bill up on Vercel

Vercel's pricing is usage-based, and three line items tend to grow fastest as an app gets real traffic:

• Function invocations and duration — every server-rendered page, API route, and middleware call is billed. Traffic growth multiplies this directly.
• Bandwidth — images, JSON payloads, and static assets served through Vercel's edge network. Media-heavy apps feel this first.
• Image Optimization requests — each unique image transformation counts separately from bandwidth, and it's easy to undercount how many variants a responsive <Image> component generates.

Vercel documents these usage categories and current rates on its pricing page and its Fair Use Policy. The pattern worth noticing: none of these costs are fixed. They scale with your product's success, not with a plan you chose once.

That's fine when the app is small. It becomes a real question once monthly spend crosses the point where a fixed-capacity server would be cheaper — and for many teams, that point arrives faster than expected, because traffic growth is rarely linear.

The decision isn't "Vercel vs. self-host" — it's three separate questions

Teams often frame this as a single binary choice. It's really three, and they don't all point the same direction.

1. Is the cost driver structural or temporary?

A traffic spike from a launch or a viral post is temporary — don't re-architect your hosting around it. A steady increase in daily active users, or a media-heavy feature that shipped last quarter, is structural. Pull three months of usage data before deciding anything; one expensive month is not a trend.

2. What are you actually paying Vercel for, beyond compute?

Vercel bundles global edge deployment, preview environments per pull request, automatic image optimization, and zero-config CI/CD. Self-hosting doesn't remove this work — it moves it to your team. If nobody on the team currently owns ingress, TLS certificate rotation, or deployment rollback, that's a real cost, even if it doesn't show up on a cloud invoice. Underestimating this is the single biggest reason self-hosting migrations run over budget.

3. Does your app's shape fit self-hosting well?

Next.js features map unevenly onto self-hosted infrastructure:

Feature	Self-hosting difficulty
Standard SSR / API routes	Low — works well behind any Node process
ISR (Incremental Static Regeneration)	Medium — needs a shared cache layer across replicas
Edge Middleware	Medium-high — Vercel's edge runtime isn't identical to a generic Kubernetes ingress
Image Optimization	Medium — replace with sharp or an external service
Cron / scheduled functions	Low — any scheduler works, just isn't automatic anymore

If your app leans heavily on Edge Middleware for auth or personalization at every request, that's the piece most worth prototyping before you commit to a migration date.

What self-hosting actually replaces

Say the math points toward moving off Vercel. The realistic destination for most teams isn't a hand-rolled EC2 box — it's a container on Kubernetes, because that's what gets you back the things Vercel was doing for free: repeatable deploys, horizontal scaling, and rollback.

That means picking up operational work that Vercel used to hide:

• Autoscaling. Vercel scales functions per-request, invisibly. On Kubernetes, you configure this yourself — the complete guide to HPA, VPA, and KEDA walks through how to size a deployment so it tracks real traffic instead of either over-provisioning or falling over during a spike.
• Environment sprawl. Preview deployments were free and automatic on Vercel; on your own cluster, every preview environment is a namespace someone has to provision and eventually tear down. How many environments do you really need? is worth reading before your staging environments quietly multiply into a cost problem of their own.
• The actual infrastructure bill. This is where the math either works or doesn't. One team's breakdown of running full Kubernetes operations under $400/month with lightweight K3s is a useful reference point for what a right-sized cluster costs in practice, versus what a managed-everything setup costs by default.

This is usually the point where the math stops working in your favor if you try to rebuild all of it from raw cloud primitives: bandwidth and function invocations scale with traffic, but so does the operational surface area you now own, and neither gets cheaper just because you left Vercel. Kubo runs standard Kubernetes with that plumbing — ingress, TLS, monitoring — already wired, so self-hosting doesn't mean rebuilding Vercel's workflow from scratch on bare infrastructure.

A rough checklist before you commit

Before scheduling a migration, get honest answers to these:

1. Three months of Vercel usage data, broken down by function invocations, bandwidth, and image optimization — not just the total bill.
2. A list of every Edge Middleware and Image Optimization dependency in the codebase, since these need explicit replacements off Vercel.
3. Who owns Kubernetes on the team after migration — not who can learn it, who owns it on a Tuesday at 2am.
4. A cost estimate for a right-sized cluster, not a worst-case one. Most Next.js apps don't need the capacity teams initially provision out of caution.

If the answers hold up, self-hosting is a reasonable next step, not a leap of faith.

Where this leaves you

None of this means Vercel is a bad choice — for a lot of apps, at a lot of stages, it's the correct one. The point of this framework is to replace "the bill feels too high" with a specific, structural answer: which cost is growing, what it's actually buying you, and whether your app's feature set fits a self-hosted platform well enough to make the move worth it.

If the numbers point toward moving off Vercel, that doesn't have to mean owning a Kubernetes cluster from scratch on day one. Kubo's entry plan (Ashigaru) starts at ¥8,800/month, and most small teams moving off Vercel land on the Ronin plan at ¥17,600/month. See how the plans compare against what you're currently paying, using the usage breakdown from step one above.