feat(website): deploy main to staging and production manually

[Mochael]

Summary

Replaces preview-based staging with a stable Vercel custom environment.

• allows only main to trigger a Vercel Git deployment, routed by the Vercel branch rule to staging
• disables Git deployments for PR branches and the sentinel production branch
• adds a protected manual production workflow pinned to the dispatched main SHA
• validates Vercel target, API endpoint, and environment-specific GitHub App URL at build time
• points staging at https://api.staging.libretto.sh and production at https://api.libretto.sh
• documents Vercel domains, branch rules, environment variables, Deployment Protection, and GitHub environment secrets

Dependencies

• cloud auth policy: https://github.com/saffron-health/libretto-cloud/pull/273
• staging domains/config: https://github.com/saffron-health/libretto-cloud/pull/274

Verification

• website Vitest: 21 tests passed
• website TypeScript type-check
• staging build with staging API and staging GitHub App identities
• production build with production identities; no staging endpoint in application bundles
• mismatched staging-to-production build fails before compilation
• actionlint and git diff --check
• independent security review: no Critical, High, or Medium blockers

Rollout prerequisites

Complete apps/website/DEPLOYMENTS.md before merging: create the Vercel staging custom environment and exact main branch rule; set Production Branch to production; expose system variables; set scoped endpoint/App variables; attach staging.libretto.sh; enable Vercel Authentication without bypass links; and create the approval-protected GitHub production environment.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
libretto-docs	Building	Preview	Aug 15, 2026 12:22am

[github-actions]

OpenCode Review

📋 Detailed Review

Spec Analysis

No spec file exists. Inferred goals: make main auto-deploy to Vercel staging, block PR and sentinel production Git deployments, add an approval-gated manual production workflow, validate deployment target/API/App identity at build time, and document the required Vercel/GitHub setup.

Changed Files

• .github/workflows/deploy-website-production.yml: adds manual production deploy workflow.
• apps/website/DEPLOYMENTS.md: documents staging and production setup.
• apps/website/scripts/deployment-config.spec.ts: tests deployment config validation.
• apps/website/scripts/deployment-config.ts: validates target-specific API and GitHub App URLs.
• apps/website/src/prAgentSetup.ts: makes GitHub App install URL environment-specific.
• apps/website/vercel.json: limits Git deployments and allows staging API in CSP.
• apps/website/vite.config.ts: runs deployment validation during Vite config load.

Simplicity Assessment

• apps/website/scripts/deployment-config.ts:12-60 is a small direct validator and is appropriate for the deployment guard.
• apps/website/vercel.json:3-9 uses Vercel’s native branch deployment rules instead of adding extra CI logic, which is the simpler path for the staging goal.
• .github/workflows/deploy-website-production.yml:29-35 can stay as one deploy step, but it needs to run against the website project root rather than the repository root.

Correctness Assessment

• .github/workflows/deploy-website-production.yml:29-35 runs vercel deploy from the checkout root, while the Vercel project config and output settings live under apps/website/vercel.json:1-10. Vercel CLI deploys the current project root unless given a path or --cwd, so this can ignore the website vercel.json, build the monorepo root, fail, or publish the wrong output. That breaks the PR’s core manual production release path.
• apps/website/scripts/deployment-config.ts:46-51 rejects the production GitHub App in staging, but it still accepts any other GitHub App slug with the right URL shape. That is non-blocking if the intended invariant is only “not production,” but it does not fully validate the exact staging App identity shown in apps/website/scripts/deployment-config.spec.ts:11-16.

Summary

The staging branch rules, environment validation, CSP update, and docs match the stated deployment model. The manual production workflow has one blocking path issue: it invokes Vercel from the repo root instead of the website project root.

Required Actions

• Fix .github/workflows/deploy-website-production.yml:29-35 to deploy apps/website explicitly, for example with vercel deploy --cwd apps/website or an apps/website path. Failure mode: the production workflow can build/deploy the wrong root or fail before publishing. Impact: manual production releases may not work. This blocks merge because manual production deployment is a primary goal of the PR.

Suggestions

• Consider making apps/website/scripts/deployment-config.ts:46-51 check the exact staging GitHub App install URL if the goal is strict environment identity validation, not just preventing the production App URL in staging.

github run

[Mochael]

Follow-up on the automated review: I checked this against Vercel’s current monorepo/Root Directory documentation. The existing project has Root Directory set to apps/website; Vercel states that this setting also applies to CLI and explicitly says to invoke the CLI from the monorepo root rather than the subdirectory. Keeping the workflow at repository root is therefore intentional and preserves workspace dependencies. Sources: https://vercel.com/docs/builds/configure-a-build#root-directory and https://vercel.com/docs/monorepos#add-a-monorepo-through-vercel-cli