# Run any Dockerfile on Vercel

DevFeed: [Run any Dockerfile on Vercel](<https://devfeed.tech/articles/run-any-dockerfile-on-vercel-732.md>)

Original publisher: [Read original article](<https://vercel.com/blog/dockerfile-on-vercel>)

Author: Kevin Sundstrom

Published: 2026-06-30T16:00:00Z

Content type: article

Language: en

Sources: [Vercel News](<https://devfeed.tech/sources/vercel-news.md>)

Topics: [Dockerfile](<https://devfeed.tech/topics/dockerfile.md>), [Vercel](<https://devfeed.tech/topics/vercel.md>), [Deployment](<https://devfeed.tech/topics/deployment.md>), [autoscaling](<https://devfeed.tech/topics/autoscaling.md>), [observability](<https://devfeed.tech/topics/observability.md>), [web applications](<https://devfeed.tech/topics/web-applications.md>)

Tags: [autoscaling](<https://devfeed.tech/tags/autoscaling.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [http](<https://devfeed.tech/tags/http.md>), [logs](<https://devfeed.tech/tags/logs.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [network](<https://devfeed.tech/tags/network.md>), [observability](<https://devfeed.tech/tags/observability.md>), [traces](<https://devfeed.tech/tags/traces.md>), [vercel](<https://devfeed.tech/tags/vercel.md>)

## AI overview

Vercel introduces support for deploying applications from a Dockerfile.vercel file. The platform builds, stores, deploys, and autoscales container images on Fluid compute, with pricing based on active CPU usage. The article demonstrates a Go HTTP server and explains that other HTTP-speaking applications, including Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, Java, PHP, and nginx-backed servers, can use the same deployment model.

## Source excerpt

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: Add a Dockerfile.vercel file that builds it into a small image and runs it: Then deploy: 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 language 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 st