Self-hosting

Cinderblock targets Supabase Cloud by default. Self-hosting is possible but out of scope for the demo deployment — the Docker Compose / Kubernetes operational burden is genuinely different and would distract from the security pitch.

What changes

The migrations + policies + Edge Functions are portable. To swap Cloud for a self-hosted Supabase stack you change:

• Connection URLs. NEXT_PUBLIC_SUPABASE_URL + PG_AUDIT_WRITER_URL + PG_IMPERSONATOR_URL point at your self-hosted endpoints.
• JWT secret.Same shape, different rotation mechanism (you manage GoTrue's signing key directly).
• pg_cron extension. Self-hosted Postgres ships pg_cron the same way; the schedule migrations apply unchanged.

What doesn't work out of the box

• Supabase Branching. The CI "ephemeral preview database per PR" story doesn't apply — substitute with a test-database-per-branch convention or a single shared test stack.
• Supabase Management API. The /status page and quota-alert pg_cron job use the Management API — those become no-ops or you wire equivalent telemetry from your own observability stack.

Why we stayed on Cloud

The buyer pool for Cinderblock-style work is on Supabase Cloud. Showing a demo that runs on Cloud is faithful to what the prospect will receive. The self-hosted path is a fork-it-yourself swap, not a feature.