Vercel adds routing rules to Python projects, enabling rewrites and headers without redeploys

Vercel has added routing rules to Python projects, letting applications built with frameworks such as FastAPI, Django and Flask set response headers and rewrite incoming requests at the CDN. According to the Vercel blog, the rules are evaluated before a request reaches the application, so a change takes effect immediately across all regions without a new deployment.

What the rules cover

Two capabilities are included: setting response headers and rewriting requests to internal paths. Vercel's worked example uses a FastAPI app that defines a /new route returning a JSON message. A routing rule then maps /old to /new, so requests for the old path are served by the new handler while the application code stays untouched.

Because evaluation happens in the Vercel CDN rather than inside the Python process, published rules apply instantly in every region. Published rulesets are also versioned: a previous version can be restored from the History tab in the project dashboard, giving teams a rollback path if a rule misbehaves.

Three ways to manage rules

Rules can be created and published from three surfaces. The first is the CDN tab in the project dashboard, where rewrites are configured through the interface. The second is the Vercel CLI, which Vercel says should be updated to the latest version before use. The CLI separates staging from publishing:

• vercel routes add --ai "Rewrite /old to /new" --yes stages a rewrite, with the --ai flag accepting a natural-language description of the rule.
• vercel routes list --diff reviews the staged changes.
• vercel routes publish pushes them to production.

The third surface is Python itself. The vercel SDK wraps Vercel's REST API, so routing can be scripted from the same language as the application. A RewriteRoute object carrying a name, source and destination is passed to project_routes.add_route to stage the rule, and update_route_version with the promote action publishes it, mirroring the CLI's stage-then-publish flow.

How this relates to vercel.

Rewrites can still be declared in vercel., where they belong to a specific deployment and change only when that deployment changes. The new project-level rules live outside any individual deployment, and Vercel says they are evaluated before a deployment's own routes. The practical consequence is precedence: when a published project rule and a vercel. rewrite target the same path, the project rule wins. Vercel frames the two as fitting different workflows, with vercel. keeping routing tied to the deployment and project rules operating independently of it.

Why it matters

Changing routing behaviour for a running service has traditionally meant editing code or configuration and shipping a new build. On a deployment-centric platform, that couples operational tweaks, such as bridging a renamed endpoint or adjusting a response header, to the full release pipeline. Evaluating these rules at the CDN shortens that loop to a single publish command, applies the change globally at once, and adds versioned rollback for safety.

For Python teams, the SDK matters as much as the CLI: routing becomes automatable from the language the application is already written in, whether that means scripting a batch of rewrites during a URL migration or managing headers programmatically. The --ai flag, which turns a plain-language instruction into a staged rule, lowers the barrier further. The feature is available now, with the CLI requiring an update to the latest version.