Skip to content
VibePatchers

Fix guide ·

How to give VibePatchers access (and revoke it after)

For a Rescue we need two things: a GitHub repo invite and a dedicated Postgres role created just for us. You should never send us (or anyone) your Supabase service-role key, your main database password, or your Stripe secret key.

Not sure how? We’ll walk you through access on a quick call or email: hello@vibepatchers.com.

What this role can do (plainly)

The role below can change your schema and row-level security policies. Anyone who can change policies can also read data, so this role can read your data. We only use it for the agreed fixes, we test with throwaway test accounts, we don’t export your users’ data, and we delete any copies at delivery (see our terms and privacy policy). Revoke it as soon as we deliver.

1. Invite us to GitHub

In your repo: Settings → Collaborators → Add people, then add MontourLink with write access.

2. Create the role

In Supabase, open SQL Editor and run (replace the password with a long random one). We tested this exact script on a fresh Supabase project in October 2026.

create role vibepatchers with login password 'REPLACE-WITH-A-LONG-RANDOM-PASSWORD'
  valid until '2026-12-31';  -- set a date ~2 weeks out

grant usage, create on schema public to vibepatchers;
grant select, insert, update, delete, references, trigger
  on all tables in schema public to vibepatchers;
grant usage, select on all sequences in schema public to vibepatchers;
grant execute on all functions in schema public to vibepatchers;

-- Lets policies we write call auth.uid() / auth.jwt()
grant authenticated to vibepatchers;

-- Only the owner of a table can change its RLS policies, so we temporarily
-- take ownership of your public tables. You get them back in step 4.
grant vibepatchers to postgres;
do $$
declare t record;
begin
  for t in select tablename from pg_tables
           where schemaname = 'public' and tableowner = 'postgres'
  loop
    execute format('alter table public.%I owner to vibepatchers', t.tablename);
  end loop;
end $$;

The valid until date makes the login expire automatically even if you forget to revoke it.

Why not grant postgres to vibepatchers? Supabase refuses it (permission denied to grant role "postgres"), and without ownership a role gets must be owner of table when it touches policies. Temporary table ownership is the narrowest thing that works: it covers your public tables only, not auth, storage or your project settings. It still lets the role change policies and read data in those tables, so revoke it when we deliver.

Prefer not to run SQL? Invite us to your Supabase organization (Organization Settings → Team → Invite) with the Developer role instead, and remove us after delivery. Email us first so we know which address to invite.

3. Send us the connection details

Send the role name (vibepatchers) and the password over the channel we agree by email. Your project’s host is under Project Settings → Database → Connection string.

4. Revoke it after delivery

When we deliver, run:

-- Gives every table back to postgres (including any we created)
reassign owned by vibepatchers to postgres;
drop owned by vibepatchers;
drop role vibepatchers;

Then remove MontourLink from your GitHub repo collaborators. Check with:

select rolname from pg_roles where rolname = 'vibepatchers';

It should return zero rows.

Rather have it fixed and proven?

Our flat-fee Rescue fixes this and hands you a before/after verification report within 48 hours of working access.

See pricing