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 Dockerfile.vercel file to your project, and Vercel builds, stores, deploys, and autoscales the image on Fluid compute, so you pay only for the CPU your code uses. No daemon to run locally, registry to set up, or cluster to babysit.

How it works

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

1package main2
3import (4	"fmt"5	"net/http"6	"os"7)8
9func main() {10	port := os.Getenv("PORT")11	if port == "" {12		port = "80"13	}14
15	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {16		fmt.Fprintln(w, "Hello from a container on Vercel 👋")17	})18
19	http.ListenAndServe(":"+port, nil)20}

A minimal HTTP server that reads its port from $PORT and answers every request.

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

1FROM golang:1.24-alpine AS build2WORKDIR /src3COPY . .4RUN go build -o /server main.go5
6FROM alpine:3.207COPY --from=build /server /server8CMD ["/server"]

A two-stage build that compiles the binary, then copies it into a minimal Alpine image that runs on boot.

Then deploy:

▲ vercel deployVercel CLI✓ Building image from Dockerfile.vercel✓ Stored image in your project's registry✓ Deployed to Fluid computeProduction: https://my-server.vercel.app

One command builds the image, stores it, and ships it to Fluid compute, then prints the production URL.

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

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 $PORT, which defaults to 80. If it speaks HTTP, it deploys. Yes, even Java. And yes, even PHP.

What you get

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 preview deployment for every push: Every commit gets its own immutable URL you can open, share, and roll back to.

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

Active CPU pricing: 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.

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

One project, one domain: 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.

Built to start fast

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 optimized boot image, a compressed snapshot of the container's disk tuned for fast startup.

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.