Connecting your Supabase project

Your app can read live from a Supabase project you already own. Your product catalogue, your class timetable, your listings, your stock levels. Whatever is already in there.

Nothing is copied. Every read goes to your project at the moment someone loads the page.

How it works

Connect once through the Supabase popup. That is the whole setup.

After that you just describe what you want. The agent looks at your database, finds the tables it needs, and builds pages that read from them. You do not pick tables from a list or configure anything.

Your app has two data sources, and they hold different things

This is the part worth understanding, because it explains everything else.

Your app's own database holds anything that belongs to one person. Accounts, orders placed in your app, bookings, saved items, uploads. Each person sees only their own, and that separation is handled for you.

Your connected Supabase holds anything that belongs to the app rather than to a person. The menu, the timetable, the price list, the properties.

So a booking app reads the class timetable live from your Supabase, and writes the booking into the app's own database. That is the shape almost every app takes.

Who can see it

When the agent builds a page that reads one of your tables, it asks you once who should be able to see it:

• Nobody. The published app never reads it. The agent can still see the table while building, so it writes correct code around it.
• People signed in to your app. What that means depends on your app: if anyone can sign up, it means anyone who creates an account.
• Anyone who visits. Including people who have not signed up, and search engines.

Everything starts at nobody. Choosing a table for the agent to build with never publishes it.

You can change any of this later in Vault, Connectors, Supabase.

If a table looks like it holds personal information, we say so, and we will not make it readable by anonymous visitors from a chat message. That decision lives in the Vault panel behind a separate confirmation.

Your data is always current, and it is never ours

There is no sync, no refresh button, no schedule, and no "last updated" stamp, because there is nothing to update. Change a price in Supabase and the next person to load the page sees the new price.

Vaulter does not keep a copy of your data. It passes through and is not written down anywhere. What we do record is that a read happened: which table, how many rows, how long it took. Never the contents.

What Vaulter can and cannot do in your Supabase project

Can: read from the tables in your project, to answer your questions while you build and to fill in pages in your published app.

Cannot: write anything. Not insert, not update, not delete, not change your schema. Reads are the only thing the connection can do.

When you connect, Supabase's own consent screen will mention broader access than this. That is Supabase's standard connector permission and we cannot narrow what it says. What we can tell you is what we actually do with it, which is the list above.

You can disconnect at any time, and reads stop immediately.

If your Supabase project is on the free plan

Supabase pauses free projects after about a week without activity. While a project is paused, the parts of your app that read from it will not load, until you resume it from your Supabase dashboard.

Everything stored in your app itself keeps working normally. Only the sections reading from your Supabase are affected, and visitors see a short message rather than a broken page.

We can offer to read one row a day to keep the project active. It is off unless you turn it on, and it uses a small amount of your Supabase free allowance.

What this does not do yet

• No writing back. Your app cannot save anything into your Supabase project. Things your users create live in the app's own database.
• No per-person rows from your Supabase. A connected table is shown to everyone in the audience you picked, or to nobody. If you need each customer to see only their own record, that belongs in the app's own database, and the agent can build it that way.
• No column-level control. A table is shared whole, or not at all.