Vercel Routing Middleware Now Supports Python: Works with FastAPI, Flask, and Django

Vercel's Routing Middleware now officially supports Python. This means developers using Python frameworks like FastAPI, Flask, and Django can now insert an independent layer of processing logic before requests reach the main application, allowing them to rewrite, redirect, or directly return responses.

Middleware Runs Before the Application

Unlike traditional in-framework middleware, Vercel's routing middleware is a standalone ASGI or WSGI application. It executes before requests enter the main application, making it ideal for handling cross-application common logic such as legacy path migration, API version header injection, and canary traffic splitting.

This "front-intercept" positioning brings a practical benefit: middleware code is decoupled from business code, and the main application doesn't need to modify framework configuration for routing-level rules. For teams with multiple frameworks, the same middleware approach can be reused across different tech stacks.

ASGI and WSGI are two levels of server-application interface standards in the Python web ecosystem. WSGI (Web Server Gateway Interface, PEP 3333) is the synchronous traditional standard, which Django and Flask are built on by default; ASGI (Asynchronous Server Gateway Interface) is the asynchronous evolution that supports async/await, WebSocket, and long connections, adopted by FastAPI and Starlette. Both are essentially conventions for how application objects are called by servers: a WSGI application is a callable object app(environ, start_response), while an ASGI application is async def app(scope, receive, send). Vercel routing middleware running as a standalone ASGI/WSGI application means it doesn't depend on the main application framework's request object—as long as it conforms to the interface convention, it can be uniformly mounted in front of different frameworks like FastAPI, Flask, and Django. This is also the technical prerequisite for its cross-stack reusability.

Configuration: Pointing vercel.toml to the Entry Point

To enable it, specify the entry file via the proxy field in vercel.toml:

[proxy]
entrypoint = "proxy:proxy"

Here, proxy:proxy follows the module-name-plus-object-name reference format, pointing to the middleware instance you've written. The configuration itself is lightweight; the actual logic is all written in Python files.

For dependency management, the middleware has its own dependency group. The official requirement is to add packages imported by the middleware to the vercel.proxy dependency group in pyproject.toml. For example, you can install the official toolkit via uv add --group vercel.proxy vercel-proxy. This isolation design prevents middleware dependencies from polluting main application dependencies—the middleware only needs the few packages it actually uses, benefiting both cold start and build size.

Dependency groups are a standard feature of pyproject.toml introduced by PEP 735, allowing dependencies to be divided into named groups such as development, testing, and deployment under [dependency-groups], installed by tools like uv on a per-group basis. It's similar to optional-dependencies but with clearer semantics: the latter is for package users to install additional features on demand, while dependency groups are for the project's own different runtime environments. Putting middleware dependencies in the vercel.proxy group means only that group is installed during build, and main application dependencies won't be pulled into the middleware's build artifacts, thereby reducing cold start size and avoiding version conflicts.

Using the Proxy Class to Route Requests by Path

The official vercel-proxy package wraps a Proxy application that registers handler functions by path in a decorator style. The following example permanently redirects old blog paths to new ones:

from urllib.parse import quote
from vercel.proxy import ContinueResponse, Proxy, RedirectResponse, Request, Response

proxy = Proxy()

@proxy.route("/old-blog/{slug}")
def old_blog(request: Request) -> Response:
    slug = quote(request.path_params["slug"])
    return RedirectResponse(f"/blog/{slug}", status_code=308)

Path parameters are read via request.path_params, and return values use the response types provided by the framework. The 308 status code indicates a permanent redirect that preserves the request method, making it suitable for site structure migration.

Modifying Request Headers Before Passing Through

A more common use of middleware is "modify then pass through." ContinueResponse allows you to append or override request headers while preserving the original request, then hand it off to the main application for further processing:

@proxy.route("/api/{path:path}")
def api(request: Request) -> Response:
    return ContinueResponse(request_headers={"x-api-version": "2"})

This code injects the x-api-version: 2 header into all requests starting with /api/. Note that the wildcard pattern {path:path} can match multi-level paths, making it suitable for batch rules on API prefixes. For requests that don't match any route, the middleware passes them through to the main application as-is without blocking.

The difference between 308 and 301 deserves separate mention: both are permanent redirects, and browsers and search engines will cache them and update their indexes. The difference is that 301 allows clients to change POST to GET, while 308 explicitly mandates preserving the original request method and body. For APIs and form submissions, using 301 may cause the method to be rewritten and the request body lost; 308 ensures semantics remain unchanged after migration. The trade-off is that 308 is relatively newer, and extremely old clients may not recognize it. So for pure GET page migrations, 301 is fine, but when non-GET methods are involved, prefer 308.

Suitable Scenarios

In terms of capability boundaries, this middleware excels at three types of tasks: path-level redirection and rewriting, unified request header injection, and path-based routing decisions. It's not suitable for heavyweight business logic—running independently means it doesn't have access to the main application's runtime context, nor should it handle time-consuming operations like database queries.

For teams already deploying Python applications on Vercel, this update fills the control gap "before the application layer." Previously, such requirements often meant writing middleware at the framework level or relying on the platform's rewrite rules; now they can be expressed uniformly in familiar Python code and reused across frameworks.

For complete parameters and response types, the official Routing Middleware Python reference documentation is available.

One-line Summary

Vercel routing middleware supports Python, enabling unified request handling in front of FastAPI/Flask/Django.

Paragraph Summary

Vercel's routing middleware now officially supports Python, allowing developers to insert a standalone ASGI or WSGI application before requests reach the main application, enabling request rewriting, redirection, header injection, or direct responses. It's enabled by specifying an entry point in vercel.toml's proxy.entrypoint, with dependencies isolated in the vercel.proxy group in pyproject.toml. The official vercel-proxy package provides a Proxy class that registers handler functions by path using decorators, supporting path parameters and wildcard matching; ContinueResponse can rewrite request headers while preserving the original request before passing through, and unmatched requests are passed through as-is. This middleware is suitable for lightweight front logic such as path migration, API version header injection, and canary traffic splitting, but not for heavyweight operations like database queries.