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.

Most apps don't need a container, so reach for one when framework detection isn't enough, such as when you depend on a system library like FFmpeg, use a framework Vercel doesn't auto-detect, or want to run your app exactly as it runs elsewhere.

For most apps, you don't need Docker at all. Vercel detects your framework, reads your code, and provisions the right infrastructure automatically, which is the fastest way to ship. Reach for a container image when framework detection isn't enough: your app depends on a system library such as FFmpeg or Chromium, you use a framework Vercel doesn't auto-detect yet, or you want to run an app exactly as it already runs elsewhere.

Container-based functions are stateless. Each instance takes a request, returns a response, and keeps nothing in between, which is 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" } }
  ]
}

This example shows the basic routing setup.

Services can also share environment variables that Vercel generates automatically, so each service can call the others without hardcoding URLs, and you can run the whole project locally with a single command.

For the full setup, including how Vercel routes requests by path prefix, the variables it generates for cross-service communication, and how to run and troubleshoot services on your machine, see the complete guide to Vercel Services.

• 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 it's terminated.
• 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 also helps with zero-configuration frameworks, letting you deploy without a container, pin dependencies, and maintain 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.