Vercel deploys plain Dockerfiles without framework detection

Vercel’s Container runtime, still in beta, now builds a plain root Dockerfile or Containerfile directly: it picks the Container preset, builds that file, and routes all traffic to the resulting image. Before this, deployment depended on framework detection, so a project without a recognised framework could not simply drop in a Dockerfile and expect it to be used.

You can also force container deployment explicitly, either by naming the file Dockerfile.vercel or Containerfile.vercel (which takes priority over any detected framework), or by setting it in config:

vercel project update --framework container

Multi-service projects still configure things through vercel.json, with a separate entrypoint per service.

Why it matters: this removes a real piece of friction for anyone running something Vercel’s framework detection does not recognise, a Go binary, a custom Python setup, anything you would otherwise containerise and ship elsewhere. You get Vercel’s deploy pipeline and Active CPU billing without reshaping the app to fit a preset first.

The caveat: Container runtime is still beta, and billing is Active CPU rather than flat container pricing, so cost behaves differently from a standard VM or container host.