--- title: Vercel vs Kubernetes description: Compare Vercel and Kubernetes on operational ownership, deployment workflow, scaling, and cost model to decide which platform fits your workload and team. url: /kb/guide/vercel-vs-kubernetes canonical_url: "https://vercel.com/kb/guide/vercel-vs-kubernetes" published: 2026-08-19 last_updated: 2026-08-19 authors: Ben Sabic related: - /kb/guide/vercel-kubernetes-support - /docs/observability - /docs/container-registry - /kb/guide/kubernetes-manifests-to-vercel-json - /docs/fluid-compute - /docs/functions/usage-and-pricing - /kb/guide/fluid-compute-vs-cloud-cost - /docs/cron-jobs - /docs/services - /docs/oidc - /docs/secure-compute - /docs/integrations/external-platforms/kubernetes - /docs/functions/container-images install_vercel_plugin: npx plugins add vercel/vercel-plugin --- ## Related pages > **For AI agents:** Follow these links to understand how this page connects to the rest of the Vercel ecosystem. For the full cross-link map (inbound, outbound, prerequisites, and semantic neighbors), see the .graph.md link below. - [Running Docker on Vercel vs Render](https://vercel.com/kb/guide/docker-on-vercel-vs-render?from=related) — Compare how Vercel and Render run Docker workloads, including deployment model, scaling, image sources, state, and netwo - [How to migrate from Google Cloud Run to Vercel](https://vercel.com/kb/guide/migrate-cloud-run-to-vercel?from=related) — Migrate from Cloud Run to Vercel by copying your Dockerfile to Dockerfile.vercel, aligning the PORT contract, moving sec - [TanStack Start on Vercel vs Cloudflare](https://vercel.com/kb/guide/tanstack-start-on-vercel-vs-cloudflare?from=related) — Compare running TanStack Start on Vercel Functions with Fluid compute against Cloudflare Workers. Learn how the runtimes - [How to migrate from Fly.io to Vercel](https://vercel.com/kb/guide/migrate-fly-io-to-vercel?from=related) — Move a containerized app from Fly.io to Vercel. Map fly.toml to Dockerfile.vercel and vercel.json, replace Machines with - [TanStack Start on Vercel vs Netlify](https://vercel.com/kb/guide/tanstack-start-on-vercel-vs-netlify?from=related) — Compare running TanStack Start on Vercel Functions with Fluid compute against Netlify Functions. Learn how the compute m Full cross-link map for this page: [/kb/guide/vercel-vs-kubernetes.graph.md](/kb/guide/vercel-vs-kubernetes.graph.md) Vercel and Kubernetes can both run containerized web workloads, but they sit at different layers of the stack. Kubernetes is an orchestrator your team installs, configures, and operates on infrastructure you provision. Vercel is a managed platform that builds, deploys, and scales your workloads without a cluster to run. The real comparison is about operational ownership: who patches, scales, secures, and pays for the infrastructure underneath your code. ## Overview In this guide, you'll learn: - How Vercel and Kubernetes divide responsibilities - How the deployment workflow, scaling model, and cost model differ - When each platform is the better fit for a workload - How teams run both platforms together ## Two different layers of the stack Kubernetes gives you infrastructure primitives, while Vercel gives you a finished platform. On Kubernetes, you compose Deployments, Services, Ingress controllers, and autoscalers into a delivery system, and your team owns that system in production. On Vercel, the delivery system already exists: you connect a Git repository, and the platform handles builds, routing, TLS, scaling, and rollbacks. This distinction matters more than any feature checklist. A Kubernetes cluster can run almost anything if you invest the engineering time, whereas Vercel targets a specific class of workloads, primarily stateless HTTP services, frontends, APIs, and scheduled jobs, and removes the operational work for them. Each of these Kubernetes concepts [maps to a specific Vercel feature](https://vercel.com/kb/guide/vercel-kubernetes-support). ## What your team manages on each platform The clearest way to compare the platforms is by responsibility. On Kubernetes, most of these rows are your team's job, even on a managed control plane like EKS, GKE, or AKS. | Responsibility | Kubernetes | Vercel | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- | | Control plane and upgrades | You schedule cluster upgrades. Kubernetes ships three minor releases per year, and each receives patches for roughly 14 months | None. Vercel operates the compute platform | | Node capacity | You size node pools, tune bin-packing, and plan headroom for spikes | None. Instances scale with traffic | | OS and runtime patching | Your team patches node images and base layers | Handled by the platform | | Autoscaling | You configure the Horizontal Pod Autoscaler and cluster autoscaler, and tune their thresholds | Built-in, with no configuration | | Ingress, TLS, and routing | You run an ingress controller and certificate management | Automatic HTTPS, with routing defined in `vercel.json` | | CI/CD and rollouts | You build pipelines, push to a registry, and manage rollout strategy, often with tools like Argo CD or Flux | Every Git push builds and deploys, with a preview URL per commit and instant rollback | | Observability | You install and operate agents such as Prometheus, Grafana, or Datadog | Built-in logs, traces, and metrics through [Vercel Observability](https://vercel.com/docs/observability) | The pattern is consistent: Kubernetes trades operational ownership for flexibility, and Vercel trades some flexibility for a platform your team doesn't have to run. ## How deployment works on each platform On Kubernetes, a deployment is a pipeline your team assembles. CI builds an image, pushes it to a registry, applies updated manifests to the cluster, and a rolling update replaces pods while probes gate traffic. Each stage is configurable and something you maintain. On Vercel, a deployment is a Git push. For containerized workloads, you add a `Dockerfile.vercel` to your project, and Vercel builds the image, stores it in [Vercel Container Registry](https://vercel.com/docs/container-registry), and routes traffic to it. Every commit produces a preview deployment with its own URL, so review happens on running infrastructure rather than in a staging queue. Existing manifests don't need a rewrite from scratch. [Translate Kubernetes manifests to vercel.json](https://vercel.com/kb/guide/kubernetes-manifests-to-vercel-json) converts each one, from Deployments through CronJobs, into its Vercel configuration. ## How scaling differs Kubernetes scales in two coupled layers. The Horizontal Pod Autoscaler adds pods based on metrics you choose, and the cluster autoscaler adds nodes when pods can't be scheduled. Scaling to zero requires additional tooling such as KEDA or Knative, so idle services usually keep at least one pod, and therefore at least one node, running. Vercel Functions scale up with traffic and scale to zero without configuration. In production, an instance that receives no traffic for 5 minutes scales down, and containers receive a `SIGTERM` signal with a 30s grace period to clean up. [Fluid compute](https://vercel.com/docs/fluid-compute) also lets a single instance serve concurrent requests, which keeps utilization high for I/O-bound workloads like AI inference or API backends that spend most of their time waiting on external calls. ## How the cost models differ Kubernetes bills for capacity. You pay for nodes while they exist, whether the pods on them are busy or idle, so utilization is a cost problem your team actively manages. Managed control planes add their own per-cluster fees on top of node costs. Vercel bills for work. With [Active CPU pricing](https://vercel.com/docs/functions/usage-and-pricing), you pay CPU rates only while your code is executing, at $0.128 per hour of Active CPU, plus provisioned memory at $0.0106 per GB-hour while requests are in flight. If a function spends 400ms waiting on a database query and 100ms processing the result, you pay CPU rates for the 100ms. When no requests are running, neither CPU nor memory charges apply. For a detailed cost breakdown against EC2, Fargate, and EKS on a per-vCPU basis, see the [Fluid compute pricing comparison guide](https://vercel.com/kb/guide/fluid-compute-vs-cloud-cost). ## When Kubernetes is the better fit Keep workloads on Kubernetes when they depend on the cluster itself rather than on containers over HTTP: - **Operators and custom resources**: Workloads that extend the Kubernetes API, such as database operators or certificate controllers, have no platform equivalent - **Always-on stateful processes**: Daemons that hold long-lived connections or poll continuously don't fit a model that scales to zero - **Cluster-level networking**: Service meshes, NetworkPolicies, and fine-grained east-west traffic control only exist inside a cluster - **Custom hardware scheduling**: GPU node pools, specific instance families, and topology-aware placement require node-level control - **Private connectivity with containers**: Secure Compute and static IPs don't yet work with custom container images on Vercel, so workloads that require private VPC access from a container should stay on the cluster for now ## When Vercel is the better fit Move workloads to Vercel when the container is the product and the cluster is overhead: - **Stateless HTTP services and APIs**: These run as autoscaling Vercel Functions with no scheduler, node pool, or ingress to operate - **Frontends and full-stack apps**: Framework-aware builds, preview deployments, and a global CDN come with every project - **I/O-bound and AI workloads**: Fluid compute's concurrency and Active CPU pricing suit workloads that wait more than they compute - **Scheduled jobs**: [Cron Jobs](https://vercel.com/docs/cron-jobs) replace CronJob manifests with entries in `vercel.json` - **Multi-service projects**: [Vercel Services](https://vercel.com/docs/services) deploy several frontends and backends in one project, with each service building independently - **Teams without a platform group**: If nobody owns the cluster full time, upgrades and incident response compete with product work ## Running both together Choosing between Vercel and Kubernetes isn't all-or-nothing, and most teams that adopt Vercel keep a cluster. The common split runs the frontend and request-serving backends on Vercel while cluster-native workloads stay on EKS, GKE, or AKS. Vercel workloads can reach services in your AWS account by assuming an IAM role through [OIDC federation](https://vercel.com/docs/oidc), without storing long-lived credentials, and Enterprise teams can use [Secure Compute](https://vercel.com/docs/secure-compute) for private connectivity to backends behind a VPC. The [Kubernetes integration guide](https://vercel.com/docs/integrations/external-platforms/kubernetes) covers this hybrid setup in detail, including networking, environment variables, and keeping your existing observability stack. ## Next steps - Read [Does Vercel support Kubernetes?](https://vercel.com/kb/guide/vercel-kubernetes-support) for the full concept-by-concept mapping - Follow [Translate Kubernetes manifests to vercel.json](https://vercel.com/kb/guide/kubernetes-manifests-to-vercel-json) when you're ready to move a workload - Review the [container images documentation](https://vercel.com/docs/functions/container-images) for build configuration and limits - Learn how [Fluid compute](https://vercel.com/docs/fluid-compute) executes and bills Vercel Functions