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/vercel-workers] refactor queue sdk logic into `_queue/` (#16171) Keeps behavior unchanged, refactors queue SDK logic into `_queue/` to start untangling the workers runtime from the queue sdk and make it easier to move this code into the `vercel/vercel-py` repo

[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>

[@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/vercel-workers] refactor framework-specific logic into vercel-workers (#15455) Refactors specific framework-bootstrapping logic out of vercel-runtime `workers.py` into vercel-workers `_runtime.py` which exposes 2 functions that vercel-runtime calls into: * `prepare_environment(...)` * `maybe_bootstrap_worker_service_app(...)` This is a cleaner separation of concerns since vercel-runtime shouldn't have to worry about whether Celery, Dramatiq, Django, etc. is installed

[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] 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

[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).

[python/vercel-workers] Queue client (#16187) Implements `QueueClient` and `AsyncQueueClient` ```python from vercel.workers import QueueClient q = QueueClient() @q.subscribe def handler(message, metadata): pass ``` This PR adds configured queue clients and client-local subscription registration. It does not yet wire client-owned subscriptions into worker bootstrap/callback handling.

[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" } } } ```

[services] `experimentalServicesV2` -> `services` (#16757) Add `services` as the canonical multi-service project configuration and keep `experimentalServicesV2` as a deprecated backwards-compatible alias.

[vercel-workers] payload type validation (#16119) Adds support for payload type validation with [Pydantic TypeAdapter](https://pydantic.dev/docs/validation/latest/api/pydantic/type_adapter/) This PR adds Pydantic to the dependencies but vercel-workers depends on the Vercel SDK which already depends on Pydantic so it is not a net new dependency Typed `@subscribe` handlers now validate and coerce the queue payload before invoking the handler. If validation fails, the message is treated as a processing failure: the SDK does not acknowledge/delete it, allowing VQS to redeliver according to configured retry, max-attempts, and TTL behavior instead of silently dropping the message ```python class CreateUser(BaseModel): email: str name: str @subscribe(topic="users.create") async def handle_user_create( payload: CreateUser, metadata: MessageMetadata, ) -> None: print(payload.email, metadata["messageId"]) ```

[python/vercel-workers] support omitting deployment id (#16143) The deployment ID header for per-deployment isolation is [optional](https://vercel.com/docs/queues/api#common-headers) Adds an unset sentinel to enable the 3 separate behaviors: ```python # Auto-pinned send("q", payload) # sends Vqs-Deployment-Id from VERCEL_DEPLOYMENT_ID # Explicitly unpinned send("q", payload, deployment_id=None) # sends no Vqs-Deployment-Id header # Explicit pin send("q", payload, deployment_id="dpl_123") # sends Vqs-Deployment-Id: dpl_123 ``` --------- Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>

[go] Supervise user server after startup (#16598) ## Problem In standalone Go server mode, the bootstrap only watches the user's server process during startup. If the server crashes after `server-started`, nothing notices: the proxy returns 502s for every request while`/_vercel/ping` (which is answered by the bootstrap itself) keeps reporting 200 ## Fix After startup completes, a goroutine waits on the existing `childDone` channel (fed by `cmd.Wait()`). If the user server exits at any point, the bootstrap sends an `unrecoverable-error` IPC message and exits with the child's exit code ## Testing - Tests fo `vc-init.go` - Manual smoke test: deployed app with /crash endpoint that called `os.Exit()` * prev: kept serving 502s * after: "This Serverless Function has crashed." then healthy again

[python] apply request path transforms (#17212) Currently rewrites for python are no-ops since they only modify the path that Vercel matches at the proxy layer, not the request path actually seen by the user code This means the following currently has no effect, user code still sees `/old` ```json { "rewrites": [ { "source": "/old", "destination": "/new" } ] } ``` This PR fixes this issue by adding a `request.path` transform to the emitted catch all lambda for python frameworks, which sets the request path seen by user code to the path ```json { "src": "/(.*)", "dest": "/index", "transforms": [ { "type": "request.path", "op": "set", "args": "/$1" } ] } ```

[vercel-workers] ack and retry directives (#16120) Adds `Ack(...)` and `RetryAfter(...)` exceptions for Python queues SDK - Support returning or raising directives from handlers. - Map `RetryAfter(...)` to delayed retry and `Ack(...)` to delete/no retry. - Remove support for returning dicts with `{ retryAfter: ... }`

[routing-utils] service-targeted route destinations (#16545) ## Summary Adds a service-targeted `destination` to `@vercel/routing-utils` so a route/rewrite can delegate into a named service from `services`/`experimentalServicesV2` ```json { "source": "/org/:orgSlug/api/:path*", "destination": { "type": "service", "service": "my_backend", "path": "/:path*?org=:orgSlug" } } ``` `destination` can now be either the existing string (unchanged behavior — alias for dest) or a `ServiceDestination` object

[vercel-workers] support timedelta for retention and delay (#16106) Replaces `retention_seconds` and `delay_seconds` with `retention` and `delay` which support `timedelta`, e.g `retention=timedelta(hours=6)` **Note:** this is a breaking change but the SDK is still unreleased and this is not a breaking change for the currently supported Celery path