Skip to main content

Deploy SABLE

Release owner: Indigo-Trigger/sable owns production deployments. Vercel builds web/ and docs-site/ from its merged main. GitHub Actions in this repository own Supabase migrations, Edge Functions, and Trigger deployment. The engagement repository retains historical evidence but does not release SABLE.

Supabase Project​

Current Supabase project ref:

fvngkfrmienkltuwtoxa

Project config lives in:

supabase/config.toml

Migrations​

Add a new migration under supabase/migrations/, test it, and submit it in a PR. After a release merge in this repository, sable-migrate.yml applies committed migrations to production when its path gate and required repository secrets are satisfied. Do not run production db push from a workstation.

On every PR, sable-migrate-rehearsal.yml applies the migrations the PR adds or changes the way production will. It replays the older migrations, then runs db push on the same CLI version, as the non-superuser postgres role, in a fresh session. It also rejects a new migration whose timestamp is not newer than the latest one on main, and deleting or renaming a migration, since db push refuses both. A failure there usually means SABLE Migrate would fail after merge and block every migration behind it. The one exception is editing a migration production has already applied: the rehearsal re-applies it, and production never will.

One cause of such failures is naming an extension's setting (such as hnsw.ef_search) in a function SET clause before that extension has loaded in the session. Run one of the extension's functions first, for example select '[1]'::public.vector;.

Edge Functions​

Submit changed functions and supabase/config.toml in a PR. After merge, this repository's sable-deploy.yml deploys the checked-in function set when its path gate and required repository secrets are satisfied. Do not deploy an Edge Function from a workstation.

fathom-webhook and spine-mcp must be deployed with JWT verification disabled. Fathom authenticates with signed webhook headers; spine-mcp is dialed by the SABLE Claude Managed Agent with a static bearer (SPINE_MCP_TOKEN) from its vault. Neither is a Supabase JWT, and each function enforces its own auth. If spine-mcp is deployed with the gate on, CMA's calls are rejected as "Invalid JWT" before the function runs and every "Go SABLE" run fails. The required settings are pinned in config.toml and applied by the automated deployment workflow.

Web App​

The app deploys from:

web

It uses Vercel's zero-config serverless routing for api/*.js.

Production target:

Team: cprinos-7741s-projects
Project: sable
Root directory: web (standalone repository)
URL: https://sable.indigotrigger.ai

Production is deployed only by Vercel's Git integration after a checked PR merges to the current release owner's main. vercel project inspect sable --scope cprinos-7741s-projects is permitted for read-only verification; direct production deploy, promote, redeploy, and alias commands are prohibited.

Docs Site​

Production URL:

https://docs.sable.indigotrigger.ai/

Build from:

cd docs-site
npm run build

Docusaurus writes static output to build/. That folder is generated and should not be treated as source.

The docs site has its own vercel.json so its Git deployment uses npm run build and publishes the generated build/ directory. Build locally and submit the result through the repository workflow; do not deploy production docs directly from a workstation.

Board Orchestrator​

Submit Trigger.dev task changes in a PR in this repository. After merge, sable-deploy.yml deploys the worker when its path gate and repository access token are satisfied. Do not deploy Trigger tasks from a workstation. Start cutover configuration with the data plane and changed Edge Functions present. Use SABLE_REPORT_DELIVERY_MODE=shadow and follow Board Reliability And Cutover. Do not leave built-in Claude Managed Agent board schedules and Trigger board schedules active together.

Operators verify the generated weekday ET schedules in the Trigger dashboard after the automated deployment.

Release customer portal changes​

Schema-dependent portal releases require an ordered database, Edge Function, Trigger, web, and email gate. Follow Release the customer portal before enabling customer activity email.