Vercel Now Runs Rails, Django and Go Apps From a Plain Dockerfile

Vercel Functions can now deploy an HTTP server straight from a Dockerfile, no Next.js or Node.js required. The change, shipped June 30, 2026, lets a Rails, Django, Spring Boot or Go app run on Vercel’s infrastructure with the same git-push deploys, preview URLs and autoscaling the platform has offered frontend projects for years (Vercel changelog, June 30, 2026).

---

How it works

A project that adds a Dockerfile.vercel (or Containerfile.vercel) to its root gets built as an Open Container Initiative-compliant image on every commit, rather than run through Vercel’s usual framework detection. The only hard requirement is that the container’s HTTP server listens on the $PORT environment variable (Vercel blog, “Run any Dockerfile on Vercel,” June 30, 2026). Vercel builds the image, pushes it to the newly launched Vercel Container Registry, and serves it from a Function running on Fluid compute, Vercel’s shared-instance compute model, rather than as a standalone container a team has to provision or scale by hand.

Cold starts are the obvious tax on packaging a full container instead of a slim function bundle. Vercel’s answer is a boot-snapshot format: it stores each image as a compressed, pre-tuned snapshot of the container’s disk and streams it in on startup, so the server can begin handling requests before the whole image has finished decompressing (Vercel, “Run any Dockerfile on Vercel”). Functions built this way share the platform’s existing limits: up to 5 GB uncompressed on Fluid compute, an 800-second execution ceiling generally available on Pro and Enterprise plans, and a scale-to-zero window of 5 minutes in production and 30 seconds on preview deployments (Vercel Functions limits).

The registry itself, Vercel Container Registry, ships in beta alongside the feature: 10 GB of image storage is included per month, with additional usage billed at $0.10 per GB-month (Vercel Container Registry pricing).

---

Why this matters

Vercel built its reputation, and its pricing, on being a frontend host with framework-aware magic for Next.js. Anything that needed a different language’s runtime, a long-lived process, or a dependency Vercel’s build image didn’t already ship, meant reaching for Render, Fly.io or a Cloud Run container instead. A Dockerfile that just needs a listening port collapses that distinction: the same continuous-deployment workflow Vercel offers a Next.js frontend now covers a Rails API or a Go worker sitting behind it, in the same project.

That convenience is still rough at the edges. A Vercel Community thread opened this month reports that concurrent requests to a container-image Function each spawn a fresh cold instance instead of reusing a warm one already handling traffic (Vercel Community, “Container Images (beta): concurrent requests spawn cold instances instead of reusing a warm one”). That’s exactly the kind of behavior a team migrating a production backend needs to trust before it ships. The feature is labeled beta for a reason.

---

Key Takeaways

• Vercel Functions now build and deploy any Dockerfile-based HTTP server that listens on $PORT, no framework detection required.
• Images are stored in the new Vercel Container Registry (10 GB/month included, $0.10/GB-month beyond that) and run on Fluid compute with a boot-snapshot format built for faster cold starts.
• Standard Vercel Function limits apply: up to 5 GB uncompressed image size, an 800-second execution ceiling on Pro/Enterprise, and scale-to-zero after 5 minutes idle in production.
• A community bug report already flags container-image Functions spinning up redundant cold instances under concurrent load. Test it against real traffic before moving a production backend over.

---

What to do

If a backend already lives in a Dockerfile, spike it: drop it in as Dockerfile.vercel, point it at a Vercel project, and see whether Fluid compute’s autoscaling holds up under your traffic pattern. It’s not yet the move for anything latency-sensitive or concurrency-heavy in production. The warm-instance bug is exactly the failure mode that matters there. For everything else, it’s a lower-friction way to keep a non-Next.js service next to a Vercel frontend without standing up a separate host.