Ricardo Gonzalez

[python-runtime] Python WebSockets Support (#15993) - Vendor `wsproto` 1.3.2 so uvicorn can handle WebSocket upgrades - Extend `ASGIMiddleware` to handle `websocket` scope (previously only `http`) - End request at `websocket.accept` to match Node.js detached upgrade flow --------- Co-authored-by: Fantix King <fantix.king@gmail.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

[routing-utils] request.path transforms schema (#16653) Implements `request.path` transforms: - **Routing utils:** Adds schema/types, validation, and compilation from high-level `:param` syntax to low-level `$1` captures. - **Config SDK:** Adds `requestPath` support to `router.rewrite()`. - **CLI:** Adds AI generation/edit support, inspection, previews, interactive editing, and env handling. ```json { "source": "/api/:path*", "destination": { "type": "service", "service": "my_backend", "path": "/:path*" }, "transforms": [ { "type": "request.path", "op": "set", "args": "/:path*" } ] } ```

[python] pyproject.toml subscribers vc dev (#16728) Adds `vc dev` support for running subscribers defined in `pyproject.toml` as sidecars to the main builder so a FastAPI app with Celery workers runs the full enqueue -> broker -> worker loop locally with a single vc dev. ```toml [tool.vercel] entrypoint = "main:app" # FastAPI [tool.vercel.subscribers.celery-worker] entrypoint = "worker:app" # Celery topics = ["celery"] ``` **How** * New optional builder hook getDevSidecars() in @vercel/build-utils; @vercel/python implements it by parsing `[[tool.vercel.subscribers]]` * The CLI runs sidecars through a dedicated ServicesOrchestrator + the existing dev QueueBroker * App and subscribers share one managed .venv per workspace; concurrent startups dedupe venv creation and installs --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

configurable routing middleware in `vercel.json` (#17215) Enables configuration of routing middleware through `proxy` in `vercel.json`: ```json { "proxy": { "entrypoint": "proxy.ts" } } ``` ```javascript export default function proxy(request) { return new Response('proxy'); } ``` Explicitly configured `proxy` overrides the default `middleware.ts` builder. It also uses the nodejs runtime as opposed to implicitly built `middleware.ts` which defaults to the edge runtime

[@vercel/backends] server.ts devserver (#16772) Implements proper `vc dev` support for Node preset `server.ts` servers which starts a persistent devserver reused across requests --------- Co-authored-by: Jeff See <jeffsee.55@gmail.com>

[python] support declaring workflows in `pyproject.toml` (#16983) Adds support for declaring workflows in `[[tool.vercel.workflows]]` in `pyproject.toml` ```toml [[tool.vercel.workflows]] entrypoint = "flows:wf" ``` **Note:** We currently only support a single workflow entrypoint. This is because we don't yet have a way to namespace workflows into different topics: see https://github.com/vercel/vercel-py/pull/162

[python] `pyproject.toml` subscribers (#16655) Support running async subscriber workloads alongside the main Python API application, e.g. FastAPI + Celery by declaring `subscribers` in `pyproject.toml` ```toml [tool.vercel.subscribers.celery-worker] entrypoint = "worker:app" topics = ["celery"] ```

[go] support websockets upgrades (#16733) Adds WebSocket support for standalone Go servers. Go’s ReverseProxy already upgrades and tunnels WebSocket connections. However, ServeHTTP does not return until the connection closes, which keeps the IPC request open for the WebSocket’s entire lifetime. This change ends the IPC request after the 101 Switching Protocols response is successfully flushed, while ReverseProxy continues tunneling WebSocket traffic. The end message is sent exactly once, and regular HTTP requests are unaffected. Go’s standard library remains responsible for validating and managing the upgrade: [reverseproxy.go](https://github.com/golang/go/blob/go1.25.5/src/net/http/httputil/reverseproxy.go#L750-L815).

[go] Fix vc dev for Go standalone server mode (#16603) `vc dev` returned 404 for every request in Go standalone server mode (framework: `go`), and once matched, spawned a new `go run` per request making every response take 2–3s. **Fixes:** 1. **CLI build matching**: the Go framework preset's `useRuntime` src (`index.go`) is a placeholder that may not exist, so no build match was created. `vc dev` now matches the real entrypoint candidates (`main.go`, `cmd/api/main.go`, `cmd/server/main.go`), mirroring the Python carve-out. 2. **Routing**: `@vercel/go` exported the default `shouldServe`, which only serves the entrypoint path. In standalone mode the user's server handles its own routing, so all paths are now served. 3. **Performance**: `startStandaloneDevServer` spawned a fresh `go run` per request and waited a fixed 2s before proxying (cold compiles >2s got killed → `FUNCTION_INVOCATION_FAILED`). It now keeps a persistent dev server across requests, polls the port until ready, and kills the process group on CLI exit. Warm requests drop from 2–3s to ~3–20ms; cold start is a one-time compile. **Notes:** In a following PR, it would be worth switching the Go preset's `useRuntime` src to `<detect>` following Python's implementation

[services] compose `pyproject.toml` subscribers into `services` (#16977) Add support for composing subscriber services defined in `pyproject.toml` into a `services` build: ```toml # FastAPI [tool.vercel] entrypoint = "main:app" # Celery [[tool.vercel.subscribers]] entrypoint = "worker:app" topics = ["a"] ``` ```json { "services": { "frontend": { ... }, "backend": { // produces both FastAPI and Celery "root": "backend/", "entrypoint": "pyproject.toml" } } } ```