Run any Dockerfile on Vercel

You have a server in a container. Maybe it's a Go service, a Rails app, a Spring Boot API, or a web server behind nginx. It speaks HTTP. It listens on a port. It just needs somewhere to run.

Add a file to your project, and Vercel builds, stores, deploys, and autoscales the image on , so you pay only for the CPU your code uses. No daemon to run locally, registry to set up, or cluster to babysit.Dockerfile.vercelFluid compute

Here is a small HTTP server in Go, listening on :$PORT

Add a file that builds it into a small image and runs it:Dockerfile.vercel

Then deploy:

That is it. Two files, and you are live. Every rebuilds the image and hands you a fresh preview URL. Or run to deploy without committing.git pushvercel

We used Go in this example, but any stack works. Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, and a web server behind nginx all deploy the same way. The only rule is that your server listens on , which defaults to . If it speaks HTTP, it deploys. Yes, even Java. And yes, even PHP.$PORT80

A container on Vercel is a first-class citizen. It runs on the same platform, and the same compute, as your frontend and the rest of your .services on Vercel

A container is only as good as the time it takes to answer its first request.

When Vercel builds your image, it stores it as an , a compressed snapshot of the container's disk tuned for fast startup.optimized boot image

When a container boots, we stream that snapshot and decompress it on demand, rather than downloading the whole image before anything runs. Your server can start handling requests before the full image is in place, so a larger image does not have to finish downloading first.

Once an instance is running, Fluid compute keeps it warm and serves many requests from it, rather than starting a fresh copy for each one. You get the responsiveness of a warm server and the bill of one that sleeps when idle.

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, like a database or cache from the . Because an instance holds nothing that has to survive, Vercel can add instances when traffic arrives and retire them when it stops. We're also working on shipping durable storage attached to containers soon.Vercel Marketplace

Our let you deploy a Dockerfile with a single command. That was a decade ago, and the idea was right, but the infrastructure to make it great didn't exist yet.first platform

We've spent the years since building the primitives to handle it well. They power everything you run on Vercel: Builds, Functions, Sandboxes, and now containers. It all scales with traffic, and you only pay for the CPU you use. A container is now a first-class citizen, running on the same system as everything else.

Framework detection is our front door. When we recognize your framework, we read your code and , because the code already describes what it should do. For most apps it's the fastest way to ship. A Dockerfile is for everything else: a service that needs a system library like FFmpeg or Chromium, a framework we do not auto-detect yet, or an app you want to bring exactly as it already runs. It is the universal way to say how a program should be built, so when there is no framework to read, we meet it directly.derive the infrastructure your app needs

Everything around your Dockerfile is zero configuration. You point at the image, and the build, the registry, the rollout, the scaling, and the URL all just happen.

Your backend now ships the way your frontend does: one push, one preview, one platform. We can't wait to see what you build.

or to get started.Read the docsdeploy an example

Read more

How it works

What you get

Built to start fast

Why now?

Backends are back

• Every commit gets its own immutable URL you can open, share, and roll back to. A preview deployment for every push:

• Traffic arrives and you scale out. Traffic stops and your instances wind down. You never size a fleet or guess a concurrency number.Autoscaling, in both directions:

• : Fluid compute bills for the time your code is actually running, so an idle server, parked on a slow query or an upstream API, isn't burning CPU while it waits. You pay for execution time, not wall time.Active CPU pricing

• Logs, traces, and metrics for your container live in the same dashboard as everything else you ship.Observability, included:

• Your container sits beside your frontend and your other services and talks to them privately over the Vercel network. Your full stack ships as one deploy.One project, one domain: