--- title: Does Vercel support Docker deployments? description: Vercel supports deploying OCI-compatible container images through Vercel Functions and Vercel Container Registry, with Active CPU pricing and automatic scaling. url: "https://vercel.com/kb/guide/does-vercel-support-docker-deployments" published: 2025-11-03 last_updated: 2026-10-29 authors: Ben Sabic install_vercel_plugin: npx plugins add vercel/vercel-plugin --- Yes. Vercel runs Open Container Initiative (OCI) container images as [Vercel Functions](https://vercel.com/docs/functions). It builds the image from your Dockerfile, stores it in [Vercel Container Registry](https://vercel.com/docs/container-registry), and runs your HTTP server with automatic scaling. The Container runtime is in beta on all plans. Your application must serve HTTP requests and fit the runtime's resource and networking limits. ## When to use a container image Use containers to control your runtime and system dependencies: - Custom servers written in Go, Rust, Python, or Ruby - System libraries such as FFmpeg or Chromium - Frameworks outside Vercel's auto-detection list - The same packaged runtime and dependencies across environments Container-based functions can reuse a running instance, but local memory and files are not durable storage. Store data that must outlive an instance or be shared across instances in an external database, object store, or cache. For workers that continuously poll for jobs independently of HTTP traffic, use [Vercel Daemons](https://vercel.com/docs/daemons). ## How container image deployments work For a new project with no other detected framework, Vercel selects the Container preset from a root `Dockerfile` or `Containerfile`. It builds the image, pushes it to Vercel Container Registry, and routes incoming requests to the resulting function. If Vercel detects a framework such as Next.js or Django, it keeps that framework. To use the root Dockerfile instead, run `vercel project update --framework container` or set `"framework": "container"` in `vercel.json`. You can also name the file `Dockerfile.vercel` or `Containerfile.vercel` to make container detection take precedence. ### Run a dynamic server Create `Dockerfile` and `server.ts` together in your project root. This Node.js server uses `srvx` to return the request's forwarded IP header as JSON: ```dockerfile FROM node:26-alpine RUN npm i -g srvx WORKDIR /app COPY server.ts . # srvx listens on $PORT by default CMD ["srvx", "--prod"] ``` ```typescript export default { fetch(req: Request) { return Response.json({ ip: req.headers.get("x-forwarded-for") }) } } ``` ### Serve static files For a static site, use this Dockerfile instead of the Node.js version. Place only public files in `public/` to keep other project files out of Nginx's document root: ```dockerfile FROM nginx:alpine COPY public/ /usr/share/nginx/html/ ``` Create `public/index.html` with content you can recognize after deployment: ```html

Hello from Vercel

``` Deploy from your project root with `vercel deploy`, or push the files to a connected Git repository. Open the deployment URL and confirm that the Node.js server returns JSON with an `ip` field or that Nginx displays your HTML page. ## How to run multiple services in one project To deploy multiple applications in one project, define each as a service and use `rewrites` to route incoming requests. Each `entrypoint` is relative to that service's `root`. Save this configuration as `vercel.json` in the project root, with a Dockerfile at each of these paths: `frontend/Dockerfile` and `backend/Dockerfile`. ```json { "services": { "frontend": { "root": "frontend/", "entrypoint": "Dockerfile" }, "backend": { "root": "backend/", "entrypoint": "Dockerfile" } }, "rewrites": [ { "source": "/api/(.*)", "destination": { "service": "backend" } }, { "source": "/(.*)", "destination": { "service": "frontend" } } ] } ``` The first rewrite sends `/api/users` to the backend with the path still set to `/api/users`, so the backend must handle that route. The final rewrite sends other requests to the frontend. Rewrites are checked in order; a backend 404 does not fall through to the frontend. For private calls between services, declare a [service binding](https://vercel.com/docs/services/bindings) on the caller. Vercel then injects the target URL into the environment variable named by that binding. Public rewrites do not create this internal access. Run the services together with `vercel dev`. The [Vercel Services guide](https://vercel.com/kb/guide/vercel-services) explains how to configure bindings and develop the project locally. ## How container image functions handle ports, scaling, and logs - **Port resolution**: Vercel routes HTTP traffic to port `80` by default. To use another port, set `PORT` in your [project environment variables](https://vercel.com/docs/environment-variables) and configure the server to listen on that port. - **Scale-in**: Idle functions scale down after five minutes in production or 30 seconds in preview. The container receives `SIGTERM` and has 30 seconds to clean up before termination. - **Observability**: Container `stdout` and `stderr` logs are associated with all in-flight requests on the instance. Vercel Observability metrics are also available. - **Pricing and limits**: Container functions use [Fluid compute pricing](https://vercel.com/docs/functions/usage-and-pricing) for active CPU time, provisioned memory, and invocations. CPU billing pauses during I/O waits. The Container runtime is in beta on all plans. ## How to develop and test container images locally Run `vercel dev` to develop and test container images locally. This requires the `docker` CLI and a running Docker daemon on your machine. The [Next.js Dockerfile example](https://github.com/vercel/next.js/tree/canary/examples/with-docker) shows how to build a standalone production image and run it locally with Docker. ### Check a framework build without a custom container For a framework app deployed without a custom container image, you can check the Vercel build locally before creating a preview deployment: 1. Run `vercel pull` to refresh project settings and environment variables. 2. Run `vercel build` and inspect the generated `.vercel/output` artifacts. 3. To deploy that output, run `vercel deploy --prebuilt` after the build succeeds. The last command creates a deployment from the build artifacts without uploading the project's source code. ## Current limitations for container images Two Vercel networking features don't work with custom container images yet: - [Secure Compute](https://vercel.com/docs/networking/secure-compute): dedicated network isolation for private backend connections. - [Static IPs](https://vercel.com/docs/networking/static-ips): fixed outbound IP addresses for allowlisting with external services. Container image functions are subject to the applicable [Vercel Function limits](https://vercel.com/docs/functions/limitations). If your app needs Secure Compute or Static IPs, check whether its runtime and system dependencies can run on Vercel without a custom container image before switching deployment paths. ## Further reading - See the [Container runtime documentation](https://vercel.com/docs/functions/runtimes/container) for configuration and limits. - Learn how to store, push, and pull images in [Vercel Container Registry](https://vercel.com/docs/container-registry). - Review [Fluid compute pricing](https://vercel.com/docs/functions/usage-and-pricing) for compute usage and invocation charges. - Explore the [Next.js Dockerfile example](https://github.com/vercel/next.js/tree/canary/examples/with-docker) to build a standalone production image. - Learn more about [Vercel Services](https://vercel.com/kb/guide/vercel-services) to run frontends and backends in one project. ## Related Documentation - [Vercel Services](https://vercel.com/docs/services) - [Vercel Container Registry](https://vercel.com/docs/container-registry) - [Vercel CLI](https://vercel.com/docs/cli) ## More Vercel Services guides - [Migrate from Railway to Vercel](/kb/guide/migrate-railway-to-vercel): Migrate an app from Railway to Vercel. Choose a deployment path, configure services, plan for stored data, and test before switching production traffic. - [Migrate from Google Cloud Run to Vercel](/kb/guide/migrate-cloud-run-to-vercel): Move a Cloud Run service or worker to Vercel. Compare runtimes, preserve Google Cloud access, and plan jobs, validation, and production cutover. - [Migrate from Render to Vercel](/kb/guide/migrate-render-to-vercel): Migrate from Render to Vercel: map web services, cron jobs, and containers to their equivalents, and handle what doesn't move.