Vercel releases

Vercel is optional. Generic tool and HTTP projects do not need a Vercel project. Use a separate real-work project after the diagnostic connection check.

Connect the release target

In Projects & rules, create a project with a Vercel binding or explicitly link an unbound project using its real Vercel project ID and name. Only an owner or admin can do this. Existing bindings cannot be detached or silently rebound.

Connect Vercel credentials for the organization. For staging, configure a staging domain. For production, enable the production-enforcement setting and ensure Vercel's own configuration does not offer an unguarded production path.

Give the runtime a deploy:staging or deploy:production grant, preferably with explicit allowedGitRefs, and a policy covering its source. A production policy requiring human approval is a sensible starting point.

Authorize an existing preview

This example uses the client from the Node SDK guide and a separate real-work project. It authorizes and executes a staging alias, not a new build. The deployment ID and Git SHA must belong to your existing preview:

const request = await passport.authorize({
  action: "deploy:staging",
  parameters: {
    deploymentId: "dpl_REPLACE_WITH_PREVIEW_ID",
    gitSha: "0123456789abcdef0123456789abcdef01234567",
    gitRef: "refs/heads/main",
  },
});

const decision = request.status === "pending"
  ? await passport.waitForDecision(request)
  : request;
if (decision.status !== "allowed") {
  throw new Error(`Release stopped: ${decision.reasonCode}`);
}
await passport.execute(request);

Use deploy:production only with the corresponding grant and policy. The relay checks the configured project, promotable preview and current authorization. It holds the Vercel credential; do not give that credential to the model.

An unbound project fails execution with VERCEL_PROJECT_NOT_BOUND before a Vercel call. Signature verification alone must never trigger an independent deployment path. See verification for the distinction.