Vercel Now Runs Any Dockerfile on Fluid Compute

Vercel has added native container deployment. Drop a `Dockerfile.vercel` into your project, run `vercel deploy`, and Vercel builds the image, stores it, and ships it to its Fluid compute platform. If your server speaks HTTP and listens on `$PORT`, it deploys — no local Docker daemon, no registry to configure, no cluster to babysit.

For anyone building automation backends, agent runtimes, or API glue that doesn't fit neatly into a serverless function, this is worth understanding. Here's what it actually does and where it fits.

What it actually does

The model is deliberately simple. You write a normal HTTP server in whatever stack you like — Vercel's post names Go, Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, and nginx as examples. You add a `Dockerfile.vercel` that builds and runs it. The only hard rule is that your server listens on `$PORT`, which defaults to 80.

From there the workflow mirrors the rest of Vercel. Every git push rebuilds the image and hands you a fresh, immutable preview URL you can open, share, or roll back to. Your container sits in the same project as your frontend and other services, talks to them privately over Vercel's network, and shares one dashboard for logs, traces, and metrics. One deploy ships your full stack.

The two headline operational features are autoscaling in both directions and "active CPU" pricing. Traffic arrives, instances scale out; traffic stops, they wind down. Because Fluid compute bills for the time your code is actually executing, a server parked on a slow database query or waiting on an upstream API isn't burning CPU while it idles. You pay for execution time, not wall-clock time.

Why this matters for automation and agents

A lot of AI automation work eventually outgrows a single function call. You want a long-lived process that orchestrates tool calls, streams responses, holds a connection open to a model, or runs a framework that assumes a persistent server. Serverless functions with tight timeouts and cold starts make that awkward. A container that speaks HTTP is a much more natural home for that kind of agent or backend service.

The active-CPU pricing angle is the interesting part here. Agent workloads spend a lot of time waiting — on OpenAI or Claude API responses, on retrieval queries, on external webhooks. If you're paying only for CPU that's actually running, that waiting time costs less than it would on a machine billed by the hour. Vercel also keeps warm instances around and serves many requests from each, so you get warm-server responsiveness without paying to keep a fleet sized for peak traffic.

There's a design constraint to respect: each container is a stateless process. It takes a request, returns a response, and keeps nothing in between. Persistent state lives in a backing service you attach — a database or cache. Vercel says durable storage attached to containers is "coming soon," but today you should assume any state your automation needs must live elsewhere. That's fine for most agent and API patterns, but it means you can't lean on in-memory sessions or local disk.

On startup, Vercel stores your image as a compressed "boot image" snapshot and streams it on demand, so your server can begin answering requests before the whole image finishes downloading. That reduces the usual penalty for larger images, though as with any autoscaling platform you'll want to test cold-start behaviour under your own traffic patterns before trusting it for latency-sensitive work.

Where it fits versus the alternatives

This puts Vercel in more direct competition with container hosts like Fly.io, Railway, Render, and AWS's various container services. The pitch is consolidation: if your frontend, functions, and now your containers all live on one platform with one domain, one deploy, and one observability view, you cut down on the seams between systems. For teams already on Vercel, adding a Go or FastAPI service without adopting a whole new deployment stack is a real convenience.

The trade-off is the usual one with an integrated platform. You're leaning further into Vercel's pricing and primitives, and the stateless-only constraint plus consumption billing means you'll want to model your costs against a fixed-price VM or a dedicated container host for steady, high-throughput workloads. Bursty, idle-heavy agent traffic is where active-CPU pricing shines; a service pinned at high CPU around the clock may be cheaper elsewhere.

If you're wiring this into a broader automation pipeline, a containerised HTTP service on Vercel makes a clean webhook target or API layer for orchestrators like Zapier, Make, or n8n to call, while keeping your model-facing logic in code rather than in a visual builder.

The practical takeaway: if you already ship on Vercel and have a service that speaks HTTP, this is a low-friction way to run it beside everything else. Just budget for stateless design and test your startup and cost behaviour before committing production traffic.

If you want help designing an agent backend or wiring a containerised service into your automation stack, browse the provider directory to find someone who can put it to work.