Skip to content

Coming from Tadabase

Row-level security before you go live

The one setting people forget — and the API is fail-closed until you set it.

The master switch

Vibe apps read and write your data through the Domain API, as the signed-in end-user. For your role and record rules to apply to those calls, one app-level switch must be on:

This is deliberately fail-closed: an app that hasn't opted in cannot accidentally expose data over the API.

Per-table security and scope

On each table you expose, turn on row-level security and set its scope — where those rules apply:

ScopeMeaning
Only APIRLS applies to Domain API calls (what Vibe uses).
App onlyRLS applies to the classic builder front-end only — invisible to the API.
BothRLS applies to both surfaces.

Write real policies — don't rely on defaults

With RLS on, a table denies by default: no policy means no rows. Add role-based policies for who can select, insert, update, and delete, and which records each role reaches ("their own," "their team's," etc.). Field-level rules (hidden / read-only / masked) are enforced server-side too.

Ready to build

Skip the docs.
Just describe it.

Tadabase AI builds it, hosts it and keeps it running. Real backend, real domain, real app.

Start Building