Vercel Can Now Run Any Dockerfile on Fluid Compute

Vercel has added support for arbitrary containers to its platform. Developers can now deploy any service that has a Dockerfile, from a Go service to a Rails or Spring Boot app, by adding a Dockerfile.vercel file to the project root. The platform builds the image and deploys it on its Fluid compute infrastructure.

How it works

The setup is minimal: the server itself plus a Dockerfile.vercel file, and the project is ready to deploy. Vercel's example uses Go: an HTTP server that listens on the port from the $PORT variable (80 by default) and builds with a two-stage Dockerfile. First, a golang:1.24-alpine image compiles the binary; then the binary is copied into a minimal alpine:3.20 image, which is what runs in production.

Running `vercel deploy` from the CLI builds the image, stores it in the project's registry, deploys it on Fluid compute, and returns a production URL. Every git push automatically rebuilds the image and creates a separate preview deployment with an immutable URL that you can open, share with teammates, or use to roll back to an earlier version.

• The only server requirement is listening for HTTP on the port from the $PORT variable
• The blog example uses golang:1.24-alpine and alpine:3.20 in a two-stage build
• Deployment runs with a single `vercel deploy` command 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 stresses that the specific stack doesn't matter: any service that speaks HTTP and listens on a port will work. The explicit list includes Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, and web servers behind nginx, covering Java and PHP — platforms long associated more with traditional server hosting than with Vercel's serverless infrastructure.

What developers get

A container on Vercel becomes a first-class citizen of the platform, running on the same infrastructure as the frontend and the project's other services. Every commit gets its own preview deployment with a separate URL, and scaling happens automatically in both directions: the platform adds instances when traffic grows and winds them down when it drops, so teams no longer have to size their fleet or set concurrency limits by hand.

Billing follows the Active CPU model: Fluid compute charges only for the time the service's code is actually executing, not for the instance's entire lifetime. That means an idle server stuck waiting on a slow database query doesn't cost the team more than one that's actively working.

What it means

Dockerfile.vercel blurs the line between serverless platforms like Vercel and traditional container clouds. Any Java, PHP, or Ruby service can now be deployed without setting up your own image registry, daemon, or cluster, with autoscaling and preview deployments included by default.

FAQ

What does a server need to be deployed?

The only requirement is that the server listens for HTTP on the port from the $PORT environment variable (80 by default). If a service responds to HTTP requests, you can wrap it in Dockerfile.vercel and deploy it.

What happens on every commit?

Every git push rebuilds the image and creates a separate preview URL that you can open, share with others, or use to roll back to a previous version of the project.

Which frameworks does it work with?

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