Python on Vercel is GA, but its Next.js glue is still Beta

Python on Vercel was announced as generally available on October 15, 2026, but the feature that puts a FastAPI backend beside a Next.js frontend, Vercel Services, is still labelled Beta in its docs. This guide covers what the GA includes, which limits decide whether your API fits, and when you should keep it elsewhere.

We should say where we stand. Creuto has not deployed a production Python workload on Vercel. We build Next.js frontends and Python AI/ML services, and we run AWS, Docker, Kubernetes and serverless setups for clients, so this is a reading of Vercel's documentation, checked against what we know of those stacks. Vercel sells the platform, and almost every source below is Vercel's own. Limits are stated as read on 2026-10-20.

Python on Vercel is GA, but Services, Daemons and large functions are not

The GA announcement covers the Python runtime itself. Vercel says it reads your dependency files, including those managed by uv, and detects FastAPI, Flask, Django and FastHTML, then runs the app on Fluid compute. The Python runtime docs describe ASGI and WSGI applications run as Vercel Functions, with Python 3.12 as the default and 3.13 and 3.14 available.

The pieces around that runtime are labelled differently. The Services page carries an availability note reading "Services (Beta) are available on all plans". The Daemons page says "Daemons (Public Beta)", and the limits page marks large functions and the 30-minute extended duration as Beta.

That matters because the GA post's pitch for full-stack projects leans on Services: running vercel dev starts both parts together, and shared previews let you test backend changes with the frontend that uses them. The runtime is GA. The colocation workflow is, by Vercel's own labels, not yet. A beta label is not a reason to avoid it, but it is a reason to pilot before you move a revenue-bearing API.

What the 150,000 teams figure does and does not tell you

In a companion post, Vercel states that 150,000 teams run Python backends on Vercel, including engineers at OpenAI, Polymarket and Exa. It is Vercel's count and the post does not define "run" or give a time window, so read it as evidence of adoption, not of fit for your workload.

One trap: the same post also says that 5,000 teams have shipped 150,000 container deployments. The two figures share a number and measure different things. If you quote either, quote it with its subject.

The limits that decide whether your Python API fits

Most migration surprises come from limits, not features. These are the figures from Vercel's Functions limits page (last updated 2026-08-24 on the page, read 2026-10-20) and the Python runtime page.

Limit	Value on Vercel Functions	What it means for a FastAPI backend
Maximum duration	Hobby 300s. Pro and Enterprise 300s default, 800s maximum, 1,800s extended maximum in Beta	A request that runs past the limit returns a 504; longer work needs Workflows, Queues or a Daemon
Memory	Hobby 2 GB and 1 vCPU. Pro and Enterprise up to 4 GB and 2 vCPU	Loading a large model or dataset per instance can hit this first
Bundle size	500 MB uncompressed for Python; up to 5 GB with large functions (Beta)	Python has no automatic tree-shaking, so trim dependencies yourself
Request and response body	4.5 MB maximum	File uploads and large exports need object storage, not the function body
File descriptors	1,024 shared across concurrent executions, including the runtime's own	Pool database connections and close sockets
Default region	A single region, iad1, unless you change it; multiple regions on Pro and Enterprise	Place the function near your database

Cold starts are the other question teams ask, and here we have nothing to quote. Vercel says Fluid compute applies automatic bytecode optimization and function pre-warming on production deployments, and the Python runtime page says Vercel compiles Python source into bytecode and includes the .pyc files in the bundle when space allows. None of the pages we read gave a Python cold-start figure, so we are not publishing one and we are not comparing against Lambda or any other host. Measure your own endpoint with your own dependencies.

How colocating a FastAPI backend with Next.js works in Services

Per the Services docs, a service is an independently built unit within your project, and all services share one deployment. A Next.js frontend at the root and a FastAPI backend under its own directory is the example the docs use. The configuration is a vercel.json with a services block and rewrites:

{
  "services": {
    "my_frontend": { "root": "frontend/" },
    "my_backend": { "root": "backend/", "entrypoint": "main:app" }
  },
  "rewrites": [
    { "source": "/api/(.*)", "destination": { "service": "my_backend" } },
    { "source": "/(.*)", "destination": { "service": "my_frontend" } }
  ]
}

Three behaviours are worth knowing before you adopt it. A service is internal by default and not routable from the internet unless a top-level rewrite exposes it, and one service can call another over a binding. Services also remain, in the words of Vercel's own hosting guide, separate applications communicating across a service boundary, with no implied shared process or memory. And the preview is only as isolated as its data: Vercel's Python starter guide warns that deploying both apps together does not isolate their database, so previews that share a database let a schema change affect older deployments.

On the bill, CPU stops during I/O but memory does not

Services are billed the same as Vercel Functions: Active CPU, provisioned memory and invocations, plus a charge for service-to-service requests over bindings, with the first 1,000,000 included on Hobby. The pricing page says Active CPU is billed only while your code is running, and pauses while it waits on I/O.

The same page adds the half that blog summaries leave out: provisioned memory keeps billing while requests wait on I/O, until the last in-flight request completes. An API that spends most of its time waiting on a database or a model call pays less CPU than a busy-loop would, but it is not free while it waits. We have not priced a workload against AWS, so we make no cost comparison. What you can do is take your current peak memory and request time and run them through the published regional rates.

Delphi's move saved onboarding time, not compute

Vercel's lead case study is Delphi, which moved its Python backend from AWS ECS to Vercel; with ten engineers and no dedicated infrastructure role, it reports more than 100 production deploys a day behind feature flags. That is a vendor-published customer story, so weigh it accordingly.

The detail that is useful to you is the reason. Delphi's backend ran on ECS, Docker Desktop and local databases, and getting a new engineer to their first deploy took a full day of environment setup. The story says Delphi could have fixed that without leaving AWS, but that would have meant designing and owning the infrastructure, which the team did not want. It also says the move depended on Vercel Workflows and Queues for its long-running work and background jobs.

Our reading, and it is ours: Delphi bought less infrastructure ownership, and paid for it with a deeper dependence on Vercel's own primitives. That trade suits a ten-person team with no platform engineer. It may not suit a company that already runs a platform team and a compliance regime on AWS.

When keeping your Python service separate is the right call

The strongest argument for staying put comes from Vercel's own hosting guide: adding a new frontend is often insufficient reason to relocate an otherwise suitable Python API, and independent deployments suit a backend that serves several clients or has its own release process. We agree with it, and it points to the cases below.

• More than one client. If a mobile app, partners or webhooks call the API directly, it needs its own public surface and release cadence. Services can expose a backend, but then you are running an independent API that happens to sit in a frontend repository.
• Long or stateful work. Past 800 seconds you are in Beta territory, and Vercel points unlimited-duration work to Workflows. Daemons, the worker option, run only in production during the beta, with no preview-deployment support. The Daemons docs give a 30-second default shutdown grace after SIGTERM while Vercel's Functions, containers and Daemons guide says 10 seconds. Test the figure you rely on.
• Heavy dependencies. A 500 MB bundle ceiling, 4 GB of memory and no tree-shaking rule out many ML-heavy services unless you accept large functions in Beta or put the heavy step in a separate worker.
• Data location. The regional pricing table lists 19 regions, from Cape Town to Tokyo and including Mumbai, and none in the Gulf. If your data must stay in the UAE, check the service availability gap in the UAE cloud region and Vercel's region list before you plan around either.
• Realtime. Vercel says its Functions can serve WebSockets, currently in beta, and that a reconnect can reach a different instance, so session state must live outside process memory.

If edge Python is what you are weighing, we covered Cloudflare Python Workers and FastAPI separately. If the alternative to ECS is Lambda, our note on the AWS Lambda 90 minute timeout is the place to start, and its advice is to read the conditions first.

A decision framework we would use, untested on Vercel by us

This table is our reasoning from the sources above, not a benchmark. It assumes you are choosing for a Next.js product with a Python API behind it.

Your situation	Our lean	Why
Python API used only by this Next.js app, requests well under a minute, payloads under 4.5 MB	Pilot colocating on Vercel	Fits the limits, and one preview covers both halves
API also serves mobile apps, partners or webhooks	Keep a separate service	Its release cycle should not follow the frontend's
Jobs that run for minutes or hours, or poll queues	Keep workers where they are, or pilot Workflows or Daemons knowing both are young	Beta limits, and Daemons have no preview support
Large ML dependencies, GPU, or models loaded into memory	Keep on AWS or a dedicated compute service	500 MB bundle and 4 GB ceilings
Data pinned to a region or cloud Vercel does not list	Keep the API next to the data	Latency and residency come before deployment convenience
Small team, no platform engineer, an environment that takes a day to set up	Colocating is worth a serious pilot	This is the profile of Delphi's reported gain

Treat any row that depends on a Beta feature as a pilot, not a migration. The decision that costs least to get wrong is the next one: pick the single endpoint with your largest realistic input, deploy it to a Vercel preview, and record peak memory, duration and first-request latency against the limits table. If it clears them, the web app development question becomes how to stage the rest, and the serverless architecture and DevOps and cloud engineering work is deciding what stays on AWS.