Kuberns and Vercel are built around different execution models: Kuberns runs long-running container processes, while Vercel runs framework builds, serverless functions, and a static edge network. Kuberns is a compelling alternative to Vercel for backends, workers, and anything that needs to stay up, and a poor one for a site that is mostly static.
This is the one comparison on this site where the honest answer is often "use both".
Summary
When to choose Kuberns
- Deployment from a repository alone: connect the repo and an AI agent works out the framework, runtime, web port, build commands, and the resources the application needs. Nothing to write first.
- Processes that stay up: websockets, queue consumers, long requests, in-memory caches, and scheduled work inside your own application.
- Managed data beside the app: PostgreSQL, MySQL, and MongoDB as datastores, with Redis, Kafka, and NATS as resources — no separate vendor to add.
- No cold starts: one continuous process rather than an isolate per request.
- Automatic recovery: three layers of container self-healing that classify a failure and act on it.
When to choose Vercel
- Static and edge delivery: a global edge network is the right way to serve a marketing site or a static frontend, and a container is not.
- Next.js integration: image optimization, framework-aware builds, and features that exist because the framework and the platform are built by the same team.
- Serverless economics for bursty traffic: paying per invocation beats paying for a process that idles.
- Preview deployments per pull request: Kuberns environments are per branch, not per PR.
- Edge middleware: code that runs before the request reaches an origin has no container equivalent.
Using both
Unlike the other comparisons on this site, this one has a genuinely complementary answer, and it is often the best one.
Keep the frontend on Vercel, where the edge network and framework integration earn their keep. Move the backend, the workers, and the data services to Kuberns, where a process that stays up and a managed database beside it are the natural shape. The frontend calls the API over HTTPS like any other client.
Teams arrive at this split for a practical reason: the parts of an application that suffer on serverless — long jobs, websockets, queue consumers, anything holding a connection — are exactly the parts that a container handles well, and the parts that suffer in a container — global static delivery — are exactly what an edge network is for.
How the same application is described
The start command
On Vercel there is no start command. You configure the build, and the platform decides how to run the output:
{
"buildCommand": "next build",
"framework": "nextjs"
}On Kuberns the application must start a server that stays up and listens on the port the environment provides:
web: next start -p $PORTThis is the one code-level change most Vercel projects need, and it is small. What is not small is auditing what assumed a fresh isolate per request. Anything that used the filesystem as scratch space between invocations, or relied on per-request isolation for correctness, now shares one process.
Environments
Vercel gives you Production, Preview, and Development, with a preview deployment per pull request. Kuberns gives you an environment per repository branch:
Project your product
└── Service one deployable application
└── Environment one branch, with its own variables and resourcesAn environment owns its own variables, resources, domains, logs, and usage. A long-lived staging branch maps well. A preview for every open pull request does not.
Variables
Both platforms scope variables per environment, and key names carry across unchanged. Two Vercel-specific behaviours need attention:
- Framework-prefixed public variables are baked in at build time on both platforms. Changing one needs a redeploy, not just a variable update.
- Values a Vercel integration supplied automatically will not be in your own variable list. Collect them from the integration.
If your database is already an external managed provider, its connection string carries over unchanged and there is no data migration at all.
Where Kuberns shines
Work that has to keep running
This is the whole argument. A serverless function is built to start, respond, and stop. A queue consumer, a websocket server, a job that takes four minutes, a cache that is worth keeping warm — none of those fit that shape, and every workaround for it is more complicated than a process that simply stays up.
On Kuberns, a background worker is a resource on the environment with its own Procfile command, sitting in the same list as the server and the database. Worker subtypes cover Celery and Node Worker.
Data services included in the platform
A Vercel project reaches its database through an integration or a separate vendor relationship. Kuberns provisions PostgreSQL, MySQL, and MongoDB as managed datastores with their own credentials, metrics, and backups, plus Redis, Kafka, and NATS as resources, in the same dashboard as the application.
Backups are dumps you download and load yourself with the standard client. Kuberns does not restore one into a running datastore for you.
A first deploy with nothing to write
The AI agent runs against the repository before the first deploy and reports the framework, root directory, dependency file, runtime, base image, web port, build commands, Procfile commands, detected variable names, and the resource categories the application appears to need. You review and correct that on one screen, then it provisions.
For a Vercel migration this is worth more than usual, because the start command is the field most likely to need correcting and this is where you correct it.
Recovery when a container fails
A serverless platform handles failure by discarding the invocation. A container platform has to keep something alive, so Kuberns tries to.
Three recovery layers run in the backend: orchestrator restart, an intelligent healing layer that classifies the failure and selects a recovery action, and a real-time listener fed by health-agent events. Classifications include out-of-memory, memory pressure, database unreachable, port conflict, disk full, CPU throttling, missing variables, and startup loop. Every attempt is recorded as a healing event.
Defaults cap this at five restart attempts an hour, triggered by three failed probes. It is best-effort recovery, not a guarantee. Kuberns Fixes separately splits build and runtime diagnostics into platform-side items you can apply from the dashboard and user-side items reported as yours to fix.
Predictable billing for steady traffic
The models are opposites, and which is cheaper depends entirely on your traffic shape.
Vercel bills per invocation and per unit of compute consumed, which is efficient for bursty traffic and unpredictable under a spike. Kuberns bills runtime credits — one credit is one dollar, charged while resources run — which is predictable at steady load and wasteful for something that serves ten requests a day.
Bundles have no Vercel equivalent: a one-, three-, or twelve-month bundle is your current burn rate multiplied by that duration, with a better rate on longer bundles. Data transfer is metered per environment, with 5 GB a month included. See Data transfer and storage.
The trial runs seven days with ten credits and no card.
Where Vercel still fits better
Anything static
A container serving static files is a worse edge network than an edge network. If a large part of your project is pages that could be files, that part should stay on Vercel, and the split described above is the answer rather than a compromise.
Framework-integrated features
Image optimization, framework-aware caching, and analytics are platform products, not portable code. On Kuberns they need a library, an external service, or pre-built assets. Count how many you use before you plan the move.
Edge middleware and edge runtime
Code that runs before the request reaches an origin has no container equivalent. Middleware written against the Node runtime usually survives as ordinary server code; anything using edge-specific APIs does not.
Preview deployments per pull request
Kuberns environments are branch-based. You get preview environments, but one per branch rather than one per open pull request, and nothing is created and destroyed automatically as PRs open and close.
Bursty and low-traffic workloads
If your application serves traffic in short spikes with long quiet periods, paying per invocation is genuinely cheaper than paying for a process that idles between them. That is not a limitation of Kuberns so much as a description of what runtime billing means.
Get started
Start by deciding which of the three outcomes applies to you: move everything, split frontend and backend, or stay. The Vercel migration guide opens with that assessment rather than a checklist, because for this pair it is the decision that matters.
If you already know your backend is the part that hurts, the split is the answer, and the migration is smaller than you think.