Upcoming changes to Supabase API Keys

[kangmingtay]

Timestamp	Latest Update
17th June 2025	Early access to new API keys launched, available on all projects. Please give them a try and raise any issues in this discussion for the team to fix or address.

We’re changing the way API keys work in Supabase to improve your project’s security and developer experience. Refer to the timetable below for key dates and info on actions you may need to take in the future.

This change starts out as early preview and is opt-in. No action necessary until at least 1st November 2025. We strongly encourage you to give the new API keys a try!

What's the change?

These are the planned changes for the API keys:

• anon and service_role keys remain available for use.
• A single publishable key with the form sb_publishable_... can be used to replace the anon key.
• You can create multiple secret keys with the form sb_secret_.... You can also choose not to have a secret key if you don’t need one. Secret keys replace the service_role key.
• You can disable and re-enable the anon and service_role keys, as needed during the migration period.

Summarized, there are 4 types of API keys that can now be used with Supabase. This chart should illustrate it better:

Type	Format	Privileges	Availability	Use
Publishable key	sb_publishable_...	Low	Platform	Safe to expose online: web page, mobile or desktop app, GitHub actions, CLIs, source code.
Secret keys	sb_secret_...	Elevated	Platform	Only use in backend components of your app: servers, already secured APIs (admin panels), Edge Functions, microservices, etc. They provide full access to your project's data, bypassing Row Level Security.
anon	JWT (long lived)	Low	Platform, CLI	Exactly like the publishable key.
service_role	JWT (long lived)	Elevated	Platform, CLI	Exactly like secret keys.

Timetable

Key Dates	Description	User Action Needed
June 2025	Early preview and Introduction of new API keys. New projects will automatically generate both new API keys and legacy API keys to help ease the transition. Existing projects can continue to use the legacy API keys and can opt in to use the new API keys by manually generating them.	No immediate action needed. We recommend trying them out and preparing your projects for a future migration.
July 2025	Full feature launch of new API keys. Feedback and issues seen in the early preview period to be resolved.	No immediate action needed. We strongly recommend that you migrate to use the new API keys or start planning for it. Dashboard and docs will focus on new API keys.
November 2025	We will start sending you monthly reminders to migrate off legacy API keys and start using the new keys. Projects restored from 1st November 2025 will no longer be restored with the legacy API keys. New projects no longer have anon and service_role available for use.	You are highly encouraged to migrate off to use the new API keys before this date since paused projects that are restored risk being broken as they won’t have the legacy keys.
Late 2026, TBC	Legacy API keys will be deleted and removed from the Docs / Dashboard.	You have to migrate to use the new API keys by this point or your app will break.

Why are we doing this?

Since the start of Supabase, the JWT-based anon and service_role keys were the right trade-off between simplicity and relative security for your project. Unfortunately they pose some real challenges in live applications, especially around rotation and security best practices.

The main reasons for making this change are:

• Tight coupling between the JWT secret (which itself can be compromised, if you mint your own JWTs) and the anon (low privilege), service_role (high privilege), and authenticated (issued by Supabase Auth) Postgres roles.
• Inability to independently rotate each aspect of the keys, without downtime.
• Inability to roll-back an unnecessary or problematic JWT secret rotation.
• Publishing new versions of mobile applications can take days and often weeks in the app review phase with Apple's App Store and Google's Play Store. A forced rotation can cause weeks of downtime for mobile app users.
• Users may continue using desktop, CLI and mobile apps with very old versions, making rotation impossible without a forced version upgrade.
• JWTs had 10-year expiry duration, giving malicious actors more to work with.
• JWTs were self-referential and full of redundant information not necessary for achieving their primary purpose.
• JWTs are large, hard to parse, verify, and manipulate -- leading to insecure logging or bad security practices.
• They were signed with a symmetric JWT secret, preventing future development of Auth features.

Start using the new API keys

It’s easy to start using the new API keys. You can opt in in the Supabase dashboard. This will create the default publishable key and a single secret API key.

For the most part, you can substitute the sb_publishable_... and sb_secret_... values anywhere you used the anon and service_role keys respectively. They work roughly the same in terms of permissions and data access.

You can initialize any version of the Supabase Client libraries with the new values without any additional changes, and we don't expect any backward compatibility issues.

Key differences to be aware of

We've redesigned how the Supabase hosted platform deals with API keys with a few key goals:

• Advanced and enterprise-ready security features
• Zero-downtime rotation
• Solid foundations for the introduction of asymmetric JWT support and other Auth features requiring this

To achieve these, the new API keys have some subtle differences from anon and publishable:

• Permission and access control. Secret keys are hidden by default and need to be individually "revealed." Each event appears in your organization's Audit Log.
• Instant revocation. By deleting a secret key it is instantly revoked.
• Forbidden use in a browser. Using a secret key in a browser is no longer possible and will always fail with HTTP 401 Unauthorized.
• Limitation with Realtime: Connections last 24 hours when there’s no signed in user, or when using a secret key. Sign users in to extend connections indefinitely.
• Limitation with Edge Functions: Edge Functions provide the option --no-verify-jwt which means they can be called without knowing any API key. You will need to apply this option to functions you are protecting without it.
• Use of the Authorization header. It is no longer possible to use a publishable or secret key inside the Authorization header — because they are not a JWT. Instead pass in the user’s JWT, or leave the header empty. For backward compatibility, it is only allowed if the value in the header exactly matches the value in the apikey header.

We believe these limitations are minor and not likely to impact even a single-digit percentage of existing customers. Should you find any additional limitation do not hesitate to bring it up in this discussion or via Supabase Support.

[Peterksharma]

Is this live?

[j4w8n]

It is not live yet. There's been no further timelines, aside from "Q4".

[kangmingtay]

Hi @Peterksharma and @j4w8n, we've updated the discussion:

Update: Changes to Supabase API Keys will not be released in Q4 2024 because it needs further development work. We will finalize the timeline and announce the updated timeline in Q1 2025.

[hf]

It is now.

[StevenStavrakis]

Dang. I was looking forward to an improved auth flow.

[hodakl099]

Dang. I was looking forward to an improved auth flow.

Dang it me too!!!

[rishabhsingroha]

us

[dk-flpra]

Bro, but it does not change anything on the auth flow. Just the way how we manage and rotate secret changes.

[rishabhsingroha]

Correct, this doesn’t impact the auth flow. It’s mainly about improving how we handle and rotate secrets.

[sdocquir]

Would love to get an updated timeline for this, even if it's Q2/3/4 2025

[zachwaterstories]

Also looking for a timeline here. Any info - is helpful for our roadmap.

[o1Suleyman]

Supabase really needs to focus up on this. It's hampering their adoption

[StevenStavrakis]

@o1Suleyman Don't worry, they'll ship five more AI features that barely work and no one uses, instead.

[sourman]

I found the assistants integration in supabase one the best integration by far. Helps me as I am an SQL noob

[rishabhsingroha]

bro supabase is the future acc to me its literally the best
just hold up a little
facing some issues myself but i have faith in them

[Mandalorian007]

Will these custom api keys work for creating a rest api on an edge function and letting user authorize with an api key?

[rishabhsingroha]

wait what?

[kengokawano]

Existing projects can continue to use the legacy API keys and can opt in to use the new API keys by manually generating them.

How can I manually generate the new API keys for an existing project?

[GaryAustin1]

@kengokawano you have to generate a new JWT secret. All keys will change and need to be updated where you have applied them.

[jhwheeler]

@GaryAustin1 Are you sure about this? When we did this, it created a new set of legacy anon/service_role keys, rather than the new standard of publishable/secret keys.

@kengokawano Based on the discussion, this is not live yet (see this comment: https://github.com/orgs/supabase/discussions/29260#discussioncomment-11612891).

[j4w8n]

@jhwheeler, Gary is correct in how it's done for an existing project, but you are correct that it won't work yet because they haven't released the feature.

I think Gary was just trying to give a straight answer to the question @kengokawano was asking.

[GaryAustin1]

Yes, I read his question as how to generate new keys currently. Not how to generate THE new keys. Sorry for the confusion.

[jhwheeler]

Thank you for clarifying!

[Sohrab-tech1]

Is there an updated timeline for the new keys, if not when can there be one?

[CalvinWilkinson]

Quick question:

I have some migrations where I created a public.user table and in the sql it is using the term service_role for the permission. With the service_role being replaced by secret, I assume that migrations will not work and need to be updated?

Do we just swap out the word service_role with secret and we are good to go?

Here is the sql:

create table "public"."user" (
    "id" uuid not null default gen_random_uuid(),
    "created_at" timestamp with time zone not null default now(),
    "email" text not null,
    "first_name" text not null,
    "last_name" text not null
);


alter table "public"."user" enable row level security;

CREATE UNIQUE INDEX user_pkey ON public."user" USING btree (id);

alter table "public"."user" add constraint "user_pkey" PRIMARY KEY using index "user_pkey";

grant delete on table "public"."user" to "anon";

grant insert on table "public"."user" to "anon";

grant references on table "public"."user" to "anon";

grant select on table "public"."user" to "anon";

grant trigger on table "public"."user" to "anon";

grant truncate on table "public"."user" to "anon";

grant update on table "public"."user" to "anon";

grant delete on table "public"."user" to "authenticated";

grant insert on table "public"."user" to "authenticated";

grant references on table "public"."user" to "authenticated";

grant select on table "public"."user" to "authenticated";

grant trigger on table "public"."user" to "authenticated";

grant truncate on table "public"."user" to "authenticated";

grant update on table "public"."user" to "authenticated";

grant delete on table "public"."user" to "service_role";

grant insert on table "public"."user" to "service_role";

grant references on table "public"."user" to "service_role";

grant select on table "public"."user" to "service_role";

grant trigger on table "public"."user" to "service_role";

grant truncate on table "public"."user" to "service_role";

grant update on table "public"."user" to "service_role";

[GitTorres]

In the middle of their FAQ on this thread they say the following:

"By default, secret API keys assume the service_role. When creating the new secret API keys, you can override this behavior and assign a custom role."

I'm interpreting this to say that the "service_role" role in Postgres will still be associated with your API key like it is today and we won't need to change any GRANT statements mentioning "service_role". Fingers crossed anyway.

[CalvinWilkinson]

Let's hope! It would be helpful to receive an official response on this matter.

[tarun1sisodia]

yes , i am also worried about that , my whole project migrations and customization based on service_role . i hope it will not change.

[riderx]

i just tried and it seems to work my functions who are allowed on service_role work the same way

[cardilloscreations]

What's the plan for self-hosted via docker? Is it available there already? I did a quick scan but didn't see this in the docker files.

[raitono]

According to the FAQ:

I only connect to the database via the connection string — do I need to worry about this at all?

No, unless you use the supabase client libraries to make queries to the database.

I am using connection strings with Prisma. I just restored a project which was paused for inactivity and can no longer reach it from my application.

Error querying the database: FATAL: Authentication error, reason: "Unsupported or invalid secret format"

Also:

... restored projects affected from 1st May 2025 ...

Has this policy changed? The connection instructions in the project show no change in the recommended setup for connecting with Prisma.

[j4w8n]

Asym jwts have not been released yet, so the timeline is inaccurate. So, theoretically, it shouldn't have affected your project. You might wanna contact support.

[pauksztello]

Updated timeline posted anywhere?

[sanchezcarlosjr]

One day left before the launch week is over...

[pauksztello]

a very sad outcome I must say

[j4w8n]

I completely spaced that they were releasing anything today.

Oh well, someday.

[omarammarthefirst]

It looks like they updated the timeline on supabase , previously it said Q4 2024

[j4w8n]

Nice find @omarammarthefirst. I finally found where this was at in the dashboard. So the announcement link takes you back to this discussion.

[fmp-llauton]

Has anything on this been actioned?

[j4w8n]

Nothing has been implemented, if that's what you're asking. Supabase-hosted project dashboards say asym JWTs will be available by the end of June 2025.

We shall see.

[jhaworth]

my current (old style) anon key has a start date of june 2025, can i migrate to new keys yet or how do i refresh the old one

[keshav-k3]

I don't think the new keys are out yet, they are looking at a Q2 2025 release I believe, which means it will probably come out around June of this year.
So you're anon key needs no immediate update for now

[rishabhsingroha]

same question bro

[spk-alex]

Why must I pass both JWT token and anon API keys to access the PostgREST API?
Some tools make me choose one way of authentication and don't work with 2 at once. Like Custom ChatGPT Action.

[rishabhsingroha]

Is this just for the sake of discussing something ? sob

[liaujianjie]

@kangmingtay Will be be able to create multiple secret keys? It'll help with reducing downtime during key rotation.

[hf]

Yes!

[liaujianjie]

🫶

[rishabhsingroha]

yup
thats actually stunning

[rishabhsingroha]

best feature

[maxcan]

How can we export the publishable secret key (for privileged, backend services) via the CLI or from the terraform resource?

This is pretty much required for any IaC setup.

[brendanjhoffman]

Reading https://supabase.com/docs/guides/functions/secrets, it looks like SUPABASE_PUBLISHABLE_KEY is available but not secret key. Additionally, the service role key is still available. Is the secret key something we have to manually add and/or are there plans for rotating the default service role out for the new secret key?

[maxcan]

this is my concern. For IaC setups with privileged code running outside of Supabase functions, you really need this to be available via API / CLI

[brendanjhoffman]

Interestingly discovered while testing that service role is the new secret key? If so, this is a bit confusing while migrating. I think there are a few users who use this to secure edge functions, like database webhooks in our use case.

const SERVICE_KEY = Deno.env.get("SUPABASE_SERVICE_ROLE_KEY");
console.log("SERVICE_KEY", SERVICE_KEY);

outputs:
SERVICE_KEY sb_secret_***

[maxcan]

oh interesting. I'll try this with a dummy project. If the terraform provider shares this behavior, my problem is solved. Agreed that it would be great if they documented this. @kangmingtay

[j4w8n]

yo one of my 2 years old project in ruined it says some bug in supabase
I still use supabase
but cant figure out that error
what do it do ?
any suggestions?

Depending on the error, write a post on the Supabase Discord. You may be encouraged to either open an issue on github or a support ticket with supabase.

[CalvinWilkinson]

I wanted to jump in and offer some advice that might help you get a solution faster next time.

When posting in a discussion or asking for help, it's often a good idea to provide as much context as possible. This helps the community understand your issue quickly and offer the most relevant advice.

Could you try including some more details, like:

• The exact issue you're facing.
• Any error messages you're seeing.
• What you've already tried to fix it.
• The versions that you're using.

Including these details is often the fastest way to get help. It also helps others who might encounter the same problem in the future.
If English isn't your first language, don't worry! A great approach is to write out your post in your native language first and then
use a tool like Google Translate to get the English version. Sometimes this can help ensure everything you want to say is included.

I hope this is helpful, and good luck with your issue!

[rishabhsingroha]

Thank you for real
I opened a support ticket with supabase
and Its fixed now :)

[CalvinWilkinson]

Glad I could help!

[asdico]

Hello everyone, I love the API keys, but you need to make them available for local environment as well. We can't have differences between environments.

Do you have in plan to release API keys for local env?

Thanks

[CalvinWilkinson]

I agree with this. The local environment still uses the anon and service_role keys and does not appear to have a concept of publishable and secret keys.

At least, it does not show the new keys when using the supabase status command. 😀

[sweatybridge]

Just to give you an update, we are currently working on publishable and secret key support locally. supabase/cli#4167

Hopefully it will land on stable release next Tuesday.

[logemann]

now "supabase status" outputs the new keys:
Publishable key: sb_publishable_ACJWlzQHlZjBrEguHvfOxg_3BJgxXXX
Secret key: sb_secret_N7UND0UgjKTVK-Uodkm0Hg_xSvEMXXX

But why cant i use the secret key when calling createClient(URL, SECRET_KEY)?
It gives me

Error fetching user role: {
  code: 'PGRST301',
  message: 'Expected 3 parts in JWT; got 1',
  details: null,
  hint: null
}

[GaryAustin1]

@logemann
There is a bug in the released CLI around this.
There is a fixed version available but not released to production yet.
If you know how to run beta releases you can pull that in.
https://github.com/supabase/cli/releases/tag/v2.46.1

[logemann]

thanks for confirming. I figured that i can get the old JWTs via "supabase status --output env" so i am using them as long as its not in prod.

[riderx]

I migrated the from to use the new JWT a month ago, last night I updated the machine to latest postgres and now no one can login....

I contacted the support I have no idea why this happen

[hf]

What support ticket is this?

[riderx]

SU-242643 Issue is resolved for user, i had pg_temp in search path no idea why and when that was added, i suspect it was when we checked why i had so many pg_temp create without me doing so.

[brendanjhoffman]

After migrating and upgrading to PostgREST 13, I'm getting a "PGRST301 No suitable key or wrong key type" error when trying to create custom JWTs. I think the issue is related to this PostgREST/postgrest#4048. It seems like having kid mismatch between JWT and JWK is causing it, which would make sense. However, whenever I try to import a private key using supabase gen signing-key in the web ui, it creates a new standby key with a different kid than what is generated by the CLI.

[hf]

Checking!

[brendanjhoffman]

I had same issue and contacted the support, we found out that pg_temp got added in the search path in the config UI, dunno how. But remove it fixed the issue on my end

As in the data API settings search path? Unfortunately mine only shows public and graphql public, and public and extensions in extra search paths.

[riderx]

Yes, you can check the PG log in the UI this was showing clear errors if i had copy to gpt it would found out

[sweatybridge]

Hi there, this error was caused by kid mismatch between your local private key and the one imported to platform.

We have since released a fix for this but it would require you to import the same private key again.

Could you give that a try and let me know?

[brendanjhoffman]

@sweatybridge Works now, thanks!

[DDushkin]

Hello, I have a frontend that uses Supabase auth, then I get that JWT and pass it to the Python server to make some complex calculations and use secrets. So on Python, I have an OAuth2PasswordBearer check for JWT and then create_client with it. I had this same setup for regular user endpoints and for some admin endpoints, just using a secret JWT. Now, with new api keys, I still can do the user endpoints with the Authorization header cause it is generated by the frontend, but what should I do with admin endpoints? This OAuth2PasswordBearer will not work for the secret api key. Maybe you can add some guides for cases like this? I think it will be the same logic for people who are using Supabase edge functions

[hf]

I'm not sure what you're referring to honestly. Can you link to OAuth2PasswordBearer? What framework is this?

[DDushkin]

I'm not sure what you're referring to honestly. Can you link to OAuth2PasswordBearer? What framework is this?

It is python FastAPI. But it doesn't matter, the point of this question is similar to what to do with edge functions or any external backend where we had endpoints that now just receive the secret JWT and that way works as admin endpoints. How to make it work with new api keys if JWT checks are not working anymore cause new APIs keys are not JWT. I think the easiest approach is to make in those admin endpoints different checks for custom headers where we gonna pass new api key and create super client out of it

[1234redripper]

Ok

…

On Wed, 10 Sept 2025, 17:36 Martin DONADIEU, ***@***.***> wrote: SU-242643 Issue is resolved for user, i had pg_temp in search path no idea why and when that was added, i suspect it was when we checked why i had so many pg_temp create without me doing so. — Reply to this email directly, view it on GitHub <#29260 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BTBQAVECJEGXRWMQQ7SWXZL3SAZNPAVCNFSM6AAAAABODRV7OCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTIMZWGM3TCMY> . You are receiving this because you commented.Message ID: ***@***.***>

[SteveHawes]

I have not imported any private keys to the platform and do not have any private keys as far as I am aware. What exactly do I need to do please? Thanks Steve Steve Hawes CIO t: +44 (0)20 8158 5958 m: +44 (0)7831 338552 e: ***@***.*** w: www.elysiumwebservices.com a:Connect 38, 1 Dover Place, Ashford, Kent, TN23 1FB Elysium Web Services Limited is a company registered in England and Wales under number 14469124 with its registered office being at Connect 38 1 Dover Place, Ashford, United Kingdom, TN23 1FB. ​ ​This message contains confidential information and is intended only for the intended recipients. If you are not an intended recipient you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. ​ Elysium Web Services Limited may monitor email traffic data and also the content of emails for compliance purposes and to protect its business. From: Han Qiao ***@***.***> Date: Tuesday, 16 September 2025 at 17:07 To: supabase/supabase ***@***.***> Cc: Steve Hawes ***@***.***>, Comment ***@***.***> Subject: Re: [supabase/supabase] Upcoming changes to Supabase API Keys (Discussion #29260) Hi there, this error was caused by kid mismatch between your local private key and the one imported to platform. We have since released a fix for this but it would require you to import the same private key again. Could you give that a try and let me know? — Reply to this email directly, view it on GitHub<#29260 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFSUXNZ6JBOWCTNIETVYYST3TAYVLAVCNFSM6AAAAABODRV7OCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTINBRHAZTQOA>. You are receiving this because you commented.

[maxcan]

Any update on the terraform provider?

[IAmPattycakes]

It isn't entirely clear to me how or if the existing JWT secret's functionality is transferred over to the new API keys. Are we able to sign self-created JWTs using an API key, just like the existing JWT secret, and have that be respected in RLS? I have a trusted, secured endpoint that signs very limited keys for ephemeral headless resources, and I would really prefer those instances don't get full access to everything in the database, the blast radius of one of those machines being compromised is significantly higher if they get handed an API key than if they are just issued a JWT that has basically no permissions to modify anything but their own data.

[renton4code]

Just sharing my feedback:

IDK what happened guys, but our webhook that relied on legacy JWT just stopped working on Sep 17th, secrets were rotated to new keys and API that called function with legacy JWT stopped working. This had a major impact on the business, one of the critical services broke during merge-freeze. Quite frustrating experience with keys migration TBH... I'd appreciate an email or a banner somewhere before a breaking change. 😢

[pawarren]

@sweatybridge

Legacy JWT keys had a configurable "Access token expiry time".

I don't see that field in "JWT Signing Keys"...trying to figure out how long signed in user's access token lasts before they need to use the refresh token.

Did this change remove access tokens/refresh tokens, or is it now impossible to adjust the access token expiry time?

[GaryAustin1]

That setting should apply to both the legacy and the new asymmetric keys.

[pawarren]

Okay, I will edit the access token expiry time (currently in "Legacy JWT Keys") and expect it to also apply to the new "JWT Signing Keys"

[xiaoshuai-cui1987]

Use Deno.env.get("SUPABASE_SERVICE_ROLE_KEY") in Edge Functions to get the Secret key. After switching to the new api secret key, can no environment variable get the secret key?