Five years later, Vercel finally lets a Dockerfile in — Rails, Spring, FastAPI to Fluid compute in one push
TL;DR
Vercel launched Dockerfile.vercel on June 30 — Rails, Spring Boot, FastAPI and any HTTP server ship to Fluid compute on every git push, billed on active CPU only.
Vercel on June 30 shipped «Bring your Dockerfile to Vercel Functions»: drop a Dockerfile.vercel or Containerfile.vercel at repo root, have the container listen on $PORT, and every
It is a full reversal of Vercel's five-year stance on Docker. The old posture was «serverless functions are the only door in — refactor your backend to stateless functions or take it somewhere else», which shoved Rails, Spring Boot, Laravel and ASP.NET onto Fly.io / Railway / Render, or over to AWS App Runner and Google Cloud Run for the hyperscaler-shaped work. The official blog said the quiet part out loud: «the idea was right, but the infrastructure to make it great didn't exist yet» — an admission that the serverless-only playbook did not cover every workload.
The supported list is written flat: Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, plus anything HTTP behind nginx. Vercel's line: «Two files, and you are live. Every
The Fluid compute billing is the sharper edge. Fly.io bills the full VM clock; Railway charges per-minute CPU + RAM; Vercel ports the Functions active-CPU model — your container is not charged while it awaits the database. For long-tail-traffic SaaS backends, at equal QPS the bill runs materially below Fly / Railway.
If it works, Rails / Spring and the rest of the traditional web-framework stack ride into Vercel alongside Next.js, and Vercel graduates from «the Next.js cloud» to «the cloud for any web app» — narratives at Fly.io's $400M valuation and Railway's Series B thin out. If it doesn't, Container Registry storage fees, cross-region cold starts and Fluid concurrency caps meet real Docker workloads and the five-year trust gap does not close on two config files.
via Vercel Changelog / Vercel Blog / Vercel Docs / Vercel KB
git push auto-builds an OCI image, pushes it to the built-in Vercel Container Registry, deploys it on Fluid compute, and bills only for active CPU — idle time is free.It is a full reversal of Vercel's five-year stance on Docker. The old posture was «serverless functions are the only door in — refactor your backend to stateless functions or take it somewhere else», which shoved Rails, Spring Boot, Laravel and ASP.NET onto Fly.io / Railway / Render, or over to AWS App Runner and Google Cloud Run for the hyperscaler-shaped work. The official blog said the quiet part out loud: «the idea was right, but the infrastructure to make it great didn't exist yet» — an admission that the serverless-only playbook did not cover every workload.
The supported list is written flat: Rails, Spring Boot, Express, Laravel, ASP.NET, FastAPI, plus anything HTTP behind nginx. Vercel's line: «Two files, and you are live. Every
git push rebuilds the image and hands you a fresh preview URL.» Preview environments, logs, routing and autoscaling all inherit from the Functions pipeline.The Fluid compute billing is the sharper edge. Fly.io bills the full VM clock; Railway charges per-minute CPU + RAM; Vercel ports the Functions active-CPU model — your container is not charged while it awaits the database. For long-tail-traffic SaaS backends, at equal QPS the bill runs materially below Fly / Railway.
If it works, Rails / Spring and the rest of the traditional web-framework stack ride into Vercel alongside Next.js, and Vercel graduates from «the Next.js cloud» to «the cloud for any web app» — narratives at Fly.io's $400M valuation and Railway's Series B thin out. If it doesn't, Container Registry storage fees, cross-region cold starts and Fluid concurrency caps meet real Docker workloads and the five-year trust gap does not close on two config files.
via Vercel Changelog / Vercel Blog / Vercel Docs / Vercel KB
