Bring your own Supabase

By default your app runs on Vaulter's managed backend, and you never think about it. If you would rather own the backend yourself, you can connect your own Supabase project.

Why bring your own

Most people do not need to. The managed backend handles storage, privacy, and user accounts for you. Connecting your own Supabase makes sense when:

• Your organization requires data to live in an account you control.
• You want direct access to the database in the Supabase dashboard, outside of Vaulter.
• You want your app's auth and data fully under your own roof.

What you will need

You connect from Vault → Database → Settings. Vaulter asks for three things from your Supabase project:

• Project URL. The https://<your-project>.supabase.co address.
• Service role key. Lets Vaulter read and manage your app's data.
• Personal access token. Lets Vaulter set up the schema and replay your app's migrations on your project.

Only the project owner can connect a backend.

What happens when you connect

Vaulter first runs a preflight check on your project and tells you what it found. An empty project, or one with unrelated tables, is fine. It will refuse to connect a project that already hosts another Vaulter user's app, so two accounts can never collide on one database.

Then the swap streams its progress live: verify credentials, install Vaulter's schema contract, recreate your app's tables by replaying its migration history, and repoint your app at your project. If a migration fails partway, the process stops there with the error so you can fix and retry; nothing is silently skipped.

What changes

• Your data lives in your account. Full access in the Supabase dashboard, your plan, your backups, your limits.
• Your users sign in through your project. Auth is handled by your own Supabase rather than the Vaulter sign-in portal.
• The Database panel keeps working. Browsing, editing, SQL, and migrations in Vaulter all operate on your project. As a safety measure, editing live rows on a connected project asks for a confirmation each session, because Vaulter cannot undo changes in a database you own.

The honest caveats

• The swap is one-way. You cannot move back to the managed backend. You can only replace one connected Supabase with another later.
• Schema moves, data does not. Your app's structure is recreated on your project, but rows, existing signed-in users, and uploaded files from the managed backend do not come across. Connect early, before you have real data, or plan to bring data over yourself.
• Privacy rules are yours to confirm. The per-user privacy model is installed on your project as part of the contract, but you own the project and can change it. Review your access rules before launch, and when in doubt, ask the agent to confirm how privacy is set up.