Column

Kubernetes shows up on every "how do we scale past Vercel" roadmap sooner or later. For a five-person team shipping a Next.js app, that's not automatically good news. Kubernetes solves real problems, but it also hands you a second full-time job: running the cluster itself. The question worth answering first isn't "can we run Next.js on Kubernetes" — it's "should we, at our size, right now."

This is a decision checklist for that question, not a tutorial on writing Kubernetes manifests. If you're a Next.js team of one to fifteen engineers weighing a move off Vercel, work through the signals below before you touch a Helm chart.

What "small team" actually means for this decision

Team size matters here for one reason: on-call capacity. A 200-engineer platform org can absorb the operational load of Kubernetes because a handful of people already do it as their job. A five-person startup can't quietly add "run a Kubernetes cluster" to everyone's plate without it showing up somewhere — usually in the next feature that ships two weeks late.

So "small team" in this checklist means: nobody on the team has "platform engineer" in their job title, and standing up new infrastructure competes directly with product work. If that's you, every signal below should be read through that lens.

Signal 1: Your Vercel bill is the symptom, not the disease

Teams usually start this conversation because a Vercel invoice jumped. That's a real trigger, but cost alone is a weak reason to move to Kubernetes — a smaller Vercel plan, moving static assets to a CDN, or renegotiating usage can often fix a billing problem without a migration.

The stronger signal is when the reason the bill grew is structural: bandwidth-heavy traffic that doesn't fit a serverless pricing model, a compliance requirement that data stay in a specific region or on infrastructure you control, or multiple products that would each need their own Vercel account. Managed Kubernetes cost breakdowns are worth reading before you commit either way — "full Kubernetes" pricing varies a lot more by provider and cluster design than most cost comparisons assume, and the naive EKS-vs-Vercel math is usually wrong in both directions.

Signal 2: You need control Vercel doesn't give you

Some requirements simply don't fit a managed serverless platform: running on-prem or in a specific cloud region for data residency, integrating with existing internal services over a private network, or running long background jobs that exceed serverless execution limits. Next.js's own deployment documentation is explicit that self-hosting is a first-class option, precisely because these constraints are common enough that Vercel isn't always the right fit.

If your constraint is technical rather than financial, that's a much stronger case for Kubernetes than cost alone. It also means the migration is closer to mandatory than optional — worth knowing before you spend a quarter debating it.

Signal 3: Someone can own day-two operations

This is the signal small teams skip, and it's the one that actually predicts whether the migration goes well. Deploying Next.js to Kubernetes once is a weekend project. Keeping it running — rolling out zero-downtime deploys, scaling under real traffic, restarting a pod that OOMs at 2 a.m. — is ongoing work with no natural stopping point.

Before moving, ask concretely: who configures autoscaling so a traffic spike doesn't page someone at midnight, and who's still around to tune it three months later? The HPA, VPA, and KEDA comparison for Kubernetes autoscaling is a useful gut check here — if the tuning tradeoffs it describes sound like more configuration than your team wants to own indefinitely, that's a signal worth listening to, not a problem to power through.

If nobody can answer that question with a name, Kubernetes isn't ready for your team yet — regardless of how compelling signals 1 and 2 are.

What Kubernetes buys you that a single VM doesn't

It's worth being honest about why a single big VM or a simple PaaS isn't the obvious alternative once signals 1 or 2 are true. Kubernetes gives you a portable, standard way to describe how your app scales, heals, and rolls out — the same primitives whether you run on AWS, on-prem hardware, or a different cloud next year. A hand-rolled VM setup gives you none of that for free; you rebuild it yourself, usually worse, under deadline pressure.

That portability is exactly what closes the gap between "we need control" and "we still want something close to Vercel's workflow." Standard Kubernetes APIs mean you're not locked into one vendor's proprietary scaling model, which matters if your infrastructure needs might change again in two years.

This is usually where teams get stuck: Kubernetes solves the cost and lock-in problem, but now someone has to run the cluster. Kubo gives you standard Kubernetes — the same APIs as EKS or AKS — with the operational plumbing already wired, so a small team doesn't need a dedicated platform engineer just to get started.

The checklist

Answer these five questions before you decide:

1. Is the reason for moving structural (compliance, region, integration) rather than just a cost spike that a smaller plan would fix?
2. If it's cost, have you compared real managed-Kubernetes pricing rather than assuming EKS list prices?
3. Can you name the person who owns autoscaling, deploys, and 2 a.m. incidents six months from now — not just at launch?
4. Does your app need anything Vercel's serverless model structurally can't do (long-running jobs, private networking, specific regions)?
5. If you moved today, would it delay a specific product milestone your team already committed to?

Two or more "yes" answers to questions 1, 3, and 4 is a reasonable bar for moving forward. A "no" on question 3 alone is a reason to wait, regardless of the others.

Common mistakes teams make with this decision

The most common failure mode isn't choosing wrong — it's choosing right for the wrong reason. A team that moves to Kubernetes purely to fix a Vercel bill, without a structural driver, often ends up with a bigger total cost once engineering time is counted, because nobody budgeted for the ongoing operational work. The migration "succeeds" technically and still hurts the business.

The second common mistake is treating the decision as permanent and irreversible, which makes it feel higher-stakes than it is. In practice, a Next.js app is one of the more portable workloads to move between platforms precisely because Next.js itself doesn't lock you into Vercel-specific APIs for the core framework. That portability is a reason to decide based on today's constraints rather than trying to future-proof against every scenario you might hit in three years.

The third is skipping signal 3 because signals 1 and 2 feel urgent. Teams under budget or compliance pressure tend to greenlight the move first and figure out who owns operations later. That ordering is backwards — it's the exact pattern that turns a planned migration into an unplanned one, six months in, when the person who set up the cluster moves to a different project.

If the answer is "not yet"

Not every team needs to solve this today. If your bill is the only symptom, start by testing whether infrastructure changes within Vercel's model resolve it before evaluating a platform migration. Revisit the checklist when a structural requirement (signal 2) actually appears, rather than pre-emptively building for a scale you haven't hit.

If the answer is "yes"

If you're a solo developer or running a side project, the Ashigaru plan starts at ¥8,800/month; most small teams land on Ronin at ¥17,600/month. Compare the plans and start with the one that matches your workload.