A client portal on your Supabase

In this tutorial you build a client portal that reads live from a Supabase project you already own: your data stays where it is, and your clients get a clean, sign-in-protected window onto exactly the slice of it you choose. The pattern fits any "my records live in Supabase, my clients need to see theirs" business. Fifteen minutes, plus builds.

You need: a Supabase project with at least one table of real-ish data. The example uses a consultancy with a projects table (client name, project, status, last update); map it onto your own tables freely.

1. Start with the app, not the connection

   From your dashboard, start a new project:

   Build a client portal for my consultancy. Clients sign in and see the status of their projects: name, phase, and latest update. I will connect the project data from my Supabase. Understated and professional, charcoal and white.

   What you should see: the app scaffold with sign-in and a placeholder projects view. Announcing the Supabase connection in the prompt means the agent designs for it rather than inventing its own table.

2. Connect your Supabase

   When the agent needs the data (or right away in Vault → Connectors), connect Supabase through its own popup: sign in and pick your project. That is the entire setup; the agent can now see your schema and build against it.

   What you should see: Supabase showing as Connected. Nothing about your data is copied or published by connecting; reads happen live when pages load, and every table starts visible to nobody. The Connecting Supabase page explains the model.

3. Point the portal at the real table

   The project data lives in my Supabase "projects" table. Show a signed-in client only the rows where the client email column matches their account email, newest update first.

   The agent will ask who should be able to see the table; choose people signed in to your app.

   What you should see: the preview's portal page showing real rows from your Supabase. Change a status in Supabase and reload the preview: the change is just there, because there is no copy and no sync.

4. Verify a client sees only their own rows

   Sign up in the preview with an email that matches one client in your data, and confirm the page shows that client's projects only. Then a second test account matching a different client: their rows, and only theirs.

   What you should see: two accounts, two disjoint views of the same table. If either account sees too much, say so in chat and re-test; this is the tutorial's most important step.

5. Control who can register

   A portal is invitation business. In Vault → Auth, set registration to Only people on your list and invite your clients' addresses; strangers who find the URL then cannot create an account at all. Details in Add sign-in.

   What you should see: signing up with an uninvited address is refused at the email step.

6. Publish and hand out the address

   Press Publish, walk the flow once as a client from a private window, then put it on your own domain. If even the marketing surface should be private, the "Require sign-in to view" wall in Public vs private apps closes the whole app.

   What you should see: a client signing in and landing on their projects, live from your Supabase, without you having exported, imported, or synced anything.

Where to take it from here

• Let clients leave a comment on a project: writes go to the app's own database, which is the two-source shape working as intended.
• Email a client when you set a phase to complete: the Resend guide.
• An internal admin page summarizing every client: the roles recipe.