How Vercel's container support changes backend hosting — when stateless HTTP APIs, Active CPU pricing, and preview…
Complete Docker guides with optimization techniques, deployment strategies, and automation prompts to streamline your containerization workflow.
No spam. Unsubscribe anytime.
Meta title: Vercel Dockerfile Support: Should You Run Your Backend on Vercel?
Meta description: Vercel can now run Dockerfile-based container images. Here is what that changes for backend hosting, when it fits, and when another platform is still the better choice.
Slug: vercel-dockerfile-backend-hosting
Vercel now supports deploying custom Dockerfile-based container images as Vercel Functions. You add a Dockerfile.vercel file, Vercel builds it, stores the image in Vercel Container Registry, and runs it as an HTTP-backed function that scales with demand under the same Active CPU pricing model as other Vercel Functions. That means a stateless HTTP backend, in Go, Python, Ruby, or any language that produces a container, can now ship inside the same Vercel project as the frontend, with the same git push workflow, preview URLs, and routing.
This changes the default question for a lot of projects I work on. The decision used to start with "where do we host the backend." Now it starts with "is this backend stateless, HTTP-based, and tied closely enough to the frontend that it belongs on Vercel too."
I have been building B2B websites that need more than static pages for a while now, and the backend has always been the part that breaks the clean Vercel workflow. One deployment pipeline for the frontend, another for the API. One set of preview environments for the UI, a weaker setup for backend testing. This release is the first time Vercel has made a real case for closing that gap, so I went through the docs and the pricing model to work out where it actually applies.
A Dockerfile defines the environment, dependencies, copied files, build steps, and startup command for an application. Vercel's older documentation was explicit that it did not support deploying Docker images directly and did not run Docker instances as a deployment target. With Vercel Container Images, that limitation is gone. You place a Dockerfile.vercel or Containerfile.vercel in the project, Vercel detects it, builds the image, and runs it as a function-backed HTTP service.
The contract is simple. The application starts an HTTP server and listens on the expected port, which defaults to 80 and can be changed with the PORT environment variable. That contract is language-agnostic. A Go service, a FastAPI service, a Rails app, a Spring Boot app, a Laravel app, an Express server, or a service behind nginx can all run through the same mechanism.
Vercel's strength has always been framework detection, inferring deployment behavior from the source code it recognizes. Plenty of backends sit outside that model: native system libraries, FFmpeg or Chromium dependencies, frameworks Vercel does not detect, or existing services nobody wants to rewrite for a hosting platform. Dockerfile support is the escape hatch for exactly those cases. It tells Vercel to build and run the image as defined, instead of inferring infrastructure from the framework.
Reading this as "Vercel supports Docker now" undersells it. Render supports Dockerfile-based deploys. Railway supports Dockerfiles. Google Cloud Run has run serverless containers for years. Fly.io is built around globally deployable machines and containers. AWS App Runner runs services from source or container images. Container support on its own is not the differentiator.
The differentiator is the Vercel workflow wrapped around the container: git push deployment, preview URLs, rollback, domains, logs, metrics, frontend and backend living in one project, route-based service composition, usage-based scaling. Vercel is not positioning itself as Kubernetes. It is making more backends feel like frontend deployments, which is a different starting point than the traditional model.
A traditional backend hosting decision starts with infrastructure: service, region, instance size, runtime, container registry, networking, deploy pipeline, observability, scaling rules. The Vercel model starts with the project: frontend, backend, routes, environment variables, preview deployment, production deployment. The platform absorbs the rest. For product teams, agencies, and B2B web projects, that means the backend stops being an automatic separate hosting decision.
The feature that makes Dockerfile support interesting in practice is Vercel Services. Services let you deploy multiple backends and frontends inside one Vercel project. Vercel's own example is a Next.js frontend and a FastAPI backend in the same repository, deployed together with shared routing, environment variables, and one domain.
A project structured this way looks like:
project/
frontend/
package.json
app/
backend/
Dockerfile.vercel
main.py
vercel.json
And vercel.json routes traffic between the two services:
{
"services": {
"frontend": {
"root": "frontend/"
},
"backend": {
"runtime": "container",
"root": "backend/"
}
},
"rewrites": [
{ "source": "/api/(.*)", "destination": { "service": "backend" } },
{ "source": "/(.*)", "destination": { "service": "frontend" } }
]
}
The frontend and backend stay separate services but ship as one deployment. A branch that touches both gets a preview that represents the whole application, API traffic routes under the same domain, and the project surface stays smaller. For a lot of teams, that workflow benefit carries more weight than the container feature itself.
The strongest fit is a stateless HTTP backend that is closely related to the frontend, the kind of business logic layer that a modern B2B website or product platform needs alongside its public pages: quote request logic, product configurator APIs, search endpoints, CMS preview endpoints, auth-adjacent logic, CRM or ERP integrations, AI API wrappers, document generation endpoints, custom admin tooling, webhooks, content processing endpoints.
FastAPI next to a frontend. A Next.js, Astro, or React frontend paired with a Python API used to mean splitting hosting between Vercel and Render, Railway, Fly.io, or Cloud Run. With container support, that backend can live in the same Vercel project as a containerized service, which simplifies preview deployments most when a branch changes both the frontend and the backend contract at once.
Go APIs. Go services compile to small, fast-starting binaries, which fits Vercel's function-style lifecycle well. A stateless, request-driven Go API built from a compact multi-stage Dockerfile is one of the cleanest matches for this feature.
Apps with native dependencies. FFmpeg, Chromium, image processing libraries, PDF tooling, custom binaries, or runtimes outside the usual frontend stack are awkward inside standard serverless functions. A Dockerfile hands you control over the environment directly, so you define the runtime instead of working around the platform's assumptions.
Backend services for AI apps. Vercel's pricing docs describe Active CPU as billed for actual code execution, excluding time spent waiting on I/O such as database queries or AI model calls, while provisioned memory bills for the life of the function instance. An AI backend that mostly coordinates calls to model APIs, a vector database, and Postgres spends most of its time waiting, which fits that pricing model well. A backend that transcodes video locally or runs heavy inference for minutes at a time is a different workload.
Internal tools and client previews. This is the use case I expect to lean on most for agency work. Client projects often need a small backend alongside the frontend preview: CMS preview mode, test integrations, webhook simulations, admin routes, import or export tools, prototype APIs. Reviewing one combined environment instead of telling a client "the frontend preview is here, the backend is still on staging" is a real workflow improvement.
Container support changes what Vercel can run. It does not remove the underlying architecture decisions, and a container that packages an app cleanly does not automatically make that workload a good fit for a scale-to-zero, function-like environment.
Persistent local disk. Vercel Functions have a read-only filesystem with a writable /tmp scratch space capped at 500 MB. A bundled read-only SQLite database can work for lookup-heavy use cases, but a writable SQLite database used as the production source of truth needs a real backing service instead. Vercel's storage docs point toward Blob for files, Edge Config for low-latency configuration, and marketplace databases for relational, key-value, NoSQL, and vector use cases. The container itself should stay stateless, with the database, object storage, queue, and cache living outside it.
Long-running background workers. Container-backed functions still carry function limits. Vercel lists a default duration of 300 seconds on Hobby, Pro, and Enterprise, with higher maximums available depending on configuration and beta support. A queue worker that continuously consumes jobs, a long-running daemon, a scheduler with persistent in-memory state, or any process that needs to stay alive indefinitely is a closer match for a dedicated worker platform, a VPS, Kubernetes, Fly Machines, or Cloud Run jobs.
Heavy CPU workloads. Active CPU pricing rewards request-driven, I/O-heavy work, but CPU-heavy work still consumes CPU regardless of the billing model. Video transcoding, large image processing, local AI inference, heavy PDF generation, browser automation at scale, and large data transformations can run in a container technically, while cost, duration, memory, and reliability remain open questions worth measuring before committing.
Static IPs or Secure Compute. Vercel's Container Images docs currently state that Secure Compute and Static IPs are not yet supported with custom container images. For B2B and enterprise integrations, this matters directly: databases, APIs, ERPs, CRMs, and payment systems that require IP allowlisting cannot rely on this path yet, even though Vercel offers Static IPs and Secure Compute for other use cases.
Large monoliths with unclear runtime assumptions. Existing Dockerized apps often carry assumptions that surface only after migration: local filesystem writes, cron jobs inside the container, background workers started by the same process, in-memory session state, local uploads, long-running TCP connections, process managers built for a traditional VM, multiple services inside one container, or Docker Compose dependencies. Auditing these before moving is the difference between a smooth migration and a confusing one.
The table below summarizes the fit:
| Backend trait | Good fit for Vercel containers | Stick with traditional hosting |
|---|---|---|
| Statefulness | Stateless HTTP API | Holds persistent state or writable local disk |
| Lifecycle | Boots quickly, runs per-request | Needs to run continuously or forever |
| Workload type | I/O-heavy, waits on DB/API calls | CPU-heavy processing (transcoding, inference) |
| Networking | No static IP requirement | Needs static egress IP or Secure Compute |
| Composition | Single container, single process | Docker Compose with multiple coordinated services |
The Active CPU model is one of the more interesting parts of this release. Vercel Functions on Fluid compute price around Active CPU, provisioned memory, and invocations, and Active CPU specifically excludes time spent waiting on I/O. A backend that spends 100ms computing and 900ms waiting on a database behaves very differently, cost-wise, from one that spends 1000ms burning CPU. Most web API requests fit the first profile: validate input, call a database, call another API, transform the result, return JSON.
Memory still matters separately from CPU. A containerized app with high memory allocation can cost more than expected even with modest CPU usage, so the questions worth answering before moving are how much memory the container needs, how long requests stay open, how much CPU work happens per request, how much concurrency each instance handles, whether the app holds requests open while waiting on slow upstream services, and whether any background tasks are hiding inside request handlers. For a small API this is quick to reason about. For a production system, it is worth measuring under real traffic.
Vercel scales container-backed functions down after 5 minutes of no traffic in production and 30 seconds in preview. A scaled-down instance receives SIGTERM with a 30-second grace period before termination. That behavior is good for cost control and it is also a constraint your application needs to design around: clean shutdown handling, no assumption that the process lives forever, no reliance on in-memory state surviving to the next request, connections closed properly, and the ability to boot from scratch every time.
A traditional server can feel like a stable machine that just keeps running. A Vercel container is an ephemeral, stateless process by design, and treating it that way from the start avoids most of the surprises.
The right comparison question is not which platform supports Docker. Most of them do at this point. The question is what kind of workflow you want around the backend.
| Platform | Best fit | Choose it when |
|---|---|---|
| Vercel containers | Backend that is part of a frontend-led product or website | The backend is stateless, HTTP-based, and tied closely to the frontend experience |
| Google Cloud Run | Mature serverless containers with deeper cloud infrastructure | The backend is more central than the frontend or needs cloud-native infrastructure control |
| Render / Railway | Traditional PaaS with databases, workers, and services included | You want easy Docker deploys without going fully into cloud infrastructure |
| Fly.io | Globally distributed instances and long-running machines | The backend is the product and global runtime placement matters |
| VPS | Cost predictability and full control | The workload is predictable and you are comfortable managing the server |
Vercel containers are not a categorical upgrade over these options. They are the right choice specifically when the backend should share the frontend's deployment workflow.
For most modern B2B web projects, the pattern I would reach for is:
Vercel project
frontend service
Next.js / Astro / React
backend service
Dockerfile.vercel
FastAPI / Go / Express / Rails / Laravel
shared routing
/ -> frontend
/api/* -> backend
external state
Postgres
object storage
cache
queue
The frontend and backend ship together while staying isolated as separate services. State lives outside the container. Routing gives users one public surface. This fits B2B websites particularly well, where the site has stopped being a brochure and started carrying dynamic product configuration, gated content, quote generation, CRM integration, custom search, pricing logic, customer portals, AI-assisted support, documentation search, localization workflows, and CMS preview tools. Those features need a backend. Container support on Vercel changes whether that backend automatically needs its own infrastructure platform.
Before moving an existing Dockerized backend to Vercel, work through this list.
CMD, without manual setup steps or multiple processes that belong in separate services.80, overridable through the PORT environment variable. Reading PORT from the environment is the safest pattern./tmp is fine for scratch space; anything durable belongs in object storage..env files at runtime.SIGTERM before scale-down, the app needs to close database connections, stop handling requests, and avoid corrupting temporary work during that grace period.The mistake is treating a Vercel container like a normal VM. It is still part of the Vercel Functions model underneath, which means it should stay stateless, request-driven, tolerant of cold starts, able to survive scale-down, free of durable state inside the container, within function limits, and measured under real traffic before you trust it. Docker gives you packaging control over how the application is built and run. The runtime model underneath is still Vercel's function model, and designing for that model from the start is what makes the migration pay off.
Does Vercel support Docker Compose for production backends? Not directly. Vercel containers run as single-process Vercel Functions, so a setup that expects Postgres, Redis, an app server, and a worker running together through Docker Compose needs to be split apart, with the database, cache, and worker moved to dedicated services outside the container.
What port should my containerized app listen on?
80 by default, or whatever you set through the PORT environment variable. Reading PORT from the environment rather than hardcoding a port is the safer pattern across environments.
Can I run a Python or Go backend on Vercel without a Dockerfile? Vercel has framework-specific support for some Python and Go use cases, but Dockerfile support is what removes the requirement to fit into Vercel's framework detection at all. Any language that produces a container that starts an HTTP server and listens on the right port qualifies.
Does this replace the need for a separate database host? No. Vercel containers are meant to stay stateless. Postgres, object storage, caches, and queues still live outside the container, through Vercel's storage marketplace integrations or an external provider.
Is this a good fit for a queue worker or scheduled job? Generally no. Function duration limits and scale-to-zero behavior make Vercel containers a poor match for processes that need to run continuously or hold persistent in-memory state. A dedicated worker platform, Cloud Run jobs, or a VPS fits that workload better.
This release is the first real signal that backend hosting decisions for B2B and product websites are changing shape. The container packages the application. The decision that still matters is whether a stateless, request-driven, frontend-adjacent runtime model is the right one for what that backend actually does.
Let me know in the comments if you have questions, and subscribe for more practical development guides.
Thanks, Matija