Self-hosting expands the operating boundary
A self-hosted Supabase service includes PostgreSQL and selected services for APIs, authentication, storage, realtime features, and administration. The operating team owns the deployed components, network paths, secrets, persistent storage, backups, monitoring, and updates. The application team still owns schema, migrations, policies, and application behaviour.
Own the PostgreSQL foundation
Plan database capacity, roles, migrations, connection limits, replication or recovery approach, and monitoring. Generated APIs do not replace row-level security review. Treat policies and schema changes as production changes with tests and rollback thinking.
Own selected service paths
Map authentication, browser origins, API keys, trusted server credentials, storage buckets, file limits, realtime subscriptions, and ingress. Do not deploy features merely because they are available. Each one adds configuration, data, access, and incident responsibilities.
Recover data and files together
Database records, objects, configuration, and identity dependencies may need different recovery steps. Test the agreed boundary in isolation. A restored database that points to missing files, or files without authorisation context, is not a complete application recovery.
Ownership record
Name each owner before launch.
| Area | Operating owner | Acceptance |
|---|---|---|
| PostgreSQL | Database team | Restore and migration test. |
| API and identity | Platform and app teams | Restricted-user journey. |
| Storage | Platform owner | Object permission test. |
| Release | Service owner | Versioned change record. |
Questions to settle
Does self-hosting move policy ownership to Supabase?
No. The team deploying and using the database remains responsible for its schema and access decisions.
What should be backed up?
State database, objects, configuration, secret references, and external identity limits separately.
What proves readiness?
A normal user journey, cross-tenant denial test, file check, and restore exercise.
Operate in stages
Choose components, owners, data paths, roles, and recovery targets.
Exercise policies, identity, uploads, migrations, and restore.
Review health, access, storage, backups, and releases.
Handover checks
Keep evidence with the service.
Service map
Components and owners are documented.
Policy test
User and tenant boundaries are tested.
Restore drill
Database and object recovery is rehearsed.
