Serverless Python runs Python code on infrastructure managed by a hosting platform. Requests or events trigger work in instances that the platform provisions, maintains, and scales. You deploy the application and its dependencies.
FastAPI, Flask, and Django apps can use this model. The main design question is whether requests can complete within the platform's limits while durable data lives outside the process. Package size, database connections, and state between requests determine how much adaptation an app needs.
Copy link to headingWhat is serverless Python?
In a function-based deployment, the platform invokes your Python handler for an HTTP request or an event such as a queued message. It initializes an execution environment when needed and may reuse that environment for later work. Some platforms also let concurrent requests share an instance.
You still write Python and declare its dependencies. The platform controls when instances start, scale, and stop, so application correctness cannot depend on the lifetime of one process.
With a conventional Python web deployment, Gunicorn or Uvicorn runs a server process that passes incoming requests to the application. Flask uses WSGI (Web Server Gateway Interface), while FastAPI uses ASGI (Asynchronous Server Gateway Interface). These interfaces define how the server and application communicate.
Vercel's native Python runtime loads the application through those interfaces, so you do not configure a separate Gunicorn or Uvicorn start command. Serverless container platforms can use a different arrangement in which your container still runs the web server.
Copy link to headingHow to tell if serverless Python fits your app
Compare the application's assumptions with these limits for Python Vercel Functions on Fluid compute and an always-on server:
An API that returns JSON from a database is a useful starting point because its durable state already lives outside the process. It still needs to fit package and execution limits and keep connection usage within the database's capacity.
Copy link to headingCheck your package size against the 500 MB limit
Python Functions have a standard limit of 500 MB uncompressed. Measure the complete bundle, including transitive dependencies, model files, and application assets. Data libraries such as pandas, Plotly, and scikit-learn can be candidates, but their names alone do not establish whether the application fits.
Large Functions raises the limit to 5 GB in public beta, and new projects are enrolled automatically. It requires Fluid compute and currently excludes Secure Compute and Static IPs. Check those requirements before relying on the larger bundle for packages such as PyTorch.
Size isn't only about packages. Vercel has no automatic tree-shaking for Python, so a bundle includes every project file reachable at build time, including tests and sample data. Listing only runtime packages in your dependency file and excluding unneeded folders with excludeFiles in vercel.json keeps the bundle small.
Copy link to headingPlan for database connections to multiply
If each function instance creates a database connection pool, scaling out also increases the potential connection count. Worker processes and replicas on an always-on host can multiply pools in the same way. Set per-process pool limits with the database's total connection capacity in mind.
For an RDS database, RDS Proxy lets application connections share a managed pool of database connections. That pool grows with demand up to its configured limit. Once capacity is exhausted, requests can wait or time out, so monitor connection usage and tune both application and proxy settings.
Copy link to headingDon't rely on data staying in memory
Vercel reuses warm instances, so a cache or a loaded model can stick around between requests. Nothing guarantees the next request lands on the same instance, though, and every new deployment starts fresh. In-memory data works best as a speedup, not something your app depends on.
Untracked background threads can stop when the instance shuts down. For work that must survive the request, record the job in a durable queue or workflow and make retries safe. Monitor failures and expiry so unfinished work can be recovered.
Copy link to headingWatch for long requests and open connections
Long batch jobs and report generation need to finish within the configured request duration. The extended duration beta allows up to 1800 seconds on Pro and Enterprise with Python 3.12, 3.13, or 3.14. Set it per function in vercel.json; durations above 800 seconds currently exclude Secure Compute and Static IPs.
If a job exceeds that window, divide it into bounded steps and persist progress between them. Extending the HTTP timeout alone does not make work recoverable after a failure.
WebSockets on Vercel are generally available with Fluid compute. Python options include FastAPI's ASGI WebSocket support. Each connection stays on the instance that accepted it and closes when it reaches the configured Function duration.
Clients need to reconnect and restore their session from durable state. If an application requires one uninterrupted process or a model that must remain loaded continuously, evaluate that lifecycle requirement separately.
Copy link to headingHow Vercel keeps serverless Python fast and efficient
Vercel's Python runtime reduces the costs that used to come with serverless, including slow cold starts, CPU billed while code sits idle, and slow builds.
Copy link to headingSkip most cold starts with Fluid compute
Cold starts occur when an instance must initialize before handling a request. Fluid compute routes work to available instances first. On Pro and Enterprise, scale-to-one also keeps the current production deployment warm if it has been invoked within the last 14 days.
Vercel reported that 99.37% of requests avoided cold starts across its platform in September 2025. That figure reflects several optimizations and does not predict the cold-start rate of an individual Python app.
Vercel also compiles Python application code and dependencies into bytecode during the build. Its benchmarks reduced cold starts for the median-sized function from 2.8 seconds to 1.3 seconds. The bundle includes only the bytecode that fits, so functions near the size limit can see smaller gains.
Copy link to headingPay for CPU only while your code is working
With Active CPU pricing, CPU billing pauses while a function waits on a database or external API. Provisioned memory remains billable until the last request in flight completes. Once all requests finish, the paused instance incurs no CPU or memory charges until the next invocation.
AI Gateway spends much of its time waiting for model responses. Vercel's first-month measurement of this Node.js service recorded about 16,000 runtime hours and 1,200 hours of active CPU work. CPU charges covered less than 8% of runtime; memory and other usage remained billable.
Copy link to headingServe more requests per instance with in-function concurrency
Fluid compute lets multiple Python invocations share one function instance. While one request waits for a database or API response, the instance can make progress on other work. This is particularly useful for applications that use asynchronous I/O.
Sharing instances can reduce the number needed for the same traffic and therefore the number of application connection pools. It does not remove the need to size pools or test how the application behaves under concurrent load.
Copy link to headingBuild faster with uv
Vercel uses uv to install dependencies during Python builds. Its rollout announcement reported builds completing 30–65% faster. Supported dependency files include pyproject.toml with an optional uv.lock, requirements.txt, or Pipfile with its corresponding Pipfile.lock.
Python 3.12 is the current default, with 3.13 and 3.14 also available. Declare your project's version in .python-version, pyproject.toml, or Pipfile.lock so it does not depend on the platform default.
Copy link to headingRun FastAPI, Flask, and Django with zero configuration
Vercel detects FastAPI and Flask from the project's dependencies. Export an app instance from a supported entry file such as app.py, main.py, or index.py so the runtime can load it.
For Django, Vercel locates manage.py and resolves the application from WSGI_APPLICATION or ASGI_APPLICATION. When STATIC_ROOT is configured, the build runs collectstatic. Standard local static-file storage is served from Vercel's CDN; django-storages uploads to the configured storage provider.
Copy link to headingHow to pair a serverless Python backend with a Next.js frontend
Many Python projects on Vercel are two apps in one, a Next.js frontend and a Python API behind it. Vercel Services deploys both from one repository, and a few routing details decide whether requests reach the right place.
Copy link to headingConnect both apps with Vercel Services
Vercel Services, in beta on all plans, can deploy Next.js from frontend/ and FastAPI from backend/ using a root vercel.json. Top-level rewrites route paths such as /api/... to the backend and other paths to the frontend.
Browser requests through that shared origin do not need cross-origin resource sharing (CORS) configuration.
For private calls from Next.js server code, configure a service binding. Choose an environment variable such as BACKEND_URL and Vercel injects the target URL. Preview calls stay within the matching preview deployment. The Academy lesson walks through the setup.
Copy link to headingInclude the route prefix in your FastAPI paths
With a Services rewrite that targets the backend service, FastAPI receives the original path. For example, /api/items still arrives as /api/items, so declare @app.get("/api/items"). An endpoint declared only as @app.get("/items") will return a 404 for that request unless you also configure a path transform.
Existing projects can still use file-based Python functions in an api/ directory. Without a detected Python framework preset, each file becomes a separate Function: api/users.py serves /api/users. When a framework preset is detected, that application handles the routes instead.
Copy link to headingHow to handle background jobs and AI calls in serverless Python
Scheduled tasks, jobs with retries, and AI calls have different execution needs. Keep work in a request when it fits the duration limit and the caller can wait. Use a queue or workflow for jobs that must run independently or recover after failures.
Copy link to headingSchedule jobs and process queued work
Cron Jobs call an HTTP endpoint on a schedule. They do not retry a failed invocation, so use the endpoint to enqueue a job when it needs independent retries.
Vercel Queues, in beta with a Python SDK, stores jobs for consumers to process. Failed deliveries can be retried until they are acknowledged or expire. Make handlers safe to repeat and monitor failures within the retention window.
The Celery integration runs workers as private queue-triggered Functions. To recover tasks after a timeout or crash, enable late acknowledgement; application exceptions still need Celery's retry configuration. Check the integration's limits before migrating existing Celery workers.
For multi-step processes, Vercel Workflow's Python SDK, currently in beta, records progress so execution can pause and resume across durable steps.
Delphi moved its Python backend from AWS ECS to Vercel. Its team of ten engineers uses Workflows for long-running agents and Queues for background jobs. The customer story reports more than 100 production deployments a day without a dedicated infrastructure role.
Copy link to headingCall large models through AI Gateway
When a model exceeds the function's package, memory, or compute limits, the Python API can call a hosted model instead. AI Gateway provides access to supported provider models through the AI SDK for Python, currently in public beta, or compatible APIs.
For the OpenAI Python client, set base_url to https://ai-gateway.vercel.sh/v1, authenticate with an AI Gateway API key, and select a supported provider/model identifier. Check the API's supported fields and model capabilities when migrating an existing integration.
Copy link to headingShip Python APIs without running servers
Start with one API endpoint and check its deployed bundle size, database connections under concurrent load, and behavior when a new instance starts. Those checks show whether the application fits the execution model and which dependencies need adjustment.
Use a Python template to try FastAPI or Flask, or import an existing project.
Copy link to headingFrequently asked questions about serverless Python
Copy link to headingIs serverless Python a good fit for machine learning workloads?
Yes, for models whose dependencies and artifacts fit the deployment limit and whose inference fits the available memory, CPU, and request duration. Measure memory after loading the model as well as bundle size and inference latency. Larger or GPU-dependent models can run on dedicated inference infrastructure that the Python API calls.
Copy link to headingDoes serverless Python support background jobs and scheduled tasks?
Yes. On Vercel, Cron Jobs invoke an endpoint on a schedule, while Queues can retry accepted jobs within their retention period. Cron does not retry failed invocations and delivery can be missed or duplicated. Make processing safe to repeat and use later runs to find outstanding work after a missed invocation.
Copy link to headingCan serverless Python handle WebSocket connections?
On Vercel, yes. WebSocket support is generally available with Fluid compute and follows the configured Function duration. Clients should reconnect after disconnection and recover session state from durable storage.
Copy link to headingWhat happens to database connections when a serverless Python function shuts down?
On Vercel, FastAPI lifespan events can initialize and close per-instance database resources, but shutdown cleanup has at most 500 milliseconds after SIGTERM. Keep teardown short and do not depend on it completing. Pool limits and idle timeouts help protect database capacity when clients disconnect unexpectedly.