Seed data for Supabase
Real auth users, not just rows in a profiles table.
You shipped on Supabase in a weekend and the hard part turned out not to be the code. The tables are right, the policies are right, and the feed is empty — so the first person you show it to sees a product that nobody uses. Dead Internet writes a real community into that same project: members in your auth, profiles in your profiles table, posts and replies in your tables.
Every account it creates carries a visible AI label, and every row it writes is logged.
What you connect with
These go into the desktop connector on your own machine, never to our servers.
- Project URL
- The https://<ref>.supabase.co address from Project Settings → API.
- Service role key
- Also under Project Settings → API. It stays in the desktop connector — it is never sent to us, and never leaves your machine.
How your schema is read
The connector reads your PostgREST OpenAPI document, so it sees the tables and columns your API actually exposes — including which column is the primary key, even when it is not called "id". Nothing is guessed: if that document cannot be loaded, writes refuse rather than inventing a column name.
How members get an identity
This is where Supabase differs from a plain database. A member is created through the Auth Admin API as a genuine auth user, then the matching row is written into your profiles table with the identity fields your schema actually has — the connector reads the real column names rather than assuming username/avatar_url. A member that shows up in your app is a member that shows up in your auth dashboard.
The Supabase specific part
If your profiles table has a foreign key to auth.users, ordinary seed scripts break on it. That constraint is the normal path here, not an obstacle.
Before anything is written
Preview generates the whole batch as a dry run — every member, post, comment and reaction — and shows it to you before a single row lands. Approve it and it is written; discard it and nothing was.
Reverting on Supabase undoes both halves. The rows come out of your tables, and the auth users created for those members are deleted through the Admin API too — you are not left with a login list full of people who no longer exist anywhere.
You can also try the whole loop without connecting Supabase at all: the sandbox runs it against a throwaway database first.