Vercel Now Lets You Deploy Any Dockerfile Straight to Production

Vercel built its name on frontend deployments. Push code, get a URL, done. Backends were a different story — if your app didn’t fit Vercel’s supported frameworks, you were out of luck.

That changed this week. Vercel now runs any HTTP server straight from a Dockerfile, letting teams bring a Rails, Django, Spring Boot, or Go app and have Vercel build, deploy, autoscale, and run it on Fluid compute with Active CPU pricing. In plain terms: If your server speaks HTTP and listens on a port, it can run on Vercel now. No exceptions for language or framework.

How the New Workflow Works

The setup is simple by design. Developers add a Dockerfile.vercel file to their project, and Vercel takes it from there — building the image, storing it, deploying it, and scaling it based on traffic. There’s no local daemon to run, no registry to configure, and no cluster to manage.

Vercel published a short example using Go, but the company is clear that the language doesn’t matter. Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, and a web server behind nginx all deploy the same way, since the only real requirement is that the server listens on the PORT environment variable, which defaults to 80. Every git push triggers a new build and a fresh preview URL, so teams get the same continuous deployment experience they’re used to with frontend projects.

The Catch: These are Containers Running as Functions

Here’s the part worth reading closely before you migrate anything. These Dockerfiles don’t run as standalone containers — they run as OCI images on top of Vercel Functions and Fluid compute. That means they inherit function limits: Capped size, capped memory, capped execution duration. They scale to zero after five minutes of idle time. They’re stateless by design, and durable storage attached to a container hasn’t shipped yet. Secure Compute and Static IPs, two things container platforms take for granted, don’t work with custom containers yet either.

None of that makes the feature less useful. But it does mean that “any Dockerfile runs” is true only within the serverless function model, not in the sense that “your existing container workload can lift and shift unchanged.”

What Teams Actually Get

For DevOps teams, the appeal isn’t the Dockerfile itself — it’s what happens after the build. Vercel is bundling in a handful of things that used to require separate tooling:

• Preview deployments for every push. Each commit gets its own immutable URL for testing and rollback.
• Autoscaling in both directions. Instances scale out under load and back to zero when idle, with no manual fleet sizing.
• Active CPU pricing. Billing is tied to actual compute time, not wall-clock time, so a container idling while waiting for a slow database query isn’t incurring costs.
• Built-in observability. Logs, traces, and metrics for containers show up in the same dashboard as everything else on the platform.
• One project, one domain. Containers, frontend, and other services communicate privately over Vercel’s internal network.

That last point matters more than it might seem. A lot of teams run their frontend on Vercel and their backend elsewhere, which means managing two deployment pipelines, two sets of logs, and two vendors to troubleshoot when something breaks. Vercel is betting that collapsing those into a single platform is worth the switch for workloads that fit its model.

“The backend deployment surface Vercel long ceded to container platforms is being pulled back in,” said Mitch Ashley, VP and practice lead, software lifecycle engineering and AI-native software engineering, at The Futurum Group. “Any Dockerfile now runs beside the frontend on shared compute, observability, and one bill, which reflects platform vendors competing to own the application lifecycle. The evaluation is fit: Whether a backend runs as a stateless function with duration limits and no durable storage yet. Consolidation lowers overhead and raises switching costs. Teams commit to an architecture, and that commitment outlasts the ease of one push.”

Startup Speed was the Harder Problem

Anyone who has run containers in production knows the trade-off: A cold container is slow to respond to its first request, but keeping instances warm around the clock gets expensive fast.

Vercel says it addressed this by storing images as compressed snapshots and streaming them on demand at boot, rather than requiring the full image to download before the container can respond. Once an instance is running, Fluid compute keeps it warm and routes multiple requests to it instead of spinning up a new copy for each one. The goal is the responsiveness of a warm server with the cost profile of one that sleeps when idle.

Why is This Happening Now?

Vercel isn’t new to this idea. Its original platform, launched under the name “now” roughly a decade ago, let developers deploy a Dockerfile with a single command — the concept was right, but the underlying infrastructure to make it work well didn’t exist yet.

The company says the years since have gone into building the pieces — builds, functions, sandboxes — that make container support viable today. Framework detection remains Vercel’s preferred path when it can read a codebase and infer what infrastructure it needs. Dockerfile support is the fallback for everything else: Apps that need a system library like FFmpeg, frameworks that Vercel doesn’t auto-detect, or teams that just want to bring their app as-is.

The Bottom Line for IT Leaders

This move puts Vercel in more direct competition with platforms like Render, Fly.io, and Railway, all of which built their businesses on flexible container deployment. For platform engineering teams already standardized on Vercel for frontend work, the pitch is consolidation — one fewer vendor, one fewer pipeline to maintain, and a bill that reflects actual usage rather than reserved capacity.

But the barrier hasn’t disappeared — it’s moved. Teams still need to check whether their workload fits a stateless function model with duration limits and no durable storage before assuming a lift-and-shift is on the table. For apps that fit, this closes a real gap. For anything stateful or long-running, the dedicated container platforms still have the edge, at least for now.