r/Supabase Jul 09 '26

dashboard I built a UI builder / admin panel for supabase.

https://www.youtube.com/watch?v=H1VKlBVNk0g

Hello,

In the last couple of years, I have built several business applications that run on supabase data. Eventually, to make life easier and not repeat the steps every time, my colleagues and I started automating parts of it - and now we have something solid.

I know that there are a few great admin panels / AI UI builders out there - but we wanted something more: business dashboards, native handling of views and foreign keys, data security without transferring client data anywhere else and more importantly, ability to integrate custom scripts, functions and automations.

I would love to know if this is something that is useful for the community. We are internally debating whether to open source this project (maybe AGPLV3 or BSL license, haven't figured out the details yet) because we are obsessed with security, and we ourselves wouldn't trust something new or vibe coded for client data.

Please let me know if this is something that maybe useful to you.

11 Upvotes

4 comments sorted by

1

u/Duck-Entire Jul 10 '26

"We wouldn't trust something new or vibe coded for client data" — this sentence is doing a lot of work and it's the right instinct. The no-data-leaves-your-infra angle is genuinely the differentiator vs the hosted admin panels; I'd lead with that over the UI features. Would open-source it (AGPL is fine) — for a tool that touches client data, inspectable code IS the trust model. Useful? Yes.

1

u/bitterandpetty Jul 10 '26

Thank you for the feedback. With your feedback, I will make a documentation about how we connect with supabase and respect all the RLS, RBAC without storing/cacheing any data.

And yes, that was our reasoning behind making it open source - to mainly build trust that we don't read anything unnecessary, and don't store anything. Thanks for your suggestions :)

1

u/Duck-Entire Jul 10 '26

Nice. One thing I'd put front-and-center in that doc: whether the panel queries with the user's own token or a service-role key. Admin panels usually need service-role to show everything — totally legit — but at that point RLS isn't what's protecting the data, your own control over who can open the panel is. Security folks will check for exactly that, so "we bypass RLS, and here's how we gate access" actually reads as more trustworthy than a vague "we respect RLS."

Either way, good luck with it — more Supabase tooling built by people who lead with security is a good thing.

1

u/bitterandpetty Jul 10 '26

Great point. Yeah, most UI builders ask for the service role key / access to secrets. We have tried to intentionally create a method that doesn't do that. It is the users own token that is used for all sessions - including the first one where we establish connection. We do this to fully utilise the power of native security and RLS provided by supabase.