Vercel learned to run any Dockerfile on Fluid compute platform

Vercel added support for arbitrary containers to its platform: developers can now deploy any service with a Dockerfile — from a Go service to a Rails or Spring Boot application — simply by adding a Dockerfile.vercel file to the project root, and the platform will build the image and deploy it on Fluid compute infrastructure.

How It Works

The mechanism is minimal: just the server and the Dockerfile.vercel file — and the project is ready to deploy. Vercel shows an example in Go: an HTTP server listening on a port from the $PORT environment variable (default 80) is built through a two-stage Dockerfile — first, the golang:1.24-alpine image compiles the binary, then it is copied to a minimal alpine:3.20 image, which is what runs in production.

The `vercel deploy` command from the CLI builds the image, saves it in the project registry, and deploys it on Fluid compute, returning a production URL. Each git push automatically rebuilds the image and creates a separate preview deploy with an immutable URL that can be opened, sent to colleagues, or used to roll back to a previous version.

• The only requirement for the server is to listen to HTTP on the port from the $PORT environment variable
• The example in the blog is built on golang:1.24-alpine and alpine:3.20 in a two-stage build
• Deploy is launched with a single command `vercel deploy` from the CLI, or automatically on git push
• Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, and services behind nginx are supported

Which Languages and Frameworks Are Supported

Vercel emphasizes that the specific stack doesn't matter — any service that can speak HTTP and listen to a port works. Explicitly mentioned are Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, and web servers behind nginx, including Java and PHP — platforms that were previously associated more with classic server hosting than with Vercel's serverless infrastructure.

What Developers Get

A container on Vercel becomes a full citizen of the platform: it runs on the same infrastructure as the frontend and other project services. Each commit gets its own preview deploy with a separate URL, and scaling happens automatically in both directions — when traffic grows, the platform adds instances; when traffic drops, it scales down, freeing the team from manually calculating fleet size or concurrency limits.

The pricing model is built on Active CPU: Fluid compute bills only for the time when the service code is actually executing, not for the entire lifetime of the instance. This means that an idle server stuck on a slow database request doesn't cost the team more than one actively working.

What This Means

The Dockerfile.vercel feature blurs the line between serverless platforms like Vercel and classic container clouds: now any service running on Java, PHP, or Ruby can be deployed without setting up your own image registry, daemon, or cluster, while getting automatic scaling and preview deploys by default.

Frequently Asked Questions

What requirements does a server need to deploy?

The only condition is that the server must listen to HTTP on the port from the $PORT environment variable (default 80). If a service responds to HTTP requests, it can be wrapped in Dockerfile.vercel and deployed.

What happens at each commit?

Each git push rebuilds the image and creates a separate preview URL that can be opened, sent to others, or used to roll back to a previous version of the project.

What frameworks does this work on?

Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, and services behind nginx — the example from Vercel's blog uses golang:1.24-alpine and alpine:3.20 in a two-stage build.