Everything you need to operate Suparbase.

Quickstart

Suparbase takes about three minutes to go from zero to a usable admin workspace pointed at your Supabase project.

1. Sign up at /signup. Email and a 12+ character password, or GitHub OAuth if the operator has enabled it.
2. Save your project by pasting the Supabase URL and a key (any role: anon, authenticated, or service_role). The key is AES-256-GCM encrypted before the row commits to the database.
3. Open the dashboard. The first load runs an AI schema analysis (optional, gracefully degrades to heuristics) so tables get the right archetype, display name, and column priorities automatically.
4. Click a table. Browse rows, edit inline, bulk update, export CSV, search across every table with Cmd-K.

Connections

A connection is a saved Supabase project. Each connection holds:

• url: your project URL, e.g. https://abc.supabase.co
• encrypted_key: the PostgREST key, encrypted at rest. Used for every CRUD operation and for the Storage / Auth admin endpoints.
• encrypted_postgres_url (optional): a direct Postgres connection string. Only the RLS debugger and SQL playground read this. The URL is never echoed back over the wire: the connection summary only exposes hasPostgresUrl: boolean.

The role you store determines what works: a service_role key gets you the full Auth users admin page; anon / authenticated keys can still read and write through PostgREST under whatever RLS policies you've set.

Security model

Suparbase exists because storing a Supabase API key in a browser is a foot-gun. The whole product is built around three rules.

1. The key never reaches the browser

Every PostgREST request goes through an authenticated Next.js route handler. The session cookie identifies you; the route handler looks up your connection, decrypts the key in memory, and forwards the request to Supabase. Your browser only ever holds the session.

2. Encryption at rest

Keys are AES-256-GCM encrypted with a key from SUPARBASE_ENCRYPTION_KEY. The plaintext exists only as a request-scoped local variable inside the server. No file, log, or metric ever sees the bytes.

3. Audit every write

Every successful insert, update, and delete writes a row to audit_log with the user, connection, table, primary key, verb, and (when available) before / after snapshots. This is what powers the row history panel.

AI assistant

Click Ask AI in the bottom-right of any workspace page. The agent runs server-side against your stored OpenRouter key and has four read tools and three write-proposal tools.

Read tools

• list_tables: catalogue with AI-inferred display names and categories.
• get_table_schema: full column list with types, PKs, FKs.
• query_rows: filtered SELECT (up to 50 rows).
• count_rows: aggregate count with filters.

Write proposals

The agent never writes directly. propose_update, propose_insert, and propose_delete return a payload with the planned change and a 5-row preview. The UI renders a diff card; the human clicks Apply, which re-validates and runs through the audit-logged proxy.

Bring your own OpenRouter API key on Settings → AI. Tool-capable models are tagged tools in the picker.

RLS debugger

PostgREST hides pg_policies from anon / authenticated keys, so this page needs a direct Postgres URL. Add one on the RLS page itself: the input renders as a setup card the first time you open it.

• The policy browser groups every public-schema policy by table with USING and WITH CHECK clauses formatted as code.
• The simulator runs SELECT / INSERT / UPDATE / DELETE inside a transaction that always rolls back, with the role and request.jwt.claims you pick. You see allow / deny + visible row count per verb.

SQL playground

Same direct-Postgres credential as the RLS debugger. Read-only by default: every query runs inside BEGIN; SET TRANSACTION READ ONLY; SET LOCAL statement_timeout = N; ...; ROLLBACK, so a rogue write is rejected by Postgres itself.

Write mode is a separate toggle behind a confirm dialog. Write-mode queries burn the same rate-limit bucket as PostgREST writes and record an audit_log entry containing the SQL text.

Storage browser

Two-pane layout: bucket list on the left, object browser on the right. Drag-drop upload (up to 50 MB per file), multi-select bulk delete, per-object Sign button that copies a 1-hour signed URL, Copy button for the public URL on public buckets.

Auth users

Wraps Supabase's Admin API (/auth/v1/admin/*). Invite a new user, generate a recovery link, ban / unban (one-year ban_duration), or delete. The whole page requires a service_role key; with a lower-privilege key, the page renders a banner explaining what to change.

Audit log

Every write through the proxy writes a row to audit_log. Each row carries the user, connection, table, primary key, verb, HTTP status, and (when available) snapshot columns.

• The dashboard's Recent activity panel shows the last 10 entries with click-to-row navigation.
• Each row detail page has a History panel that filters this table by primary key.
• Diffs are computed against the previous entry's afterRow (or beforeRow for deletes).