Column

Vercel makes shipping a Next.js app trivial on day one. The friction shows up later — when the invoice jumps after a traffic spike, when a client asks for on-prem deployment, or when you need a feature Vercel's platform doesn't expose. At that point the question isn't "should we leave," it's "where do we actually go." This guide compares the realistic hosting options for a production Next.js app outside Vercel, and when each one makes sense.

Why teams start looking beyond Vercel

The two most common triggers are cost and control. Vercel's pricing scales with bandwidth, function invocations, and image optimization usage — all of which grow with traffic, not with your budget. The second trigger is control: enterprise clients asking for data residency, teams that already run infrastructure elsewhere and don't want a second vendor, or workloads (long-running jobs, WebSocket servers, custom networking) that don't fit a serverless-first platform.

Neither trigger means Next.js itself is the problem. The framework runs fine outside Vercel — the next build command with output: "standalone" produces a self-contained Node.js server that needs no Vercel-specific runtime. The real decision is what you run that server on.

Option 1: A single VPS or VM

The simplest path: a DigitalOcean droplet, an EC2 instance, or a Hetzner box running the standalone Next.js server behind Nginx or Caddy for TLS termination, with pm2 or a systemd unit keeping the process alive.

• Good for: side projects, internal tools, low-traffic marketing sites, teams validating that self-hosting is viable before investing more
• What you give up: no automatic scaling, no zero-downtime deploys without extra tooling, and you own patching, monitoring, and TLS renewal yourself
• Cost: the lowest entry point, often $5–20/month, but it doesn't grow gracefully — a traffic spike means manually resizing the box, not autoscaling

A single VM is a reasonable starting point, but it's rarely where teams stay once the app matters to the business. The operational gaps (deploys, TLS, health checks) are exactly what the next two options solve.

Option 2: A container platform (Fly.io, Railway, Render)

These platforms take the standalone Next.js Docker image and handle the orchestration layer for you — load balancing, TLS, rolling deploys, and basic autoscaling — without requiring you to run Kubernetes yourself.

• Good for: teams that want Vercel-like deploy ergonomics (git push to deploy) without Vercel's serverless pricing model or vendor-specific APIs
• What you give up: less control over the underlying infrastructure than a full cluster, and some platforms still meter usage in ways that surprise you at scale
• Cost: generally more predictable than Vercel for CPU-bound workloads, since you're paying for compute time rather than per-invocation

This tier is a good middle ground, but it's still a single vendor's abstraction. If your organization already runs other services, standardizing on one platform for everything — rather than one tool per app — usually wins in the long run.

Option 3: Kubernetes (self-managed or managed)

Running Next.js as a containerized Deployment on Kubernetes gives you the most control: horizontal pod autoscaling based on real traffic, the same TLS and ingress patterns you likely already use for other services, and no per-request billing surprises.

The tradeoff that stops most teams here is operational cost, not compute cost. The real cost of running your own Kubernetes control plane is the engineer-hours spent on upgrades, etcd maintenance, and security patching — work that has nothing to do with shipping your Next.js app. That's the gap managed Kubernetes exists to close: the control plane is someone else's problem, but you still get standard Kubernetes underneath, not a proprietary platform API.

If you're already leaning toward Kubernetes, the next decision is which distribution. For a single Next.js app plus a handful of supporting services, choosing between full Kubernetes and a lighter distribution like K3s usually comes down to cluster size and how much multi-tenancy you actually need — most teams moving off Vercel don't need the full EKS/AKS feature set on day one.

Matching the option to where you actually are

Situation	Best fit
Side project, low traffic, no SLA	Single VPS
Want git push deploys without Vercel's pricing	Container PaaS
Already run Kubernetes for other services	Self-managed or managed Kubernetes
Need standard Kubernetes without running the control plane	Managed Kubernetes
Enterprise client needs on-prem or specific cloud	Kubernetes (portable across EKS/AKS/on-prem)

The common failure mode is skipping straight to Kubernetes because it looks like the "serious" option, then spending the next two quarters on cluster operations instead of product work. The VPS and container-PaaS tiers aren't consolation prizes — they're the right answer for a real share of teams, at least until traffic or compliance requirements force the next move.

What this means if you're weighing the move

If you're migrating off Vercel, standalone output and environment variable handling are worth getting right before you pick infrastructure — both behave differently outside Vercel's build pipeline, regardless of where you host. Once the app itself is portable, the hosting decision becomes a question of how much operational work you want to own.

When you're ready to run Next.js on Kubernetes without taking on the control plane yourself, Kubo gives you standard Kubernetes — the same APIs, the same manifests, no vendor lock-in — with the operational overhead handled for you. Plans start at the Ashigaru tier for ¥8,800/month for individual developers and small projects, with most small teams landing on Ronin at ¥17,600/month for more headroom. If a single VPS or container PaaS is still serving you well, there's no need to move early — but when the control plane itself becomes the bottleneck, that's the point to look at Kubo.