How do we query server-side as postgres or service_role with the new secret key locally?
I tried this and it doesn't seem to work:
import { createClient } from '@supabase/supabase-js'
const supabase = createClient(supabase_url, service_role_key, {
auth: {
autoRefreshToken: false,
persistSession: false
}
})
I put the secret key where service_role_key is and got a permission denied. Note that I'm querying a non public schema but I did add it to .toml and granted usage.
28 Replies
If you plug in the legacy service_role key does it work?
What is the exact error?
Are you on the latest CLI? There were fixes to enable this a week or so ago.
By default the API server points to the public schema. You can enable other database schemas within the Dashboard. Go to Settings > API > Exposed schemas and add the schema which you want to expose to the API.
Note: each client connection can only access a single schema, so the code above can access the other_schema schema but cannot access the public schema.
I thik it might be this, damn it lol. Let me try this and report back. I do have querys that span 2 schemas, so I gotta refactor a bit
I know how the API works. Just don't know if it might be a local issue with the new SB.... keys.
Re your q, yes previously, SERVICE_ROLE_KEY worked and did multiple schemas too.
I'm on the latest CLI
Then it should take SB... service_role just like the JWT for service_role.
Permission would not be the API settings that would be a PostgREST error for not found in schema cache.
This was when they fixed SB... new tokens working. Seemed to solve several issues with that for actual users... https://github.com/supabase/cli/releases/tag/v2.46.1
GitHub
Release v2.46.1 · supabase/cli
Changelog
Bug fixes
f5e1774: fix: replace auth header for backwards compatibility (@sweatybridge)
d81798f: fix: replace auth header for backwards compatibility (#4206) (@sweatybridge)
Others
f53...
So using this key is what they fixed:
I THINK that is provided at startup with the other keys/urls, but don't use local dev.
Permission error though almost seems like it gets through. I would expect a JWT error if wrong key was sent.
But grant to role service_role to the schema would be the same for the old service_role key and the SB_secret one.
But grant to role service_role to the schema would be the same for the old service_role key and the SB_secret one.
Hmm, thanks for the note. Let me try to add db: 'my_schema' and see. Could be that I just lucked out somehow before.
Check the actual Dashboard logs (I assume they are there in local) for API Gateway, PostgREST and Postgres. Maybe more specific error messages.
Tried db: 'custom_schema' createClient with SB_key. Same error
"172.18.0.9 2025-10-07 00:51:07.255 UTC [18404] authenticator@postgres ERROR: permission denied for schema admin at character 134"
[
{
"host": "db-default",
"parsed": [
{
"error_severity": "ERROR",
"timestamp": "2025-10-07T00:51:07.255663084Z"
}
]
}
]
So you have a custom schema called admin?
Also check the Postgres log.
Normally you should use .schema('my_schema') for REST calls versus setting the schema for the client now, but either should work.
You got it lol
I pasted the above from the postgres log
Just confirming its the one highlighted right
yea all my queries use .schema('admin')
Kinda similar to my other issue, everything was working fine. I upgraded keys and bam
OK. Seems like it is not granted correctly for the role coming in.
I'll wait and chill for a bit, probably will get patched soon
If you grant service_role and it worked for service_role old key then seems like you local is not at the CLI version that uses the new keys... Is your CLI version past 2.46.1 then it would not be there... BUT it should be a totally different error.
You are not somehow using the supabase client you created with a user session later are you? If so that wipes the service_role and it becomes authenticated role.
Nah, so I always update to latest CLI but I was using old keys forever
So supabase status showed SB keys but I did not update my keys
somehow that was totally fine so I thougth hey I'll update it later
Seems like it's already reported:
https://github.com/supabase/supabase-js/issues/1568
GitHub
cannot authenticate supabase admin / service_role client with new a...
Bug report I confirm this is a bug with Supabase, not with my own application. I confirm I have searched the Docs, GitHub Discussions, and Discord. Describe the bug Creating an admin client with th...
That is before the fix I suspect.
It definitely was not implemented at first and then broken and 2.46.1 fixed it for some at least.
Can you run
supabase --version in this project in your terminal and report back the version number? saying the latest version isn't very helpful.2.48.3
Try running
supabase stop --no-backup and then supabase start again. Do note that this will delete any existing data you have in your local database for this project as it deletes the docker volume for this project. Sometimes keeping a stale/old docker volume can cause unexpected issues.Will do. Let me figure out how to back up my current work first lol. Then I'll report back
Ok just tried it, same error. I did make sure except for anon, authenticated + service_role has both schema and table privileges
Out for the night, but I would add anon as a quick test to rule out wrong key, then back it out.
Yep great suggestion - tried this too, when I remove RLS (allow anon) it does work.