---
title: Does Vercel support Kubernetes?
description: Vercel doesn't run Kubernetes clusters. Learn how Kubernetes workloads like Deployments, Ingress, ConfigMaps, and CronJobs map to Vercel Functions, container images, and Cron Jobs.
url: /kb/guide/vercel-kubernetes-support
canonical_url: "https://vercel.com/kb/guide/vercel-kubernetes-support"
published: 2026-08-10
last_updated: 2026-08-10
authors: Ben Sabic
related:
  - /docs/container-registry
  - /docs/services
  - /docs/environment-variables
  - /docs/cron-jobs
  - /docs/oidc
  - /docs/workflows
  - /docs/vercel-blob
  - /docs/observability
  - /kb/guide/migrate-containers-from-aws-to-vercel
  - /docs/functions/container-images
  - /kb/guide/docker
  - /docs/integrations/external-platforms/kubernetes
install_vercel_plugin: npx plugins add vercel/vercel-plugin
---

Vercel doesn't run or host Kubernetes clusters, and you don't need Kubernetes to run containers on Vercel.

Vercel runs the workloads teams often deploy to Kubernetes, stateless containerized HTTP services, as autoscaling Vercel Functions with no cluster to provision, patch, or scale. Vercel builds your container image, stores it in [Vercel Container Registry](https://vercel.com/docs/container-registry) (VCR), and scales function instances with traffic.

If you're evaluating whether your Kubernetes workloads can move to Vercel, this guide explains what maps directly, what has no equivalent, and when keeping a cluster is the right call.

## Overview

In this guide, you'll learn:

- How containerized workloads run on Vercel without a cluster
  
- Which Kubernetes concepts have direct Vercel equivalents
  
- Which Kubernetes features have no equivalent on Vercel
  
- When to keep Kubernetes and run it alongside Vercel
  

## How container workloads run on Vercel

Vercel Functions can run any Open Container Initiative (OCI) compatible container image, so an app packaged as a Docker image deploys like the rest of your project. Add a `Dockerfile.vercel` (or `Containerfile.vercel`) to the root of your project, and Vercel detects it, builds the image during deployment, pushes it to Vercel Container Registry, and routes traffic to it.

There is no scheduler to configure and no node pool to size. Function instances scale up with traffic and scale back down when idle. In production, an instance that receives no traffic for 5 minutes scales down, and the container receives a `SIGTERM` signal with a 30s grace period to clean up. In preview environments, scale-down occurs after 30 seconds of inactivity. Containers serve HTTP on port 80 by default, which you can override with the `PORT` environment variable.

Billing follows the Active CPU model rather than instance-hours. You pay for CPU while your code is running, not while an instance sits idle waiting for I/O or traffic, which is the opposite of paying for provisioned cluster capacity.

For projects with more than one workload, [Vercel Services](https://vercel.com/docs/services) let you deploy multiple frontends and backends in a single project. Each service builds independently, can use a different runtime or framework, and receives traffic through rewrite rules, filling the role that Kubernetes Services and Ingress play inside a cluster.

> **Note**: Container image support on Vercel Functions is in Beta on all plans.

## What maps from Kubernetes

Most day-to-day Kubernetes objects for a stateless HTTP service have a direct Vercel equivalent:

| Kubernetes concept                              | Vercel equivalent                                                                              |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| Deployment (Pod spec, image)                    | Container image built from `Dockerfile.vercel`, run as a Vercel Function                       |
| Horizontal Pod Autoscaler                       | Automatic scaling built into Vercel Functions, no configuration required                       |
| Service and Ingress                             | [Vercel Services](https://vercel.com/docs/services) and `rewrites` in `vercel.json`            |
| ConfigMap and Secret                            | [Environment variables](https://vercel.com/docs/environment-variables), scoped per environment |
| CronJob                                         | [Cron Jobs](https://vercel.com/docs/cron-jobs) defined in the `crons` array in `vercel.json`   |
| Container registry (ECR, GCR, ACR)              | [Vercel Container Registry](https://vercel.com/docs/container-registry)                        |
| Resource requests and limits                    | Function memory and duration settings                                                          |
| Rolling deployments and rollbacks               | Preview deployments per commit and instant rollback                                            |
| Workload identity (IRSA, GKE Workload Identity) | [Vercel OIDC federation](https://vercel.com/docs/oidc) for short-lived cloud credentials       |

Environment variables replace both ConfigMaps and Secrets, with values scoped to production, preview, or development. Each environment supports up to 1,000 variables, and all variables in a deployment share a 64 KB total size limit for names and values. Cron Jobs use standard cron expressions in `vercel.json`, though alternative expressions like `MON` or `JAN` aren't supported, and you can't set both day of the month and day of the week in one expression.

## What doesn't map from Kubernetes

Kubernetes itself has no equivalent on Vercel. If your cluster runs operators, custom resource definitions, service meshes, or workloads that depend on cluster-level scheduling, those patterns don't transfer. Vercel replaces the need for orchestration in the stateless HTTP case rather than reimplementing the orchestrator.

Specific gaps to plan around:

- **Operators and CRDs**: Anything that extends the Kubernetes API, such as database operators or certificate controllers, has no Vercel counterpart. The managed services those operators automate are usually available through the [Vercel Marketplace](https://vercel.com/marketplace) instead.
  
- **Always-on stateful processes**: A process that must keep running and hold state in memory with no request in flight, like a queue consumer that polls continuously or a daemon holding a long-lived connection, doesn't fit the function model. Vercel Functions scale to zero when idle. If the work is long because it waits on approvals, external systems, or human review, [Vercel Workflows](https://vercel.com/docs/workflows) handles it as durable orchestration with no duration cap.
  
- **StatefulSets and PersistentVolumes**: Functions are stateless. Durable data belongs in external storage such as [Vercel Blob](https://vercel.com/docs/vercel-blob) or a Marketplace database.
  
- **DaemonSets and node-level agents**: There are no nodes to run agents on. Observability is built into the platform through [Vercel Observability](https://vercel.com/docs/observability).
  
- **Service meshes and NetworkPolicies**: Traffic between Vercel Services is routed by the platform. Fine-grained east-west network policy has no direct equivalent.
  
- **Secure Compute and static IPs with container images**: These two networking features don't yet work with custom container images. If your workload requires private connectivity to a VPC, check current support first.
  

## When to keep Kubernetes

Moving off Kubernetes isn't all-or-nothing. The common pattern is to run the frontend and request-serving backends on Vercel, while cluster-native workloads remain on EKS, GKE, or AKS. Workloads on Vercel can access your AWS services by assuming an IAM role via OIDC federation, without long-lived credentials.

Keep workloads on Kubernetes when they depend on operators, custom controllers, cluster-level scheduling, or always-on stateful processes. Move workloads to Vercel when they're stateless HTTP services, scheduled jobs, or long-running work that waits rather than computes. The [AWS container migration guide](https://vercel.com/kb/guide/migrate-containers-from-aws-to-vercel) walks through this split in practice: If your cluster workload is a container being served over HTTP, it moves; the cluster machinery around it is a separate decision.

## Next steps

- Read the [container images documentation](https://vercel.com/docs/functions/container-images) for build configuration, limits, and the execution model
  
- Follow [Running Docker on Vercel](https://vercel.com/kb/guide/docker) for the full container workflow from local development to production
  
- Plan a move with [Migrate self-hosted Next.js and containers from AWS to Vercel](https://vercel.com/kb/guide/migrate-containers-from-aws-to-vercel)
  
- Learn how [Vercel Services](https://vercel.com/docs/services) run multiple backends and frontends in one project
  
- See the [Kubernetes integration guide](https://vercel.com/docs/integrations/external-platforms/kubernetes) for running Vercel with an existing cluster