Public documentation for governed AI labor
SDKs/Governance/Connectors
Arx / Docs / Supabase Migration Deployment Guide

Documentation

Supabase Migration Deployment Guide

Project-Agent / arxsec-api/migrations/DEPLOYMENT_INSTRUCTIONS.md

Project-Agent repo-root arxsec-api/migrations/DEPLOYMENT_INSTRUCTIONS.md

Step 1: Open Supabase Dashboard

  1. Go to https://app.supabase.com
  2. Click your project (jdiyzjmdtzwtyanzzraz)
  3. Navigate to SQL Editor (left sidebar)

Step 2: Create New Query

  1. Click New Query button
  2. Or click the + icon next to "New Query"

Step 3: Copy & Paste Migration Script

  1. Open this file: arxsec-api/migrations/deploy_all_migrations.sql
  2. Copy ALL contents (Ctrl+A, Ctrl+C)
  3. Paste into the SQL Editor (Ctrl+V)

Step 4: Run Migrations

  1. Click the ▶ Run button (or Ctrl+Enter)
  2. Wait for completion (~5-10 seconds)
  3. You should see:

`` deployment_status: "Supabase migrations deployed successfully" tables_created: [number of tables] ``

Step 5: Verify Deployment

  • Go to Database (left sidebar)
  • Click Tables
  • Look for:
  • ✓ agents
  • ✓ drift_events
  • ✓ approval_requests
  • ✓ policies
  • ✓ And 30+ more tables

Alternative: Deploy via CLI

If you have Supabase CLI installed:

``bash cd arxsec-api supabase db push --linked ``

Or push specific migrations:

``bash supabase db push arxsec-api/migrations/001_initial_schema.sql --linked ``

What Gets Deployed

Core Tables (from 001_initial_schema.sql)

  • orgs - Organizations
  • users - User accounts
  • agents - AI agents with declared intent
  • policies - Security policies for agent actions
  • approval_requests - Manual approval tasks
  • audit_log - Complete action audit trail
  • drift_events - Behavioral drift detections
  • compliance_packages - Evidence for audits

Advanced Features

  • SSO/SAML: sso_configs, sso_providers
  • SCIM: scim_tokens, groups, group_members
  • Encryption: encryption_configs (CMEK support)
  • API Keys: api_keys, webhooks, webhook_deliveries
  • Geordie Integration: Risk signal mappings
  • LLM Providers: Multi-provider support with health checks
  • Cloud Assets: Inventory tracking and dependencies

Security

  • Row-Level Security (RLS) enabled on all org-scoped tables
  • Encryption at rest for sensitive credentials
  • Foreign key constraints for referential integrity
  • Comprehensive indexes for performance

After Deployment

1. Verify Database Schema

``sql -- Run in SQL Editor to verify SELECT table_name FROM information_schema.tables WHERE table_schema = 'public' ORDER BY table_name; ``

2. Check Drift Events Table

```sql -- Should return 10 seeded drift events SELECT COUNT(*) as event_count FROM drift_events;

-- View sample events SELECT drift_type, severity, response_taken FROM drift_events LIMIT 5; ```

3. Refresh Dashboard

  • Go to https://app.arxsec.io/governance/drift
  • Page should refresh automatically
  • Behavioral Drift Detection metrics should show:
  • TOTAL EVENTS: 10
  • CRITICAL: 2
  • HIGH: 4
  • RESOLVED: 0
  • AGENTS SUSPENDED: 2

Troubleshooting

Error: "relation already exists"

Cause: Migrations were already deployed Fix: This is safe - all migrations use IF NOT EXISTS. You can re-run without issues.

Error: "permission denied"

Cause: Service role key doesn't have database permissions Fix:

  1. Go to Settings → API
  2. Copy fresh Service Role Key
  3. Re-run migrations

Error: "syntax error"

Cause: SQL was corrupted during copy-paste Fix:

  1. Go back to deploy_all_migrations.sql
  2. Re-copy the file (Ctrl+A, Ctrl+C)
  3. Clear editor and re-paste
  4. Run again

Dashboard still shows "No drift events"

Cause: Frontend cache or page not refreshed Fix:

  1. Hard refresh browser: Cmd+Shift+R (Mac) or Ctrl+Shift+R (Windows)
  2. Or wait 30 seconds for cache to clear
  3. Verify migrations ran: SELECT COUNT(*) FROM drift_events;

Important Notes

Idempotent Migrations

All migrations use CREATE TABLE IF NOT EXISTS and ADD COLUMN IF NOT EXISTS, making them safe to re-run multiple times.

Schema Consolidation

This script excludes approval_mitl_schema.sql because it duplicates 013_approval_escalation_chain.sql. Both create identical org_hierarchy, approval_rules, and approval_notifications tables.

Row-Level Security

All tables with org_id automatically enforce organization-scoped access via RLS policies. Users can only see data from their organization.

Performance

The combined script includes strategic indexes on:

  • org_id (organization filtering)
  • status (agent/request status)
  • created_at (audit trail sorting)
  • severity (drift event filtering)

Next Steps

After migrations are deployed:

  1. Deploy Edge Functions

``bash supabase functions deploy drift-check --linked supabase functions deploy approval-notify --linked supabase functions deploy on-signup --linked ``

  1. Configure Webhooks
  • Database → Webhooks
  • Add triggers for approval notifications and signup automation
  1. Set Scheduled Drift Detection
  • Edge Functions → drift-check
  • Enable scheduled execution at 0 * * * * (hourly)

Support

  • Supabase Dashboard: https://app.supabase.com
  • Documentation: https://supabase.com/docs
  • Status: https://status.supabase.com

For questions about ARXsec-specific tables/functions, refer to:

  • arxsec-api/docs/ - Architecture documentation
  • GitHub Issues - Report problems or ask questions