Deployment

The target stack is Vercel for Next.js, Supabase for Auth/PostgreSQL/Storage and Cloudflare DNS for foliovera.app. Vercel’s application root is apps/web. Corepack selects the pinned pnpm version from the monorepo lockfile configuration.

Set these production environment variables in Vercel:

Variable	Purpose
APP_ORIGIN	https://foliovera.app
SUPABASE_URL	Target Supabase project URL
NEXT_PUBLIC_SUPABASE_URL	The same public API URL
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY	Publishable key
ENABLE_EXPERIMENTAL_COREPACK	1

Docker builds set BUILD_TARGET=docker to generate standalone output. Vercel uses its native Next.js adapter without standalone output.

Before applying migrations, check the exact project reference and existing database backups. The seed does not create test authentication users in production. Only invited family members can enter the workspace. Normal app requests use the publishable key and the user’s session under RLS. Administrative credentials belong only to separate setup operations, never the Vercel app.

The configured SMTP service is Resend, sender login@foliovera.app, host smtp.resend.com, port 465 and a domain-restricted sending key. DNS verification does not prove successful email delivery or sign-in; test those separately.

Use the official Supabase CLI with certificate and hostname verification for database operations. The workstation has no IPv6 route to the direct endpoint, so the session pooler is used instead.

Initial deployment had to go through the Management API migration endpoint: the CLI failed while creating the migration ledger in an empty database (supabase/cli#6393). That API assigns versions with second precision, so repository filenames now match those authoritative versions, with unchanged SQL. The ledger exists now and the workaround is gone — every later release uses the CLI.

Never edit migration history by hand. Before a release, compare it with the repository: pnpm db:prod:status prints what is applied and what is pending.

What triggers what

Releasing is merging a release branch into main. release.yml reads the version from package.json, tags it, publishes the GitHub release from the changelog section, and only then starts the production deployment. An ordinary merge that does not change the version releases nothing.

Verification runs on the developer’s machine, in pre-push. There is deliberately no separate Actions run: it would repeat work already done.

Neither moves the database. A person applies migrations with pnpm db:prod:apply before the merge: every migration is additive, so the running version survives the new schema while the reverse is not true. The full release order and the rollback path are in docs/release.md.

Supabase requires the application Site URL and exact /auth/callback redirect, Google OAuth and SMTP. Google Cloud uses the Supabase project’s OAuth callback. OAuth and SMTP secrets must not be committed. The normal login page offers Google and magic link; password recovery remains separate from public navigation.

Before declaring production ready, verify HTTPS, Google sign-in, delivered magic links, outsider denial, student permissions, private uploads, logout and rollback. Current evidence and verdicts live under .agent/tasks/foliovera-mvp/. This guide describes the deployment process; it does not certify completion.