CLI

The CLI publishes as the unscoped orvacon package, so it runs without installing — shadcn-style. Two commands cover the setup orvacon can't do for you: minting a signing keypair and emitting the database schema.

npx orvacon --help

orvacon keys

Generates an Ed25519 webhook signing keypair and prints both keys to stdout as env lines:

npx orvacon keys >> .env.local

ORVACON_WEBHOOK_SIGNING_KEY=orvsk_…   # secret — pass to orvacon({ webhookSigningKey }); never commit
ORVACON_WEBHOOK_PUBLIC_KEY=orvpk_…    # public — give to whoever verifies your webhooks; safe to share

The secret signs outbound webhooks; the public key is what your verifying endpoint (or a third party) checks against. Redirect stdout to capture them — the guidance prints to stderr, so it won't end up in your .env.

orvacon generate

Emits the core Postgres schema with default-deny row-level security. By default it prints the SQL rather than writing it — deliberately, so you read the security boundary before applying it:

npx orvacon generate                 # print schema + RLS to stdout (review it)
npx orvacon generate --write         # save → supabase/migrations/<timestamp>_orvacon.sql
npx orvacon generate --write --force # overwrite an existing orvacon migration

Then apply it with your migration tool:

supabase db push

The see → write → apply order is intentional: you read the policies, save them into your own migration history, and apply them yourself. orvacon never silently mutates your database.