Detect Supabase schema drift after migrations
A one-time audit tells you about today. The problem with AI-assisted development is not the first mistake, it is the fortieth prompt, which drops a policy nobody re-reads.
VibeGuard takes a catalog snapshot on every scan and diffs it against the previous one, so a change is visible as a change rather than as a line in a list you have stopped reading.
Rules that check this
- criticalRow Level Security disabled
RLS_DISABLED - criticalPolicy always evaluates to true
RLS_TAUTOLOGY - highRLS enabled but no policies
RLS_NO_POLICIES - highStorage bucket is public
PUBLIC_BUCKET_EXPOSURE
What counts as drift
Tables added or removed. Policies added, removed, or rewritten. RLS toggled on or off. A storage bucket flipped to public.
A new table with correct policies produces no findings but is still drift worth showing, and a policy edited from one safe form to another is exactly what a reviewer wants to see even though nothing is wrong.
Regression is its own state
Findings are matched across runs by a stable key, so a problem that was fixed and has come back is reported as a regression rather than as something new. That is the more alarming of the two, and the one worth interrupting someone for.
Alerts fire on transitions
Something appearing, coming back, or going away. A project that has been broken for a week pages you once. This is also what makes a retried scan idempotent: it re-reads the finding history, sees the rows already recorded, and produces no transitions.
Frequently asked
- How often does it scan?
- Hourly on Indie, every 15 minutes on Team, and daily on the free plan. Snapshots are retained on each scan run so a rule change can be replayed over history.
- Where do alerts go?
- Slack, Discord, email, or a plain webhook, with a severity threshold per destination.
Check your project in about ten seconds
Paste a URL. No signup, no writes, nothing stored.
Run the free audit