Skip to content
Dashboard

Where should you host a Python API?

Content Engineer

Host your Python API where its dependencies, request duration, and data access fit. Vercel Functions is an option for supported Python web applications alongside a frontend. For an existing application, test representative endpoints with realistic inputs to establish the memory and execution time the host must provide.

Some of the work behind an API can run elsewhere. If one operation needs more resources than the API host provides, the API can submit it to a worker and expose its status or result. This lets you choose compute for that operation while keeping the rest of the API in an environment that already suits it.

Copy link to headingWhich hosts fit your Python API?

Start with the application you have. If your API reads records and returns a response, its operating requirements differ from those of a process that continuously polls for work. Existing databases or deployment processes may narrow your options before framework support does. Vercel publishes this article; this shortlist groups options by requirement, and several may fit your API.

Your requirement

Option to evaluate

What to establish before choosing

A supported Python HTTP backend, possibly beside a frontend

Vercel Functions, with Services for a combined project

Check framework support and Function limits against the application's dependencies and execution needs.

A conventional web service with a continuous worker or attached filesystem

Render web services, background workers, and persistent disks

Deploy the API and worker as separate services, and account for a disk's scaling restrictions.

An HTTP API and batch work in Google Cloud

Cloud Run services and jobs

Separate HTTP serving from work that completes and exits, and consider the Google Cloud services the application uses.

An API that submits GPU computation

A GPU worker, such as a Modal function

Size the worker for the computation; the API that accepts the request can use different compute.

Render's background workers run continuously and generally poll a queue. They don't receive incoming network traffic, so the HTTP API belongs in a web service. This arrangement fits an application whose worker already maintains a polling loop. Whether the API also needs an attached disk is a separate storage decision.

Cloud Run supports containerized HTTP services and jobs. Use a service for HTTP traffic and a job for work that finishes and exits. It also offers worker pools, and Python applications can deploy from source. Its integration with other Google Cloud services makes it an option to evaluate when your database or existing operations already reside there. Familiar infrastructure can reduce the changes involved in moving an API, but you still need to check the chosen execution mode.

Copy link to headingWhat should you check before deploying?

Getting the application to build only establishes part of the fit. Exercise representative endpoints with realistic inputs, then compare their behavior with the environment you intend to use.

Copy link to headingConfirm framework and dependency support

Check the application's Python version and web interface, then identify packages that depend on native libraries or executables. For a document-processing endpoint, you might need a system program as well as an installable Python package. Installing the package alone may leave that endpoint unable to run.

Vercel's Python runtime supports ASGI and WSGI applications and detects supported frameworks including FastAPI, Flask, and Django. Framework support gives you a deployment path; check additional dependencies separately.

Container images can package application code with the system dependencies it needs. Vercel's Container Runtime, currently in beta, runs OCI container images as Functions. That changes packaging, while execution remains subject to Function constraints. Choosing a Docker image alone doesn't establish whether a process can run continuously.

Copy link to headingMeasure memory and execution duration

Test with the largest inputs you intend to accept. Loading a model or expanding a compressed dataset can consume much more memory than calling the same endpoint with a small test fixture. Measure peak memory as well as elapsed time, and leave room for the variation you observe.

For Vercel, compare those measurements with the current Function limits. Duration, memory, and packaging constraints depend on the runtime and plan. Python Functions support response streaming, which lets the client receive output as it becomes available, but sending an early chunk doesn't remove those constraints.

If an operation exceeds the chosen environment's limits, reduce the work per execution or place that operation on suitable compute. Increasing the HTTP timeout won't resolve an insufficient memory allocation.

Copy link to headingSeparate temporary files from persistent data

Trace every local file write. Scratch files that the same request creates and consumes have different requirements from uploaded documents that users must retrieve next week. For persistent data, choose storage with the lifetime and access pattern the application requires. Shared object storage or a database can let separate API instances retrieve the same data without depending on another instance's local files.

Render supports attached persistent disks on paid web services, private services, and background workers. Each disk is accessible to one service instance, and attaching it prevents that service from scaling to multiple instances. With a disk, you can preserve a filesystem-based application design, but that restriction needs to fit your traffic and recovery plan. If several instances must access the same records, reassess the storage design before choosing the host around a local directory.

Copy link to headingPut the API near the data it uses

Consider the whole request path. If an endpoint makes several sequential database queries, network delay between the API and database accumulates before the response reaches the user. Start by evaluating API placement near the database, then measure the user-facing request from the locations you serve.

Region names alone don't establish connectivity. Confirm that the proposed deployment can reach the database through its network restrictions and authenticate with the intended credentials. Data-location requirements may also constrain placement. These checks can favor keeping an established backend near its data even when the frontend moves to another host.

Copy link to headingShould Python and Next.js share a deployment?

Deploying a frontend and API together suits a team that changes both as one application, because it lets the team coordinate an interface change with the endpoint it needs. Independent deployments suit a backend that serves several clients or has its own release process. Adding a new frontend is often insufficient reason to relocate an otherwise suitable Python API.

Vercel Services combines frontends and backends in one project. Each component builds separately, and components can use a shared domain. They remain separate applications communicating across a service boundary, with no implied shared process or memory.

The eve Agent with Python template demonstrates this arrangement. TypeScript tools let the eve agent call a FastAPI backend that the Next.js interface also uses. All three deploy through Services. The backend has no public route; server-side components reach it through service bindings. The template uses a shared password and shared task list, so an application requiring per-user data isolation needs a different access model.

For an existing backend on another host, define how the frontend will call it and how the API will authorize each request. Configure cross-origin resource sharing (CORS) for browser calls to another origin. Calls through the frontend's server need a way to carry the user's identity without trusting arbitrary client-supplied values. Keep credentials intended for servers out of browser code.

The FastAPI deployment guide provides setup instructions and links to Python and Next.js starters once you've established that the runtime fits.

Copy link to headingHow should the API delegate expensive work?

Consider an image-analysis application where users upload a batch and return later for the results. In a proposed design, the API validates the submission and stores a job record before returning a job identifier. The job runs in a worker that processes the saved input and records the result. The interface retrieves status through the API, so it can resume showing progress after the user closes and reopens the page.

If the computation requires a GPU, Modal functions can allocate GPU hardware. Modal is one worker option to evaluate against the model's requirements. The API can remain on the host that suits its HTTP requests and data access. Moving compute behind a job boundary also requires explicit handling for failed or repeated attempts; saving a job identifier alone doesn't make execution reliable.

Existing Celery applications have more than one deployment model. Vercel's Celery integration uses private, queue-triggered Functions with its Python runtime and Vercel Queues, which is in beta. This integration doesn't require a continuously running Celery worker process. Evaluate the task's resource needs against the worker environment regardless of how the queue invokes it. Matching backend workloads to an execution model separates worker and API hosting decisions.

Copy link to headingWhat can change the hosting decision?

Protocol requirements can affect hosting, so check current support before moving an application. Vercel Functions can serve WebSockets, currently in beta, including through Python frameworks. Even though each connection stays on one instance for its lifetime, a reconnect can reach another instance. Store session data outside process memory when the application needs to recover it after a disconnect.

You may need a virtual machine if the application requires direct administration of the underlying host. For an API coupled to a persistent local filesystem, scaling to multiple instances may require a storage change. Neither requirement follows from choosing Python itself.

Before committing to a migration, deploy a representative endpoint in the candidate environment and exercise its most demanding input. Include a restart or reconnect where the application depends on state, and confirm that the endpoint can reach production-like data. Those results should decide whether to move the whole API, change one dependency, or separate an expensive operation.

Copy link to headingFrequently asked questions

Copy link to headingCan I host FastAPI on Vercel?

Yes. Vercel detects FastAPI applications and runs them as Vercel Functions using the Python runtime. Before migrating an existing API, check its dependencies, memory use, and execution duration against the current Function limits.

Copy link to headingDoes a Python API need Docker?

No. You can deploy a Python API with a host's supported Python runtime without maintaining a Docker image. Container packaging is useful when you need to include system dependencies or control the application environment, but the host still determines the execution limits and process lifetime.

Copy link to headingShould the API and database be in the same region?

Placing an API near its database is a useful starting point when requests make frequent database calls. Measure the complete request path, because user location and the number of sequential queries also affect response time. Confirm network access and data-location requirements before choosing the region.

Copy link to headingCan my frontend and Python API use different hosts?

Yes. HTTP lets a frontend call a Python API even when the applications deploy independently. Define authentication and authorization across that boundary, and configure cross-origin access for browser calls to another origin. Existing data access or a separate backend release process can be good reasons to keep the API where it is.

More Backends articles

Ready to deploy?