Supabase is the backend your app gets when it needs one
The moment your project needs data that survives a refresh, the agent reaches for Supabase: a Postgres database with auth, file storage and Edge Functions on top. It creates the project, writes the migrations, wires the client and puts row-level security on every table — in your own Supabase organization, on your own plan.
What connecting it unlocks
Postgres
A real relational database, not a key-value store bolted onto a form builder. Tables, foreign keys, indexes, views and SQL you can read.
Auth
Email sign-in, sessions and users live in your Supabase project. Your app authenticates against it directly — Vibely is not in that flow and has no login of its own for your users.
Storage
Buckets for avatars, receipts, exports and anything else your users upload, with access policies written alongside the tables that reference them.
Edge Functions
Server-only logic — webhook handlers, scheduled jobs, anything that has to hold a secret key. Secrets go into Supabase Edge Function secrets, never into your client bundle.
Realtime
Every Supabase project ships Postgres change streams over websockets. Ask for a board that updates as other people edit it and that is what it is built on.
RLS by default
New tables get a deny-all row-level security policy, and the agent then adds least-privilege policies for the access patterns your app actually needs.
How it works, in one prompt
You do not write SQL, and you do not open the Supabase dashboard to get started. You describe the behaviour you want.
Your prompt
“Add email sign-in and a projects table each user only sees their own rows of.”
What comes back
- Supabase Auth configured for email sign-in, with the session wired into your app
- A migration in supabase/migrations/ creating the projects table
- A row-level security policy scoped to auth.uid(), so one user’s rows are unreachable from another user’s session
- The screens to sign in, list and create — already talking to the real table
What the agent does for you
Creates or links the project
Connect Supabase from the Backend drawer and the agent either creates a new project in your organization or links the one you already have.
Writes the migration
Schema changes land as timestamp-prefixed SQL files under supabase/migrations/ in your repo, and are pushed with supabase db push --linked. The SQL is yours to read, edit and keep.
Writes the RLS policies
Every table the agent creates starts deny-all, then gets policies scoped to auth.uid() or to whatever role column your app uses.
Wires the client
@supabase/supabase-js is configured with environment-aware URLs and anon keys, so the same code works in preview and in production.
Keeps reading the live schema
From then on the agent has supabase_setup (link, migrate, restart) and db_schema (read the live schema), so later turns build against what your database actually contains rather than what it remembers writing.
One database behind your web app and your native app
Vibely builds native mobile apps with Expo as well as web apps, and the same Supabase project backs both. One schema, one set of migrations, one auth configuration — a user who signs up on the website is signed in on the phone, against the same users table, with the same RLS policies deciding what they can read. There is no second backend to provision and no sync layer to keep honest.
Why RLS is mandatory on mobile, not advisable
The Supabase anon key is compiled into the Expo bundle. Anyone who installs your app can extract it and call your database directly, without ever loading one of your screens. Hiding a tab behind a session check is user interface, not access control. The only thing standing between an extracted key and your users’ rows is the row-level security policy on the table — which is why the agent writes one for every table it creates and why the security scan flags a table with RLS disabled.
What you should know first
You bring your own Supabase account
Vibely does not host your database and does not resell database capacity. A project created here is a normal project in your own Supabase organization, on your own plan, and Supabase bills you directly. If you leave, the database stays where it is.
The OAuth app needs database permissions
Connecting is an OAuth flow against the Supabase Management API. Migrations need the Database read and write permissions enabled on that authorization — if they are missing, the agent will tell you rather than half-apply a schema change. The setup guide in the docs walks through checking this.
The migrations are files in your repo
Everything the agent changes is a timestamp-prefixed SQL file under supabase/migrations/. You can read the diff, edit it, revert it, or run it yourself with the Supabase CLI. Nothing about the schema is locked inside Vibely.
Server-side secrets live in Supabase
API keys your app needs at runtime are set as Supabase Edge Function secrets with supabase secrets set, and read by an Edge Function. They are never bundled into the web or mobile client.