Vercel Now Deploys a Plain Dockerfile: What Changes

Vercel will now deploy a project that is nothing more than a Dockerfile. If a repo has a root Dockerfile or Containerfile and Vercel detects no other framework, it picks the Container preset, builds the image and sends all traffic to it, with no vercel.json required. The catch is in the fine print: the image runs as a Vercel Function, so it inherits Functions limits and Active CPU billing, and the Container runtime is still in beta.

That makes Vercel a real option for Python services, Go binaries, agent backends and anything else with a Dockerfile, but it is not a drop-in replacement for an always-on container host. Here is what changed, how detection decides what gets built, what the image actually runs on, and when it beats Google Cloud Run, Railway, Fly.io or Render.

What changed on Oct 27

Vercel already had a Container runtime in beta for Vercel Functions: you could run any Open Container Initiative (OCI) image built from a Dockerfile, but you had to opt in. The Oct 27, 2026 changelog removes that step for the simplest case. A plain root Dockerfile or Containerfile is now enough on its own when nothing else is detected.

• New project, root Dockerfile, no framework detected: Vercel selects the Container preset automatically, builds the file and routes every request to the resulting image.
• Project that matches a framework, such as Next.js or Django: the framework still wins. Your Dockerfile is ignored unless you tell Vercel otherwise.
• A Dockerfile.vercel or Containerfile.vercel file: this continues to override a detected framework, so you can keep a separate production image just for Vercel.
• Multi-service projects: still configured through the services key in vercel.json, with a per-service entrypoint pointing at each Dockerfile.

During the build, Vercel pushes the image to its own Vercel Container Registry. You can deploy from the CLI or by pushing to Git, and vercel dev can run the container locally if Docker is installed.

How to deploy a Dockerfile to Vercel

For a repo with no framework, there is nothing to configure. The only rule that trips people up is the port. Vercel expects the container to open an HTTP server, defaults to port 80, and lets you override it by setting a PORT environment variable in project settings. The example below is illustrative, written for this article rather than taken from Vercel's docs, and has not been deployed by Metarix. It shows a small Python API that reads PORT so it works locally and on Vercel:

FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
# Vercel defaults to port 80; set PORT=8000 in project settings to match
CMD ["sh", "-c", "uvicorn main:app --host 0.0.0.0 --port ${PORT:-8000}"]

If the project already matches a framework and you want the Dockerfile instead, switch the framework explicitly. Either run this once:

vercel project update --framework container --yes

or pin it in the repo so it survives new projects and forks:

{
"framework": "container"
}

For a frontend and a backend in one project, Vercel's documented pattern is two services, each with its own root and Dockerfile, plus rewrites that send /api/ traffic to the backend service and everything else to the frontend.

What your container actually runs on

This is the part to read twice. A container on Vercel is not a long-lived VM or a pod that stays up. It is a Function instance built from your image, and Vercel says the same limits and pricing model as other Vercel Functions apply. Per Vercel's documentation as of Oct 28, 2026:

• Scale to zero. An instance with no traffic for 5 minutes in production, or 30 seconds in preview, is scaled down. The container gets SIGTERM and a 30-second grace period before it is killed.
• Memory and CPU. Up to 2 GB and 1 vCPU on Hobby, and up to 4 GB and 2 vCPU on Pro and Enterprise.
• Duration. Requests default to 300 seconds. Pro and Enterprise can raise that to 800 seconds, with an 1,800-second extended maximum in beta for specific Node.js, Bun and Python runtime versions.
• Payloads. Request and response bodies are capped at 4.5 MB per Function.
• Concurrency. Auto-scales up to 30,000 concurrent executions on Hobby and Pro, and 100,000 or more on Enterprise, with 1,024 file descriptors shared across concurrent executions on an instance.
• Networking gaps. Secure Compute and Static IPs are not yet supported with custom container images.
• Logs. stdout and stderr are captured as runtime logs, but because they are not tied to a request, Vercel broadcasts them to every in-flight request on that instance. Tag your log lines with a request ID if you need to trace them.

Two practical consequences follow. First, anything that must keep running between requests, such as a queue consumer, a cron loop inside the process, or a websocket hub that holds state in memory, will be interrupted when the instance scales down. Second, your startup time matters, because a cold instance has to boot your image before it can answer.

For background work, Vercel points to Daemons, a separate public beta that runs container images continuously without receiving traffic. Vercel keeps a configured number of instances running per region and restarts them if they crash. That is the right primitive for Celery, Sidekiq or BullMQ workers; the plain-Dockerfile path is for HTTP services.

What it costs: Active CPU pricing

Containers bill like every other Fluid compute Function, on three meters. Active CPU is charged only while your code is actually executing, not while it waits on a database or a model API. Provisioned memory is charged for the whole time an instance is alive and handling requests, including I/O waits. Invocations are counted per request.

Prices as of Oct 28, 2026, from Vercel's Functions pricing page: in Washington, D.C. (iad1), Portland and Cleveland, Active CPU is $0.128 per hour and provisioned memory is $0.0106 per GB-hour. Frankfurt is $0.184 and $0.0152, and São Paulo, the most expensive listed region, is $0.221 and $0.0183. Hobby includes 4 hours of Active CPU, 360 GB-hours of memory and 1 million invocations a month. Pro bills on demand, with invocations at $0.60 per million, offset by the plan's monthly usage credit.

An illustrative, worst-case estimate (our arithmetic on those list prices, not a measured bill): an API in iad1 with 2 GB of memory, where each request uses 50 ms of CPU and keeps the instance busy for 300 ms while it waits on an upstream call. If every request had an instance to itself, a million requests would cost about $1.78 of CPU, $1.77 of memory and $0.60 of invocations, roughly $4.15 in total. In practice concurrent requests share an instance's memory, so the memory line usually comes in lower.

That model is why the change matters for AI builders. An agent endpoint that spends most of its life waiting on an LLM is mostly I/O, so you pay for memory while it waits but not for idle CPU. If you route those model calls through a gateway, our AI gateways comparison covers how Vercel AI Gateway, Cloudflare and OpenRouter differ.

Vercel vs Cloud Run, Railway, Fly.io and Render

Vercel is clearly aiming at the container hosts. Its Container runtime docs link migration guides from Railway, Fly.io, Render, Google Cloud Run and self-hosted containers on AWS. How it compares depends on what your container does.

Google Cloud Run

Cloud Run is the closest model: managed containers that scale to zero. Its ceilings are much higher. Google's quota page lists up to 32 GiB of memory and 8 vCPU per instance, a 60-minute maximum request timeout, and a 32 MiB request size on HTTP/1 (no limit on HTTP/2). Billing is per vCPU-second and GiB-second, and Google offers both request-based and instance-based billing; on instance-based billing the free tier is 240,000 vCPU-seconds and 450,000 GiB-seconds a month, according to its Cloud Run pricing page as of Oct 28, 2026. Pricing models differ enough that the two aren't directly comparable per request; model your own traffic on each calculator. Pick Cloud Run for heavy memory, long requests, large uploads or anything already inside Google Cloud.

Railway, Fly.io and Render

These platforms are built around containers or services that can stay running, which suits stateful processes, long-lived connections and background workers in the same app. Vercel's answer for those cases is Daemons plus Functions, both partly in beta. Choose Vercel when the service is request-driven and you want it beside a Vercel frontend, with previews and rollbacks in one place. Stay put if your app depends on always-on processes or on networking features Vercel's container path doesn't support yet.

AWS

On AWS, the same container would typically run on Amazon ECS with Fargate, App Runner or Lambda container images, each with its own scaling and pricing. If you need VPC-level control, canary routing or GPUs, AWS still offers far more knobs; see how ECS can canary through VPC Lattice for one example of that depth.

When the plain-Dockerfile path fits

• A stateless HTTP API in Python, Go, Rust, Ruby or Java with native dependencies that are painful to bundle as a regular Function.
• An agent or MCP server backend that mostly waits on model APIs, where Active CPU billing works in your favor.
• A monorepo where a Vercel frontend needs one or two backend services and you want a single project, one set of previews and one dashboard.
• A small static or Nginx site you already ship as an image and want on Vercel's CDN without rewriting the build.

When it doesn't

• Workers, schedulers or anything that must run between requests: use Daemons, Vercel Workflows or another host.
• Requests longer than 800 seconds on Pro (1,800 in beta) or bodies over 4.5 MB.
• Workloads that need more than 4 GB of memory or 2 vCPU per instance.
• Anything that needs Static IPs or Secure Compute today.
• Production systems that can't accept a beta runtime's rough edges.

Verdict

This is a small changelog entry with a big practical effect: the shortest path to running non-JavaScript backends on Vercel is now just a Dockerfile. For request-driven APIs and agent backends that sit next to a Vercel frontend, it is worth trying today, and Active CPU pricing is a genuine advantage for I/O-heavy AI workloads. Keep long jobs, stateful services, large payloads and big-memory work on Cloud Run, ECS or a container host, and treat the runtime as beta until Vercel says otherwise.

If you use Vercel for model routing as well, our look at how Vercel added Le Chonk to its gateway the same day shows how quickly it ships on the AI side.

Sources

• Vercel changelog: Deploy a container from a plain Dockerfile (Oct 27, 2026)
• Vercel docs: Container Runtime
• Vercel docs: Functions limits
• Vercel docs: Fluid compute pricing
• Vercel docs: Daemons
• Google Cloud: Cloud Run quotas and limits
• Google Cloud: Cloud Run pricing