Vercel builds and deploys plain Dockerfiles on its Container runtime

What's new

Vercel can now build and deploy a plain Dockerfile with no framework in the picture. According to the Vercel blog, when a project contains a root Dockerfile or Containerfile and Vercel's detection finds no other framework, the platform selects its Container preset, builds that file, and routes all traffic to the image it produces.

The changelog demonstrates with a minimal example: a container based on node:26-alpine that installs srvx globally, copies the project into /app, exposes port 3000, and starts srvx on that port. Anything with that basic shape — a base image, an exposed port and a start command — is enough to get a running deployment.

How framework detection interacts with it

The automatic path only triggers when nothing else is detected. If Vercel recognises a framework in the repository, such as Django, that framework's build still wins.

Two escape hatches force the container route instead. One is the CLI, with vercel project update --framework container. The other is configuration, by setting "framework": "container" in vercel.json.

An existing override also carries over: a file named Dockerfile.vercel or Containerfile.vercel continues to take precedence over a detected framework. Multi-service projects keep their current setup, using vercel.json services with a per-service entrypoint.

Runtime status and billing

The changelog also restates where the underlying runtime stands. The Container runtime is in beta, runs on Vercel Functions, and is billed with Active CPU pricing rather than a flat always-on rate.

Why it matters

The change removes the framework requirement that previously shaped container deployments on the platform. Teams running apps that map to no recognisable framework — internal tools, legacy services or stacks without a preset — can commit a Dockerfile they may already have and let Vercel build it, instead of restructuring the project or forcing it into an ill-fitting framework choice.

The precedence rules are the detail worth remembering. Detection still beats the Dockerfile unless you opt in explicitly, so existing framework deployments will not silently flip to container builds. Conversely, anyone who wants containers everywhere needs to set the framework once, via the CLI or vercel.json.

Combined with Active CPU pricing on a beta runtime, the feature reads as an invitation to bring arbitrary workloads to a platform that was previously organised around framework presets — and a step toward serving container-first use cases without giving up Vercel's build and routing pipeline.