Integration guide
Build with Supabase across auth, data and storage
Build with Supabase across auth, data and storage means treating the provider as an authorised external system—not a decorative logo. Xroga reports what the connected account allowed and what evidence the operation returned.
01
What belongs in the project
Keep code, configuration names, and provider-facing adapters reviewable in the repository. Keep secret values in the provider or deployment environment.
02
What must be verified
Confirm permissions, environment selection, failure behaviour, and the user-visible result. A successful API response and a working product are separate checks.
03
What Xroga will not assume
Xroga does not invent credentials, bypass provider policy, or report a deployment or integration as live without evidence from the authorised account.
04
Authentication, data, and RLS
Xroga can use an authorised Supabase project for database, authentication, storage, and migrations. Browser clients use public configuration; service-role credentials and privileged provisioning stay on the server. Row Level Security must be designed and tested for the application’s real ownership rules.
05
Verification
- Confirm the intended project and environment.
- Apply migrations through an authorised server path.
- Test allowed and denied reads and writes with real roles.
- Check storage policies as well as table policies.
- Never treat a successful connection as proof that the schema is secure.
Primary sources
Product capabilities change. These official pages were used for the factual statements above; verify them again before making a purchasing decision.