feat(vercel): derive five deploy values from the linked stores

[jouwdan]

Closes MEI-129.

The Deploy Button asked for seven values. Five of them the board can work out once Neon, Upstash and Blob are linked. It now asks for two: AUTH_SECRET and CRON_SECRET.

Why two and not zero

CRON_SECRET cannot be generated by the board — Vercel Cron sends Authorization: Bearer $CRON_SECRET read from the project's environment, so a value generated internally would be unknown to the caller.

AUTH_SECRET could be generated and persisted, but stays prompted by decision: it seals members' two-factor secrets and signs unsubscribe links, and keeping it environment-only means a database dump alone cannot forge either.

What is derived

Every derivation is gated on running on Vercel, fires only when the variable is unset, and requires a candidate that is both present and the right shape.

Variable	From	Basis
REDIS_URL	KV_URL, then UPSTASH_REDIS_URL	KV_URL confirmed on a real linked project — Upstash publishes no REDIS_URL at all, which is why the form asked for it
DIRECT_DATABASE_URL	DATABASE_URL_UNPOOLED, then POSTGRES_URL_NON_POOLING	both confirmed, both unpooled
CACHE_DRIVER	redis, once a Redis URL resolves	—
FILESTORE_DRIVER	blob, from BLOB_STORE_ID or BLOB_READ_WRITE_TOKEN	see below
MAIL_FROM	removed from the button	mail cannot work until Resend is added after the deploy; it is now part of that step

KV_REST_API_URL is deliberately excluded: it is an HTTPS REST endpoint, and a Redis client given it fails at connect time as though the network were broken. POSTGRES_URL and POSTGRES_PRISMA_URL are excluded as pooled — a transaction-mode pooler cannot hold the session-level advisory lock migrations and the installer take.

The Blob driver now authenticates the way Vercel configures it

A linked Blob store publishes BLOB_STORE_ID and BLOB_WEBHOOK_PUBLIC_KEY — and no read-write token. Confirmed against a real project's complete environment list.

Reading the installed SDK, that is deliberate. resolveBlobAuth resolves credentials as presigned → an explicit token option → OIDC (VERCEL_OIDC_TOKEN plus BLOB_STORE_ID) → the BLOB_READ_WRITE_TOKEN environment variable → throw. OIDC is tried before the static token, and the store id is exactly what it consumes.

The driver previously passed token: on every call, forcing the second branch and making OIDC unreachable, and refused to construct without the token — so it could not work against a store attached through the integration at all. It now carries two credential shapes: the OIDC path passes a store id and no token key, and the token path is unchanged.

When both are present, the store ids are compared. Same store, OIDC wins — a short-lived credential, and the SDK falls through to the token by itself if OIDC is unavailable, since getVercelOidcToken() returns undefined rather than throwing. Different stores, the token wins: it is typed by a person and a token naming another project's store is deliberate, so silently writing to the linked store would be a data error.

A token that parses as nothing is refused at boot, not on the first upload.

Self-host boards are untouched

Five environment shapes (compose-style, explicit drivers, redis cache, bare dev, build phase) each assert parseEnv({ ...shape, ...PUBLISHED }) deep-equals parseEnv(shape) on the full parsed environment, with every injected name present versus absent.

Refusals name what they looked for

A derivation that cannot resolve refuses to boot rather than falling back to local storage or the next cache — the silent degradations the prompts existed to prevent. Unresolved derivations are reported together, so one failed deploy names all of them.

Consequence worth knowing

A local community backup against a Blob store needs a token created by hand, because there is no deployment identity off-platform. This was always true of an OIDC-only project; what changed is that the documentation now says so instead of telling operators to copy a variable that does not exist.

Not established without a live deploy

Nobody has run this against real Blob storage. Reasoned from the SDK's shipped source, not observed:

• whether VERCEL_OIDC_TOKEN is actually present at request time on a linked project — this is the premise of the whole path;
• whether it exists during the build command (the code is careful not to need it: community migrate validates the environment and never reaches the file store);
• whether OIDC can be disabled per project, which the board cannot see and so cannot refuse at boot for;
• the SDK's error wording in whatever version Vercel resolves at deploy time.

Takes effect on a real deploy only once a release ships and meith-dev/vercel-template re-pins it.