Continuous RLS monitoring for Supabase

How a scan works

Each run takes one catalog snapshot and evaluates every rule as a pure function over it. That means a scan is a fixed number of round-trips regardless of rule count, and a new rule can be replayed over stored snapshots before it is switched on for alerting.

Findings are then diffed against the previous run and classified as new, regressed, or resolved.

From the terminal, and from CI

The same engine runs as a CLI against any connection string, printing the findings and the generated SQL.

npx rowshield scan --db-url "$DATABASE_URL" --fail-on high --sql

Alerts worth reading

Alerts fire on transitions only, with a severity threshold per destination. A project that has been broken for a week pages you once, and a medium-severity index finding does not wake anybody.

What the first week looks like

Day one connects the project and runs the first scan, which is usually the noisy one: every pre-existing finding appears at once as created. Read it as a baseline inventory rather than a crisis — severities sort what matters now from what belongs on next sprint’s list, and remediation SQL makes the critical fixes an afternoon rather than a project.

Days two through seven are where continuous monitoring diverges from any audit you have run before. Each scheduled scan diffs against the last; most produce nothing, which is the point — silence means nothing moved. When something does fire mid-week, it arrives as a single transition with context: this policy appeared, that fix regressed, this bucket went public.

By the end of the first week most teams have tuned alert thresholds per destination so chat receives only what deserves interruption, and email keeps the rest. The cadence follows your plan — daily on Free, hourly on Indie, fifteen minutes on Team — and findings are never withheld at any tier, because ransoming security truth behind a plan would defeat its purpose.

The same engine runs everywhere, which matters more than it first appears. The CLI wraps identical rules against any connection string with CI-friendly exit codes; the probe runs from a browser with no account at all. A finding you reproduce locally will read the same in the dashboard — there is no hosted-only truth to reconcile, and teams who later move between plans or self-host the scanner lose nothing they already knew. That portability cuts both ways in the best sense: try the hosted dashboard while evaluating, keep the CLI in CI permanently, and treat both as views over one engine whose findings will not contradict each other between surfaces. It is the same scanner everywhere, which makes its findings boring in exactly the right way. Consistency across surfaces is what lets a team trust one number during an incident instead of reconciling three tools first.

Frequently asked

How much does it cost?

Indie covers 3 projects at hourly scans. Team covers 15 projects at 15-minute scans and adds Discord and custom webhooks. Current rates are on the pricing page, and annual billing costs ten times the monthly price. Findings and remediation SQL are never withheld by plan.

What access does it need?

A Postgres connection string for the project you want monitored. Grant it catalog read access only; it never selects from your tables.

Can I self-host it?

The scanner, probe and CLI run anywhere Node runs, against any connection string, with no RowShield service involved.