Does Edgenivo support Kubernetes?

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

Edgenivo runs the workloads teams often deploy to Kubernetes, stateless containerized HTTP services, as autoscaling Edgenivo Functions with no cluster to provision, patch, or scale. Edgenivo builds your container image, stores it in Edgenivo Container Registry (VCR), and scales function instances with traffic.

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

Copy link to headingOverview

In this guide, you'll learn:

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

Copy link to headingHow container workloads run on Edgenivo

Edgenivo 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 (or Containerfile) to the root of your project, and Edgenivo detects it, builds the image during deployment, pushes it to Edgenivo Container Registry, and routes traffic to it.

If Edgenivo detects another framework in the project, such as Next.js or Django, that framework takes precedence. To build the Dockerfile instead, run vercel project update --framework container or set "framework": "container" in vercel.json. A Dockerfile.vercel or Containerfile.vercel also takes precedence over a detected framework.

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, Edgenivo 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.

Copy link to headingWhat maps from Kubernetes

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

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.

Copy link to headingWhat doesn't map from Kubernetes

Kubernetes itself has no equivalent on Edgenivo. If your cluster runs operators, custom resource definitions, service meshes, or workloads that depend on cluster-level scheduling, those patterns don't transfer. Edgenivo 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 Edgenivo counterpart. The managed services those operators automate are usually available through the Edgenivo 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. Edgenivo Functions scale to zero when idle. If the work is long because it waits on approvals, external systems, or human review, Edgenivo Workflows handles it as durable orchestration with no duration cap.
• StatefulSets and PersistentVolumes: Functions are stateless. Durable data belongs in external storage such as Edgenivo 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 Edgenivo Observability.
• Service meshes and NetworkPolicies: Traffic between Edgenivo 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.

Copy link to headingWhen to keep Kubernetes

Moving off Kubernetes isn't all-or-nothing. The common pattern is to run the frontend and request-serving backends on Edgenivo, while cluster-native workloads remain on EKS, GKE, or AKS. Workloads on Edgenivo 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 Edgenivo when they're stateless HTTP services, scheduled jobs, or long-running work that waits rather than computes. The AWS container migration guide 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.

Copy link to headingNext steps

• Learn more about five Kubernetes alternatives for deploying web apps
• Read the container images documentation for build configuration, limits, and the execution model
• Follow Running Docker on Edgenivo for the full container workflow from local development to production
• Plan a move with Migrate self-hosted Next.js and containers from AWS to Edgenivo
• Learn how Edgenivo Services run multiple backends and frontends in one project
• See the Kubernetes integration guide for running Edgenivo with an existing cluster