Does Vercel support Docker deployments?

Yes, Vercel supports Docker deployments by running OCI-compatible container images as Vercel Functions, so an app packaged as a Docker image deploys alongside the rest of your project. Vercel builds the image, stores it in Vercel Container Registry (VCR), and serves it from a function that scales automatically.

Container images are how teams bring backend workloads to Vercel. That includes services written in Go, Rust, Python, or Ruby, custom servers, sidecar processes, and apps that depend on system libraries like FFmpeg. If you can package it as an OCI image, you can deploy it on Vercel.

Container images are a first-class deployment target on Vercel, and they work well for a range of backend and full-stack workloads:

• Backend services written in any language or runtime, including Go, Python, and more.
• Apps that depend on system libraries such as FFmpeg or Chromium.
• Frameworks outside Vercel's auto-detection list.
• Workloads you want to run identically in production and in other environments.

Container-based functions are stateless. Each instance takes a request, returns a response, and keeps nothing between calls. That's what lets Vercel add instances when traffic arrives and scale to zero when it stops. Store any state that needs to persist in a backing service, such as a database or cache from the Vercel Marketplace.

Vercel detects a Dockerfile.vercel (or Containerfile.vercel) at the root of your project and adds a rewrite that routes all traffic to the resulting image. During the build step, Vercel builds the image, pushes it to VCR, and serves it from a Vercel Function.

Here's a minimal dynamic server 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"]
export default {
  fetch(req: Request) {
    return Response.json({ ip: req.headers.get("x-forwarded-for") })
  }
}

Static servers work the same way. This Dockerfile serves files with Nginx:

FROM nginx:alpine

COPY . /usr/share/nginx/html

Deploy by running vercel deploy or by pushing to a connected Git repository.

To deploy more than one application in a single project, define each one as a service and route traffic between them with rewrites in vercel.json. Set each service's entrypoint to its Dockerfile path, relative to the service's root:

{
  "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. Run the entire project locally with a single command.

For the full setup, see the Vercel Services complete guide. It covers path-prefix routing, cross-service environment variables, and local development.

• Port resolution: Your container must serve HTTP. Vercel routes traffic to port 80 by default, which you can override with the PORT environment variable.
• Scale-in: Functions that receive no traffic for five minutes in production (30 seconds in preview) scale down automatically. On scale-down, the container receives SIGTERM with a 30-second grace period to clean up before Vercel terminates it.
• Observability: Vercel broadcasts stdout and stderr logs to all inflight requests on the instance, and Vercel Observability metrics work the same as for any function.
• Pricing and limits: Container image functions follow the same Active CPU pricing and limits as other Vercel Functions.

Run vercel dev to develop and test container images locally. This requires the docker CLI and a running Docker daemon on your machine.

Docker is also useful with zero-configuration frameworks for pinning dependencies and keeping a consistent build environment across machines. The Next.js repository includes a Dockerfile example for this workflow. To verify a Vercel build locally without pushing code:

• Run vercel build
• Run vercel deploy --prebuilt to upload the generated output from .vercel/output without sending source code

Two Vercel networking features don't work with custom container images yet:

• Secure Compute: dedicated network isolation for connecting to backends over a private connection.
• Static IPs: fixed outbound IP addresses for allowlisting with external services.

Aside from these, container image functions behave like any other Vercel Function. They inherit the standard function limits for size, memory, and duration, and follow the same Active CPU pricing model. If your app depends on Secure Compute or Static IPs, deploy that part without a container image for now.

• Read the Container Images documentation for full configuration details, including Services and rewrites.
• 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 the Next.js Dockerfile example for local development.
• Learn more about Vercel Services to run frontends and backends in one project.