Request with service_role key throws row level security

[insomenia-youngbo]

In backend api I tried to insert a data with service_role, but it throws rls error.
As I know service key bypasses rls. is it a bug or it bypasses in specific condition?
It works when I insert to other tables.

# admin is supabase with service_role key

const { user } = await admin.auth.signUp({
	email,
	password: uuid
});

await admin.from('account').insert({
	id: uuid,
	user_id: user.id,
	uid,
	provider,
	email,
	access_token
});

{ 
  message: 'new row violates row-level security policy for table "account"',
  code: '42501',
  details: null,
  hint: null
}

[GaryAustin1]

When you signin a user, the user’s jwt will be used as the authorization header not the default key.

[schwartzadev]

Did you resolve this? @insomenia-youngbo I also have this issue

[GaryAustin1]

If you are using service role in a server client then it has to be a standalone client. It can't be used for user sessions. In particular an auth-helpers/SSR client can't be used for service_role.

[jameschan617]

I fix this by add new SERVICE_ROLE_CLIENT:

export const createAdminClient = () => {
  return createSupabaseClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.SUPABASE_SERVICE_ROLE_KEY!,
    {
      auth: {
        autoRefreshToken: false,
        persistSession: false
      }
    }
  )
}

Without setting up cookies, the instance will use your key instead of JWT.

[solvionsolutions]

What's happening is that your admin.auth.signUp() call sets a session on that same client, so by the time you run admin.from('account').insert(), supabase-js has swapped in the newly created user's JWT as the Authorization header instead of your service_role key. That's why RLS kicks back in and you get the 42501 — the insert is running as the just-signed-up user, not as the service role. It also explains why it worked on your other tables: those probably had policies that happened to allow the user.

The fix is to keep a dedicated server-only client for privileged work and never let it store or refresh a session:

import { createClient } from '@supabase/supabase-js'

// server-side ONLY — never ship this key to the browser
export const supabaseAdmin = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_SERVICE_ROLE_KEY,
  { auth: { persistSession: false, autoRefreshToken: false } }
)

Use supabaseAdmin for the .insert() and keep the auth/signUp flow on a separate client, and the service_role key will actually bypass RLS like you expect. The persistSession: false bit is the important part — without it, any auth call on that instance quietly overrides the key. Just make sure this client only ever lives on the server, since the service_role key ignores every policy you have.

I wrote up the full breakdown of this exact error here: https://www.guardlayer.io/blog/supabase-new-row-violates-rls-policy