Row level security test suite for Supabase

Dev toolWeb1 weekNext.jsSupabaseGitHub Actions

The idea

Every few weeks another indie hacker writes the same post-mortem: RLS policy wrong or missing, every user’s data readable by any authenticated session, found by a stranger. Supabase makes shipping a database trivially easy and makes verifying its access rules a manual chore, so the single most dangerous file in a Supabase app is the one with no tests.

The honest tool for this is pgTAP, and the target audience will never write pgTAP. The wedge is a declarative layer at the altitude they actually think: user A cannot read user B’s invoices, compiled down to impersonated queries with real JWTs, run in CI on every PR. Auto-generating a starter suite from the existing schema means the first run takes minutes and usually finds something, which is the whole sales pitch.

Who pays

The buyer is the solo founder or two-person team shipping a SaaS on Supabase, post-horror-thread and pre-audit. At 9 to 29 dollars a month it is priced as insurance against a company-ending tweet. Distribution: the Supabase Discord and r/Supabase, SEO on supabase RLS testing queries, and launch posts timed to the next public leak thread, which reliably arrives.

MVP scope

  • Connect a Supabase project and introspect tables plus policies
  • Auto-generated starter YAML suite covering cross-user and anon access per table
  • Suite runner with synthetic users, impersonated JWT queries and rollback
  • GitHub Action that fails PRs with a red/green assertion report
  • Automatic failure for tables with RLS disabled
  • Skip for v1: storage-bucket policy testing, edge function auth testing, non-Supabase Postgres, load testing, team seats
// Build prompt — paste into Cursor / Claude Code / Lovable / Bolt
Build RLSGuard, a testing tool for Supabase row level security policies. Stack: Next.js web app, Supabase (both as the product's own backend and as the target being tested), a GitHub Action for CI runs.

Core flow: user connects a Supabase project by pasting its URL and service-role key (stored encrypted, used server-side only, never shipped to the browser). RLSGuard introspects tables and existing policies, then auto-generates a starter suite in a declarative YAML format, e.g.: two synthetic users A and B; assert A can select own rows in invoices; assert A cannot select B's rows in invoices; assert anon cannot select anything in invoices. Users edit the YAML in an in-app editor with schema-aware autocomplete. Running a suite: create the synthetic users via the admin API, seed minimal rows per fixture definitions inside a transaction, execute each assertion as an impersonated query (sign in as the synthetic user, use their JWT), report pass/fail, then roll back and delete the users.

The GitHub Action runs the same suite headlessly on every PR and fails the check on any red assertion, with a summary comment listing exactly which user could read which table they should not.

Pages: landing with a horror-story-driven pitch and live demo, project dashboard with latest run status per suite, suite editor with run output side by side, docs page for the YAML format and Action setup.

Implementation notes: always test against a branch or staging project, and refuse to seed when the connected database is flagged production. Detect tables with RLS disabled entirely and report them as automatic failures.

Pricing: free for 1 project, 9 GBP/month for 3, 29 GBP/month unlimited plus CI.

// More Dev tool ideas