The right platform for a Docker app depends on the workload inside the container, not the container itself. A stateless API, an always-on worker, and a model server package identically and run best in different places. This guide maps five common workloads to their appropriate places, including those that don't fit here.
One disclosure before the list: Vercel is our platform, and it appears where the workload genuinely matches, stateless HTTP services. For the workloads it doesn't serve, this page says so plainly and points to the category that does.
Copy link to heading1. Stateless HTTP APIs and web services
The workload: a server that takes a request, returns a response, and keeps nothing in between. REST and GraphQL APIs, server-rendered apps, webhooks, backends-for-frontends. State lives in a database or cache, not in the container.
Where it runs best: this is the workload Vercel's container support is built for. Add a Dockerfile.vercel, and every commit builds the image, stores it in Vercel Container Registry, and serves it on Fluid compute. Scaling is automatic in both directions, including to zero after idle, cold starts stay fast because images are stored as precompiled snapshots, and Active CPU pricing bills the compute your code uses rather than provisioned instances. Preview deployments come with every commit, and because multiple services deploy from one project, a single PR previews the frontend and its backend together instead of pointing UI changes at a stale staging API.
The boundary to check: the container must serve HTTP on PORT and tolerate scale-to-zero. If it does, this category migrates cleanly; the Fly.io and Railway guides walk through it.
Copy link to heading2. Always-on workers and queue consumers
The workload: a process that runs continuously outside the request cycle. Queue consumers, stream processors, schedulers, bots holding persistent connections.
Where it runs best: a platform built around long-lived processes. Container platforms such as Fly.io and Railway run services that stay up regardless of traffic, which is what this workload requires by definition.
Not on Vercel, mostly. Containers on Vercel are request-driven, so a worker that must run continuously doesn't fit. Two partial exceptions: work that runs on a schedule maps to cron jobs invoking an endpoint, and work triggered by events maps to an HTTP handler called by the event source. If the worker can be restructured around invocation, it moves; if it genuinely must hold a process open, host it where processes stay open.
Copy link to heading3. Apps that write to an attached disk
The workload: anything that expects a persistent local filesystem. Self-hosted tools that store data on disk, databases running inside the container, upload handling that writes locally, and SQLite-backed apps.
Where it runs best: a platform with attached volumes, which Fly.io and Railway both provide, or a rethink. Many disk-writing apps are one refactor away from category 1: uploads move to blob storage, data moves to a managed database, and the container becomes stateless.
Not on Vercel today. There is no persistent disk; anything written locally exists only for the life of the instance. If the disk dependency is removable, remove it, and this becomes category 1. If it isn't, choose a volume-backed platform.
Copy link to heading4. GPU inference and ML workloads
The workload: containers that serve model inference or run training, needing GPU access and often large images and long startup.
Where it runs best: GPU-focused infrastructure providers, which provision the accelerators this workload is defined by. General-purpose container platforms, Vercel included, don't attach GPUs to containers.
The question worth asking first: whether you need to host the model at all. If the container exists to serve a model an API provider already hosts, a gateway in front of managed inference, such as AI Gateway, removes the GPU problem entirely, and the application around it is category 1.
Copy link to heading5. Multi-region apps with data locality
The workload: systems that need application code and its state running close to users in many regions at once, with region-aware placement of both.
Where it runs best: platforms designed around regional placement of compute and storage together, which is Fly.io's specialty, paired with a database that replicates across regions.
The distinction that decides it: if the requirement is global low-latency for stateless serving, that's not this category; Vercel's network already routes requests globally, and the container scales with traffic, which covers most "we have users everywhere" cases. This category is specifically about state pinned near users in multiple regions, and that's a different architecture than Vercel containers offer.
Copy link to headingThe short version
Most production systems mix categories, and the common split is the healthiest one: the web-facing services run on Vercel, the workers run on a process platform, and they share backing services. Migration doesn't have to be all-or-nothing.
Copy link to headingFrequently asked questions
Copy link to headingCan Vercel host any Docker app?
No. Vercel runs containers as stateless HTTP services: the image must serve HTTP on the PORT environment variable and keep no local state between requests. Workers, disk-dependent apps, and GPU workloads belong on platforms built for them.
Copy link to headingWhat if my app mixes workloads?
Split it. The web-facing services move to Vercel, the always-on pieces stay on a process platform, and both share the same databases and caches. This hybrid is common and doesn't require a single-platform decision.
Copy link to headingIs scale-to-zero safe for a production API?
For most APIs, yes. Instances scale down after five minutes without production traffic, and container images are stored as precompiled snapshots in Vercel Container Registry, which keeps cold starts fast when traffic returns. Latency-critical paths should be load-tested on a preview deployment before cutover.
Copy link to headingDo I need Kubernetes for any of this?
Not for these five workloads at typical scale. Kubernetes earns its complexity when you need control that managed platforms don't offer, such as custom scheduling, networking, and placement policies. If a managed platform fits the workload, it's the shorter path.
Copy link to headingRelated resources
Does Vercel support Docker deployments? in the Knowledge Base
Migrate to Vercel from Fly.io, Railway, Render, or Google Cloud Run
Run any Dockerfile on Vercel on the Vercel blog
Docs: Container images and Vercel Container Registry