Back to Documentation
Getting StartedUpdated 2026-04-02

Deploying to Production

Production deployment checklist: Supabase, environment variables, Vercel, monitoring, and required packages.

Deploying to Production

This is the production deployment checklist for a Vorion-governed application. It covers database setup, environment configuration, deployment, monitoring, and the npm packages you need.

Required Packages

Install the core governance stack:

npm install @vorionsys/sdk @vorionsys/atsf-core @vorionsys/cognigate

For canary probes and assurance infrastructure:

npm install @vorionsys/a3i

For the governance pipeline (intent parsing, enforcement, proof chain):

npm install @vorionsys/basis @vorionsys/enforce @vorionsys/proof

Package Summary

| Package | Purpose | |-----------------------|--------------------------------------| | @vorionsys/sdk | High-level SDK (local + remote mode) | | @vorionsys/atsf-core| Trust scoring engine | | @vorionsys/cognigate| Governance enforcement client | | @vorionsys/a3i | Canary probes, assurance infra | | @vorionsys/basis | BASIS standard, canonical params | | @vorionsys/enforce | Policy enforcement engine | | @vorionsys/proof | Cryptographic proof chain |

1. Supabase Setup

Vorion uses Supabase (PostgreSQL) for agent state, trust history, proof records, and canary probe results.

Create the Project

  1. Go to supabase.com and create a new project.
  2. Note the project URL and service role key.
  3. Enable Row Level Security (RLS) on all tables.

Run Migrations

The Vorion monorepo includes database migrations:

# From the monorepo root
npx supabase db push --project-ref YOUR_PROJECT_REF

This creates the required tables:

  • agents — Canonical Agent Records (CARs)
  • trust_scores — Current and historical trust scores
  • signals — Behavioral signal log
  • proofs — Hash-chained proof records
  • canary_results — Canary probe evaluations
  • lifecycle_events — State transition audit trail

Verify the Schema

npx supabase db diff --project-ref YOUR_PROJECT_REF

If the diff is clean, your schema matches the expected state.

2. Environment Variables

Create a .env file (or configure your deployment platform's environment):

# Supabase
SUPABASE_URL=https://your-project.supabase.co
SUPABASE_SERVICE_ROLE_KEY=eyJ...
SUPABASE_ANON_KEY=eyJ...

# Cognigate API
COGNIGATE_API_KEY=cog_...
COGNIGATE_API_URL=https://cognigate.dev/v1

# Trust Engine
TRUST_GAIN_RATE=0.05
TRUST_FAILURE_THRESHOLD=0.3
TRUST_SUCCESS_THRESHOLD=0.7

# Canary Probes
CANARY_INJECTION_RATE=0.10

# Operator Configuration
OPERATOR_POSTURE=STANDARD
OPERATOR_SECTOR=GENERAL

# Optional: Redis for caching / rate limiting
REDIS_URL=redis://...

Required vs. Optional

| Variable | Required | Default | |-------------------------------|----------|-----------| | SUPABASE_URL | Yes | — | | SUPABASE_SERVICE_ROLE_KEY | Yes | — | | COGNIGATE_API_KEY | Yes | — | | TRUST_GAIN_RATE | No | 0.05 | | CANARY_INJECTION_RATE | No | 0.10 | | OPERATOR_POSTURE | No | STANDARD | | OPERATOR_SECTOR | No | GENERAL | | REDIS_URL | No | in-memory |

Never commit .env files to source control.

3. Operator Posture Configuration

BASIS supports three operator postures that tune the governance parameters:

// STRICT — tighter penalties, lower accumulator thresholds
// STANDARD — canonical defaults
// PERMISSIVE — wider tolerances, higher thresholds

// Set via environment variable or programmatically:
import { OPERATOR_POSTURES } from '@vorionsys/basis';

const posture = OPERATOR_POSTURES[process.env.OPERATOR_POSTURE || 'STANDARD'];

| Posture | Penalty Range | Accumulator CB | Cooldown Mult | |------------|--------------|----------------|---------------| | STRICT | 5×–12× | 160 | 0.5× (faster) | | STANDARD | 3×–10× | 240 | 1.0× | | PERMISSIVE | 2×–9× | 320 | 1.5× (slower) |

Sector configuration adds domain-specific probe requirements:

import { OPERATOR_SECTORS } from '@vorionsys/basis';

// Healthcare: +5 additional probes, SAFETY minimum raised to 95%
// Financial: +5 additional probes, ETHICAL minimum raised to 90%
// Defense: +10 probes, double exercises, all minimums boosted 5%

4. Deploy to Vercel

Vorion apps deploy to Vercel via CLI (not git-connected):

# Install Vercel CLI
npm install -g vercel

# Deploy
vercel --prod

Pre-Deployment Checklist

  • [ ] All environment variables are set in Vercel project settings
  • [ ] Supabase migrations are applied
  • [ ] Database RLS policies are enabled
  • [ ] Cognigate API key is valid and scoped correctly
  • [ ] Build succeeds locally (npm run build)
  • [ ] Tests pass (npm run test)

Vercel Configuration

For Next.js apps in the Vorion monorepo, ensure vercel.json includes:

{
  "framework": "nextjs",
  "buildCommand": "turbo build --filter=your-app",
  "installCommand": "npm install",
  "outputDirectory": "apps/your-app/.next"
}

5. Cognigate API Deployment

If you are running the Cognigate API as a standalone service:

Docker

docker compose -f apps/cognigate-api/docker-compose.yml up --build -d

Fly.io

cd apps/cognigate-api
fly deploy

Health Check

curl https://your-cognigate-instance.fly.dev/health
# Expected: {"status":"ok","version":"3.0.0"}

6. Monitoring Dashboard

The Wave 4 monitoring dashboard provides real-time visibility into:

  • Trust score trends — per-agent score over time
  • Tier distribution — how many agents at each tier
  • Canary probe results — pass/fail rates by category
  • Circuit breaker status — which agents are tripped or degraded
  • Risk accumulator — 24h rolling window per agent
  • Lifecycle events — state transitions with timestamps

Enable Monitoring

import { MonitoringService } from '@vorionsys/a3i';

const monitoring = new MonitoringService({
  supabaseUrl: process.env.SUPABASE_URL!,
  supabaseKey: process.env.SUPABASE_SERVICE_ROLE_KEY!,
  refreshIntervalMs: 5000, // Dashboard refresh rate
});

await monitoring.start();

Key Metrics to Watch

| Metric | Warning Threshold | Action | |---------------------------|-------------------|---------------------------| | Canary pass rate (global) | < 85% | Review failing categories | | Agents in DEGRADED state | > 10% | Investigate common causes | | Circuit breaker trips/day | > 2 | Audit triggering agents | | Risk accumulator > 60 | Any agent | Increase monitoring | | Dormancy deductions | > 5 agents | Check for inactive agents |

7. Post-Deployment Verification

Run these checks after deploying:

# 1. Verify the trust engine initializes
curl https://your-app.vercel.app/api/health

# 2. Register a test agent
curl -X POST https://your-app.vercel.app/api/v1/agents \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -d '{"agentId":"deploy-test","name":"Deployment Test"}'

# 3. Check trust score
curl https://your-app.vercel.app/api/v1/trust/deploy-test

# 4. Verify proof chain
curl https://your-app.vercel.app/api/v1/proofs/verify?agentId=deploy-test

# 5. Clean up test agent
curl -X DELETE https://your-app.vercel.app/api/v1/agents/deploy-test

Production Hardening Checklist

  • [ ] Supabase RLS enabled on all tables
  • [ ] API keys rotated from development values
  • [ ] Rate limiting configured (Redis recommended)
  • [ ] CORS restricted to your domains
  • [ ] Canary injection rate set appropriately for your scale
  • [ ] Circuit breaker thresholds reviewed for your use case
  • [ ] Monitoring alerts configured for CB trips
  • [ ] Backup strategy for proof chain data
  • [ ] Operator posture and sector configured correctly
  • [ ] HITL SLA escalation contacts defined

Key Takeaways

  • Six core packages form the governance stack.
  • Supabase provides the persistence layer; run migrations before deploying.
  • Environment variables control trust parameters — canonical defaults are production-ready.
  • Deploy via vercel --prod (CLI, not git-connected).
  • Monitor canary pass rates, circuit breaker trips, and risk accumulators.

Next Steps

All Documentation