--- title: Running Docker on Vercel vs Render description: Compare how Vercel and Render run Docker workloads, including deployment model, scaling, image sources, state, and networking. url: "https://vercel.com/kb/guide/docker-on-vercel-vs-render" published: 2026-07-13 last_updated: 2026-10-29 authors: Ben Sabic install_vercel_plugin: npx plugins add vercel/vercel-plugin --- Docker workloads run on both Vercel and Render. Vercel uses [container Functions](https://vercel.com/docs/functions/runtimes/container) for HTTP servers that scale with traffic and [Daemons](https://vercel.com/docs/daemons) for continuous workers with configured instance counts. Render offers web services, private services, background workers, and scheduled jobs, with attached disks for supported service types. The choice depends on how your process receives work, stores data, and needs to scale. Vercel Functions account for Active CPU, Provisioned Memory, and invocations. Daemons account for CPU and memory while they run, including memory used while waiting for work. Preview deployments and traffic-based autoscaling apply to Functions; Daemons are production-only during beta. ## How the platforms compare at a glance | Capability | Vercel | Render | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Deploy from a Dockerfile | Yes, from a `Dockerfile` or `Containerfile` at the project root or configured service or daemon root | Yes, set the service language to Docker and Render builds with BuildKit | | Image source | Deploy source with a `Dockerfile` or `Containerfile`; [Vercel Container Registry](https://vercel.com/docs/container-registry) stores OCI images | Pull public images from any reachable registry and private images from Docker Hub, GitHub, GitLab, Google Artifact Registry, or AWS ECR | | Compute model | Functions autoscale with traffic and scale to zero; Daemons maintain configured worker counts | Always-on instances; manual scaling on all plans, CPU/memory-based autoscaling on Pro and higher (no scale to zero for paid instances) | | Workload types | HTTP servers on Functions; continuous queue consumers and workflow workers on Daemons | Web services, private services, background workers, and cron jobs | | Pricing model | [Functions](https://vercel.com/docs/functions/usage-and-pricing): Active CPU, Provisioned Memory, and invocations. [Daemons](https://vercel.com/docs/daemons/limits): CPU and memory usage | Per-instance pricing for the full time an instance runs | | Persistent storage | Instance-local data is temporary; use external services for durable state | Persistent disks can attach to web services, private services, and background workers (not cron jobs); disk-backed services can't scale horizontally | | Multi-container projects | [Services](https://vercel.com/docs/services) and Daemons in one project; public rewrites route HTTP traffic and declared bindings enable internal service calls | Separate services connected over private networking | | Preview environments | HTTP services get preview deployments; Daemons run only in production during beta | Preview environments available per service configuration | ## How Docker deployments work on Vercel Vercel Functions run Open Container Initiative (OCI) compatible images as a first-class deployment target. Add a `Dockerfile` (or `Containerfile`) 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 On a new project, Vercel selects the Container preset when it detects no other framework. If it detects one, 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` at the project root also takes precedence over a detected framework. Here is a minimal example using Node.js and the `srvx` server: ```dockerfile FROM node:26-alpine RUN npm i -g srvx WORKDIR /app COPY server.ts . # srvx listens on $PORT by default CMD ["srvx", "--prod"] ``` Deploy the HTTP server by running `vercel deploy` or by pushing to a connected Git repository. Each deployment has its own URL, so you can preview the containerized service alongside your frontend. Daemons use the separate configuration described below and run only in production during beta. 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 stores and optimizes your images [Vercel Container Registry](https://vercel.com/docs/container-registry), or VCR, stores OCI images for your project and supports standard container tooling. Vercel stores images built during deployment in VCR. To upload an image separately, follow the registry's [authenticated build-and-push workflow](https://vercel.com/docs/container-registry), which recommends zstd compression. Deploy the HTTP app described here from its source Dockerfile using `vercel deploy` or Git integration. 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 Functions scale automatically, including to zero 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 Function instances can serve multiple requests, so temporary files or in-memory caches may survive while an instance is reused. That state can disappear when an instance stops and is not shared across instances. Store durable data in a database or object store, such as a provider from the [Vercel Marketplace](https://vercel.com/marketplace). ### Run continuous workers with Daemons [Vercel Daemons](https://vercel.com/docs/daemons) run containerized processes that keep pulling work from queues, workflow engines, or external APIs. Define a worker under `daemons` in your project configuration, with a Dockerfile in its configured root and an instance count for each region. Vercel restarts instances that exit. Daemons are in beta and run only in production. You set their instance counts; traffic does not autoscale them or scale them to zero. They accept no inbound HTTP or TCP traffic and have no persistent local storage. Review the [Daemons limits](https://vercel.com/docs/daemons/limits), including the Hobby CPU and memory quotas, before choosing this path. ### Run multiple containers in one Vercel project [Services](https://vercel.com/docs/services) let you deploy multiple frontends and backends in one project, and you can declare Daemons alongside them. For HTTP services, `rewrites` in `vercel.json` route incoming public requests. The frontend in this example also declares a binding so its server-side code can call the backend internally: ```json { "services": { "frontend": { "root": "frontend/", "runtime": "container", "entrypoint": "Dockerfile", "bindings": [ { "type": "service", "service": "backend", "format": "url", "env": "BACKEND_URL" } ] }, "backend": { "root": "backend/", "runtime": "container", "entrypoint": "Dockerfile" } }, "rewrites": [ { "source": "/api/(.*)", "destination": { "service": "backend" } }, { "source": "/(.*)", "destination": { "service": "frontend" } } ] } ``` The [binding](https://vercel.com/docs/services/bindings) grants the frontend access to the backend and injects its URL as `BACKEND_URL` at runtime. The rewrites expose the public routes separately; they do not create internal bindings. Each `entrypoint` is relative to that service's `root`. Daemons pull their own work and cannot be the target of a service binding or rewrite. For local development of HTTP services, run `vercel dev` with the `docker` CLI and a running Docker daemon. Test Daemons by running their images directly with Docker; they do not run in `vercel dev` during beta. ### Current limitations on Vercel Container image functions inherit the standard [Vercel Functions limits](https://vercel.com/docs/functions/limitations) for size, memory, and duration. The Container runtime is in beta on all plans. Custom container Functions do not support Secure Compute or Static IPs. [Secure Compute](https://vercel.com/docs/networking/secure-compute) provides dedicated network isolation, and [Static IPs](https://vercel.com/docs/networking/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. ## How Docker deployments work on Render 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](https://docs.docker.com/build/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. ### Render runs containers as multiple service types 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 instances stay on and can attach disks 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 ## Key differences to weigh ### Compute and pricing follow different models The largest difference is what you pay for. [Vercel Functions billing](https://vercel.com/docs/functions/usage-and-pricing) includes Active CPU, Provisioned Memory, and invocations. Waiting for a database query or upstream API does not consume Active CPU, but memory usage continues until the last in-flight request finishes. Between requests, CPU and memory charges pause. [Daemons](https://vercel.com/docs/daemons/limits) use CPU while executing and provisioned memory for the whole time an instance runs, including waits for work. Pro and Enterprise bill for those resources. Hobby applies monthly CPU and memory quotas; reaching either stops the team's daemons until the next month or an upgrade to Pro. 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. Compare expected CPU usage and memory duration alongside request volume or worker instance counts. Bursty HTTP traffic and a continuously polling worker have different resource profiles even when both use the same container image. ### Workload shape determines the better fit On Vercel, request-response backends and APIs run as container Functions, with the CDN and web security features handling public requests. Continuous queue consumers use Daemons, which keep polling for work independently of HTTP requests. Render supports continuous workers too, and its separate cron job service runs a container on a schedule and stops it when the job finishes. Private services and persistent disks accommodate workloads that need internal network access or durable local storage. [WebSocket support](https://vercel.com/docs/functions/websockets) is generally available on Vercel Functions, including container Functions. Each connection stays on one instance and closes when that function reaches its maximum duration, so clients need reconnect logic. Keep shared rooms and pub/sub state in an external store such as Redis. Render web services support WebSocket connections without a fixed connection-duration limit. ### State is handled differently Both Vercel Functions and Daemons need external storage for durable data. An instance may reuse local state while it is running, but a replacement instance cannot rely on those files or memory. Render offers attached persistent disks at the cost of horizontal scaling and zero-downtime deploys for that service. If your container requires a persistent local filesystem, Render's disk model is the more direct fit; if state already lives in a database, either platform can use it. ## When to choose Vercel for Docker Choose Vercel for containerized HTTP services that benefit from traffic-based autoscaling, or for continuous consumers that fit the Daemons model. 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 - Run continuous queue consumers alongside their app, with configured worker counts and durable state in external services - Have bursty HTTP traffic and want Functions to scale with requests - Want to preview HTTP services and frontends together before deploying to production - Need Vercel's CDN, WAF, and bot protection in front of public HTTP services ## When to choose Render for Docker Choose Render when your container requires attached disks, private TCP networking, or its direct prebuilt-image deployment workflow. Render fits teams that: - Run scheduled containers that finish and exit, including cron jobs longer than Vercel Function limits allow - Need private services that accept non-HTTP connections - Need persistent disks attached directly to the container - Serve WebSocket connections with no function duration limit or forced reconnects - Deploy prebuilt images directly from Docker Hub, GitHub, GitLab, Google Artifact Registry, or AWS ECR - Prefer flat, predictable per-instance billing over usage-based pricing You can also split workloads by requirement: run the frontend and HTTP API on Vercel, place eligible consumers in Daemons, and keep disk-backed or private TCP services on Render. Shared databases and queues connect the components. ## Resources and next steps - Read the [Container runtime documentation](https://vercel.com/docs/functions/runtimes/container) for full configuration details on Vercel - Learn how to store, push, and pull images in [Vercel Container Registry](https://vercel.com/docs/container-registry) - Review [Vercel Functions usage and pricing](https://vercel.com/docs/functions/usage-and-pricing) for CPU, memory, and invocation accounting - Review [Daemons](https://vercel.com/docs/daemons) and their [limits](https://vercel.com/docs/daemons/limits) for continuous workers - Explore [Vercel Services](https://vercel.com/kb/guide/vercel-services) to run frontends and containerized backends in one project - Compare the platforms more broadly in [Vercel vs Render](https://vercel.com/kb/guide/vercel-vs-render) - See [Docker on Render](https://render.com/docs/docker) for Render's build and registry options ## Related Documentation - [Vercel Container Registry](https://vercel.com/docs/container-registry) - [Vercel Services](https://vercel.com/docs/services) ## More Vercel Container Registry guides - [Running Docker on Vercel](/kb/guide/docker): Run Docker on Vercel for HTTP apps and background workers, store images in Vercel Container Registry, and test containers with Vercel Sandbox. - [How to choose between Functions, containers, and Daemons on Vercel](/kb/guide/vercel-functions-containers-daemons): Choose Vercel Functions for HTTP requests, container images for custom runtimes, and Daemons for continuous background workers. - [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. ## Reference Architecture Choose a stack and work through the decisions behind it, with curated documentation, guides, templates, and courses to help you build. - [Agent stack](/kb/architecture/agents): Build and operate agents with models, tools, and durable workflows. - [Web applications](/kb/architecture/web): Choose rendering, data, authentication, and caching approaches. - [Backends](/kb/architecture/backends): Choose a runtime, connect services, and run background work. [Browse all stacks](/kb/architecture)