Running Docker on Vercel vs Render

Docker containers run natively on both Vercel and Render, but the two platforms execute them in fundamentally different ways. Vercel runs container images as Vercel Functions on Fluid compute, autoscaling instances with traffic and billing only for Active CPU time. Render runs containers on always-on instances that you size yourself, with support for non-HTTP workloads like background workers and cron jobs. This guide compares how Docker deployments work on each platform so you can decide which model fits your workload.

In this guide, you'll learn how each platform builds, stores, and runs container images, how their compute, scaling, state, and pricing models differ, and when to choose Vercel or Render for a containerized workload.

Vercel Functions run Open Container Initiative (OCI) compatible images as a first-class deployment target. Add a Dockerfile.vercel (or Containerfile.vercel) file to the root of your project, and on every deploy Vercel:

1. Detects the file automatically
2. Builds the image during the build step
3. Stores the image in Vercel Container Registry
4. Adds a rewrite that routes all traffic to the resulting function

Here is a minimal example using Node.js and the srvx server:

FROM node:26-alpine

RUN npm i -g srvx
WORKDIR /app
COPY server.ts .

# srvx listens on $PORT by default
CMD ["srvx", "--prod"]

Deploy by running vercel deploy or by pushing to a connected Git repository. Every commit gets an immutable preview deployment with its own URL, and the resulting container runs on the same platform, and the same compute, as your frontend and any other Vercel services.

Container image functions must open an HTTP server. Vercel routes traffic to port 80 by default, and you can override this by setting the PORT environment variable in your project settings.

Vercel Container Registry (VCR) is a project-scoped registry for OCI images that supports the Docker Registry HTTP API v2, so standard Docker tooling works against vcr.vercel.com. You can let Vercel's build step push images automatically, or push a prebuilt image yourself:

docker buildx build --push \
  -t vcr.vercel.com/team-slug/project-slug/my-repository:latest

Vercel recommends zstd compression for images pushed to VCR; see the registry documentation for the full buildx invocation with compression flags.

When you push an image, VCR optimizes it in the background into a precompiled snapshot format designed to boot on Fluid compute, which reduces startup time when new instances spin up.

Container image functions scale out when traffic arrives and wind down when it stops. You never size a fleet or set a concurrency target. The scale-down behavior is:

• Instances with no traffic for 5 minutes in production scale down automatically
• In preview environments, the threshold is 30 seconds
• On scale-down, the container receives a SIGTERM signal with a 30-second grace period to clean up before termination

Because instances come and go with traffic, containers on Vercel are stateless. Each instance takes a request, returns a response, and keeps nothing between calls. Persistent state belongs in a backing service, such as a database from the Vercel Marketplace.

Services let you deploy several applications, frontends or backends, within a single project. Traffic routes between them with rewrites in vercel.json:

{
  "services": {
    "frontend": {
      "root": "frontend/",
      "entrypoint": "Dockerfile.vercel"
    },
    "backend": {
      "root": "backend/",
      "entrypoint": "Dockerfile.vercel"
    }
  },
  "rewrites": [
    { "source": "/api/(.*)", "destination": { "service": "backend" } },
    { "source": "/(.*)", "destination": { "service": "frontend" } }
  ]
}

Vercel also automatically generates environment variables for each service, so services can call each other without hardcoded URLs.

For local development, run vercel dev with the docker CLI and a running Docker daemon on your machine.

Container image functions inherit the standard Vercel Functions limits for size, memory, and duration.

Two networking features are not yet supported with custom container images.

Secure Compute provides dedicated network isolation, and Static IPs provide fixed outbound addresses for allowlisting with external services. If part of your app depends on those features, deploy that part without a container image for now.

Render supports two paths for Docker-based services. You can have Render build an image from the Dockerfile in your Git repository, or you can deploy a prebuilt image pulled from a container registry.

To build from a repository, set the service's language to Docker during creation, point Render at your Dockerfile path if it isn't in the repository root, and deploy. On every deploy, Render:

• Builds the image with BuildKit
• Caches intermediate layers to speed up subsequent builds
• Supports parallelized multi-stage builds
• Respects your .dockerignore file

Builds can run for up to 120 minutes, which accommodates complex pipelines.

To deploy a prebuilt image, provide the image URL when creating the service. Render pulls public images from any registry it can reach, and pulls private images with a stored credential from:

• Docker Hub
• GitHub Container Registry
• GitLab Container Registry
• Google Artifact Registry
• AWS Elastic Container Registry (ECR)

Render caches public images, so reference an immutable tag or digest to avoid deploying a stale cached version.

Image-backed services don't auto-deploy when you push a new image to your registry. Trigger deploys manually from the dashboard, or call a deploy hook from your CI pipeline, optionally passing a specific tag or digest.

Docker images on Render can back four service types:

• Web services: Public HTTP traffic with a Render-provided or custom domain
• Private services: Reachable only over the private network, with no public endpoint
• Background workers: Long-running processes like queue consumers, with no inbound HTTP
• Cron jobs: Containers that run on a schedule and exit

This makes Render a fit for containerized workloads that never receive an HTTP request, such as a worker draining a job queue.

Environment variables you set for a Docker-based service are translated into Docker build arguments during the image build and exposed as standard environment variables at runtime. Render warns against referencing sensitive build arguments in a Dockerfile, since those values can be baked into the image, and recommends using secret files for build-time secrets instead.

Render services run on always-on instances. You choose an instance type and count, and you pay for the full time each instance runs, whether it is serving traffic or idle. On Pro plans and higher, autoscaling can add and remove instances against CPU or memory utilization targets, up to 100 instances. There is no scale-to-zero for paid instances, which means no cold starts, though your minimum instance count is always running and billed.

Render supports persistent disks attached directly to a service, so stateful workloads like a self-hosted database or a CMS with local file storage can run without an external backing service. The tradeoff is twofold. Services with an attached disk can't scale horizontally, and attaching a disk disables zero-downtime deploys: Render stops the existing instance before bringing up the new one, causing a few seconds of unavailability during each deploy.

Docker-based services on Render get the same platform capabilities as native runtime services, including:

• Zero-downtime deploys
• A pre-deploy command for tasks like database migrations
• Private networking on all plans
• Custom domains
• Infrastructure as code through Render Blueprints

The largest difference is what you pay for.

Vercel bills Active CPU, which is the time your code actually executes. A container waiting on a slow database query or an upstream API is not burning billable CPU, and a container with no traffic scales to zero and costs nothing to run.

Render bills per instance for wall-clock time. With manual scaling, costs are flat and predictable, but they accrue whether or not the service is performing work. With autoscaling (Pro plans and higher), Render adds and removes instances against CPU or memory targets, so costs track load down to your configured minimum instance count, but never to zero for paid instance types.

Workloads with uneven or bursty traffic tend to cost less under Active CPU pricing. Workloads with steady, sustained load may find per-instance pricing more predictable.

Vercel containers serve HTTP. Request-response backends, APIs, and full-stack apps in any language fit this model, and they gain Vercel's CDN, preview deployments, and observability in front of them.

Render additionally runs containers as background workers and cron jobs, and serves long-lived WebSocket connections from always-on web services with no per-connection duration ceiling.

Vercel Functions, including container image functions, can also serve WebSocket connections natively on Fluid compute (currently in public beta). A connection is pinned to a single function instance and is subject to the function's maximum duration limit, so clients should handle reconnects. Persistent state, rooms, and pub/sub coordination belong in an external store such as Redis.

Vercel containers are stateless by design, with persistence delegated to databases and caches from the Marketplace. Render offers attached persistent disks at the cost of horizontal scaling and zero-downtime deploys for that service. If your container writes to its local filesystem and you can't change that, Render's disk model is the more direct fit. If your state already lives in a database, either platform works.

Choose Vercel when your containerized workload is an HTTP server and you want autoscaling, scale to zero, and Active CPU pricing without managing instances. Vercel fits teams that:

• Run a frontend on Vercel and want a containerized backend, in Go, Rails, Django, Spring Boot, or any other stack, in the same project with shared previews, domains, and observability
• Have bursty or unpredictable traffic where paying only for execution time reduces costs
• Want a preview deployment for every commit, for containers and frontends alike
• Need Vercel's CDN, WAF, and bot protection in front of the container

Choose Render when your workload doesn't fit the request-response model or needs an always-on instance. Render fits teams that:

• Run containerized background workers, cron jobs longer than function limits allow, or private services with no public endpoint
• Need persistent disks attached directly to the container
• Serve WebSocket connections with no function duration limit or forced reconnects
• Pull prebuilt images directly from Docker Hub, GitHub, GitLab, Google Artifact Registry, or AWS ECR without an intermediate registry
• Prefer flat, predictable per-instance billing over usage-based pricing

Many teams combine the two, running a frontend and containerized API on Vercel while keeping workers or disk-backed services on Render, connected through shared databases or queues.

• Read the Container Images documentation for full configuration details on Vercel
• Learn how to store, push, and pull images in Vercel Container Registry
• Review Vercel Functions usage and pricing to understand the Active CPU model
• Explore Vercel Services to run frontends and containerized backends in one project
• Compare the platforms more broadly in Vercel vs Render
• See Docker on Render for Render's build and registry options