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](https://vercel.com/kb/guide/does-vercel-support-docker-deployments). For the workloads it doesn't serve, this page says so plainly and points to the category that does.

## [Copy link to heading](#1.-stateless-http-apis-and-web-services)1\. 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](/blog/dockerfile-on-vercel). 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](https://vercel.com/docs/functions/container-images), 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](http://Fly.io) and [Railway](https://vercel.com/kb/guide/migrate-railway-to-vercel) guides walk through it.

## [Copy link to heading](#2.-always-on-workers-and-queue-consumers)2\. 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](http://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](https://vercel.com/docs/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 heading](#3.-apps-that-write-to-an-attached-disk)3\. 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](http://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 heading](#4.-gpu-inference-and-ml-workloads)4\. 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](https://vercel.com/docs/ai-gateway), removes the GPU problem entirely, and the application around it is category 1.

## [Copy link to heading](#5.-multi-region-apps-with-data-locality)5\. 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](http://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 heading](#the-short-version)The short version

| Workload | Host it on |
| --- | --- |
| Stateless HTTP APIs and web services | Vercel |
| Always-on workers and queue consumers | A long-lived-process platform, or restructure around invocation |
| Apps writing to attached disks | A volume-backed platform, or remove the disk dependency |
| GPU inference and training | GPU-focused providers, or managed inference behind a gateway |
| Multi-region apps with pinned state | Region-placement platforms with replicated data |

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 heading](#frequently-asked-questions)Frequently asked questions

### [Copy link to heading](#can-vercel-host-any-docker-app)Can 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 heading](#what-if-my-app-mixes-workloads)What 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 heading](#is-scale-to-zero-safe-for-a-production-api)Is 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 heading](#do-i-need-kubernetes-for-any-of-this)Do I need Kubernetes for any of this?

Not for these five workloads at typical scale. [Kubernetes](https://vercel.com/kb/guide/vercel-kubernetes-support) 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 heading](#related-resources)Related resources

- [Does Vercel support Docker deployments?](https://vercel.com/kb/guide/does-vercel-support-docker-deployments) in the Knowledge Base

- [7 ways to use Docker containers on Vercel](https://vercel.com/i/7-ways-to-use-docker-containers-on-vercel)

- Migrate to Vercel from [Fly.io](https://vercel.com/kb/guide/migrate-fly-io-to-vercel), [Railway](https://vercel.com/kb/guide/migrate-railway-to-vercel), [Render](https://vercel.com/kb/guide/migrate-render-to-vercel), or [Google Cloud Run](https://vercel.com/kb/guide/migrate-cloud-run-to-vercel)

- [Run any Dockerfile on Vercel](/blog/dockerfile-on-vercel) on the Vercel blog

- Docs: [Container images](https://vercel.com/docs/functions/container-images) and [Vercel Container Registry](https://vercel.com/docs/container-registry)