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
andservice_role
keys remain available for use.- A single publishable key with the form
sb_publishable_...
can be used to replace theanon
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 theservice_role
key. - You can disable and re-enable the
anon
andservice_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), andauthenticated
(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 theAuthorization
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 theapikey
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.