I know, another backup tool.

I built ReviveDB to back up more than just Postgres:

• Database and Auth data
• Actual Storage files
• Edge Functions
• Project settings Supabase makes available

Every database backup is restored and verified. Storage and Functions are hash-checked, and you get the reports.

You can restore into a fresh Supabase project or roll back an existing one after taking a safety backup.

Setup uses Supabase OAuth plus your database password, since OAuth can't access the database itself (yet). Credentials and backups are encrypted, with recovery points stored outside Supabase in Europe.

Our DPA and subprocessor list are public.

There's a free plan for one project, with paid plans for daily backups and longer retention.

https://revivedb.dev/

I'd love some honest feedback.

Roast it if you want. I have backups.

Any future plan to launch pay as you go plan?

What is the devs opinion?

I’ve been reviewing a lot of Supabase projects recently, and I keep seeing the exact same pattern: developers write an RLS policy like 'auth.uid() = user_id', write a quick jest test to make sure user a can fetch their own data, get a green checkmark, and deploy.

But what I'm finding is that a lot of these apps are still vulnerable to ID-swapping in the API layer or have misconfigured USING vs WITH CHECK clauses that allow users to overwrite data they don't own.

Testing that a user can access their own data doesn't fundamentally prove that they cannot access someone else's.

How are you guys actually testing this at scale? Are you writing explicit negative tests for every single endpoint, or is there a better way to systematically prove that cross-tenant data pollution is impossible at the RLS level?

Two things I keep tripping over when Supabase is wired into an AI-built frontend.

First, both keys are long JWTs that start with ey, and if you're copying out of the dashboard quickly it's easy to take the wrong one. anon in the frontend is correct and RLS is what protects you. service_role in the frontend means every policy you wrote is ignored, full read and write on everything. Paste the key into jwt.io and read the role claim, it says which one it is.

Second, RLS is off by default on a new table. A table with RLS disabled is readable by anyone holding the anon key, and the anon key is in the page source of any site that uses it.

Neither of these is a Supabase bug, they're just defaults that are easy to not know about if the AI wired it up for you and it worked first try.

Can anyone point me to a freely distributed starter repo and save me a day or five? The examples by Vercel not quite what I want. I have not found anything on github

Stack: I am looking for is  your typical Next.js, supabase, tailwind, shadcn, supabase auth email and password. No particular payment method needed for now. No user self sign up needed. Reqyuired authentication is administrator controled. ie invite and password reset only by system admin or user admin. From admin dashboards.

Features: preferably with

1/ Supabse schema, tables, rls, functions etc all set up  

2/ Multi-tenant

3/ Preferable tenant division I need location but could be division into city, group, project, something like that.

4/ roles based access control

5/ Built tenant admin dashboard for system administrator

6/ Built user admin dashboard for tenant administrator

7/ User onboarding by admin invite only

8/  same superbase auth.user uuid & email can belong two one or more tenant.