storage

Problem Blob is getting an S3-compatible API (vercel/api#90518). S3 SDKs authenticate with an access key + secret, and we want the same zero-config DX as from : no static keys, credentials derived from the deployment's OIDC identity and refreshed automatically. Read-write tokens are deliberately not accepted as S3 credentials. Solution New subpath export : returns a provider function for the AWS SDK's option. Each call exchanges the Vercel OIDC token ( or the option, plus or ) for temporary credentials through the new endpoint. It throws a clear error when no OIDC token is available, even if a read-write token is. Options: , (scope) and (default 1 h, max 7 days). for a single credential set (for non-JS S3 clients). The result also carries , and so callers can configure a client without looking anything up. No new dependencies; the credential type is structural so stays out of the package. README documents the flow. 🤖 Generated with Claude Code

Why At API v13 the server reads keys containing or path segments exactly as written, instead of resolving them per RFC 3986 and looking up the wrong key (vercel/api#95790). This sends 13, which is what makes that reachable for , , , and . Production over 30 days: 164 requests failed for this reason; one succeeded because the normalization happened to land on a real key, and that one will start failing. is deliberately unchanged. It fetches the blob host directly, so the pathname is the URL path and resolves it before the request exists — fixing that means replacing the transport, too much risk for the size of the problem. Last commit removes an unused import in and an unused function in . Both are dead on and fail , which blocks this PR; unrelated otherwise. Merge after vercel/api#95790 deploys, or v13 requests hit a server that still resolves.

Problem rejects any URL whose hostname isn't . That check was added as an SSRF guard, but it also blocks local emulation: both (blob support) and serve blob content from their own host, so throws before any request is made. Every other command (, , , ) already works against an emulator because they route through . Raised by @scotttrinh in #help-cdn while adding Blob coverage to (#278) for the upcoming Python and Go SDKs. Solution now also accepts URLs on the same origin as a / override. With no override set, nothing changes — arbitrary hosts, subdomain spoofing and plain are all still rejected, so production behavior and the SSRF guard are untouched. Two things stay as they are, both because the SDK can't know an emulator's URL layout: Pathname input still builds a production store URL. Emulator users pass the URL returned by /, which is what already resolves on its side. For an emulator URL, keeps the emulator's route prefix (, not ), since it's derived from the URL path. Why:** You couldn't read a blob back when pointing the SDK at a local emulator — writes worked, reads threw "the URL does not point to a Vercel Blob store". Now, if you've explicitly told the SDK where its API lives, reads from that same host are allowed too, which is what unblocks and keeps the Python SDK from having to hardcode the hostname check. No feature flag: this is an npm SDK, and the change is self-gating — it only takes effect when is set, which is already an opt-in for non-production use. Rollback is a version revert. 🤖 Generated with Claude Code