Changelog

📢 UPDATE [November 26, 2025]: Public beta is live now!

• See the latest comment below for full details

---

Hey Supabase community! 👋

We're excited to share that we're adding OAuth 2.1 server capabilities to Supabase Auth, turning your Supabase project into a full OAuth authorization server. This means your project can act as an identity provider for third-party applications, similar to how you might use "Sign in with Google" today.

Current Status: Public Beta

Target Date:

• Generally available: Q4 2025

What We're Building#

We're implementing OAuth 2.1 authorization server capabilities that will allow your Supabase project to:

• Act as an identity provider for third-party applications
• Enable "Login with [Your App]" functionality
• Eventually support OpenID Connect (OIDC) for full SSO capabilities

Exciting Use Cases#

MCP (Model Context Protocol) Auth#

Use your Supabase project as the auth provider for AI agents and LLM tools that support MCP.

"Login with Supabase Project"#

Enable third-party applications to offer "Sign in with [Your App]" - turning your Supabase project into an identity provider like Google or GitHub.

Enterprise SSO (via OIDC - coming next)#

Act as a single sign-on provider for your organization's internal tools.

API Access for Partner Integrations#

Securely grant scoped access to your API for third-party developers and partners.

How It Works#

Here's the authorization flow we're implementing:

Key Design Decision: Flexible Authorization UI#

Traditional OAuth servers host your application's UI. Instead, we're giving you complete control over the authorization and consent screens. After the initial /authorize call the user is taken to your app's frontend to be presented with the consent screen. This provides the freedom to build your app how you want, while Supabase Auth takes care of the protocol specifics:

• Design custom login/registration flows (can use your existing login as it is)
• Implement your own consent screens
• Handle authentication however you prefer (password, social login, MFA, etc.)

This gives you maximum flexibility to match your application's design and user experience.

What Supabase Provides#

• OAuth 2.1 Protocol Handling: Full implementation of authorization code flow with PKCE
• Token Management: JWT access tokens and refresh tokens
• Client Registration:
  • Dashboard UI for manual client registration
  • Dynamic client registration API (perfect for MCP auth!)
• Token Validation: JWKS endpoint for third-party token validation, thanks to asymmetric JWTs
• APIs for Authorization Flow: Endpoints to handle approval/denial decisions
• Client Libraries: SDK updates for easy integration (coming soon)
• UI Components: Consent screen components via Supabase ui.supabase.com (planned)

What You Need to Implement#

• Authorization/Consent UI: Create your own login and consent screens
• User Authentication Logic: Handle how users prove their identity
• Consent Management: Present scope information (tbd) and capture user approval

Access Token Structure#

Access tokens will be JWTs (like current Supabase tokens) with:

• All standard Supabase claims (user_id, role, etc.)
• Additional client_id claim for OAuth client identification
• Compatible with existing Row Level Security(RLS) policies (same role claim structure)

Balancing RLS Power with OAuth Scopes#

We want to preserve the power and flexibility of RLS policies while also enabling developers to "scope down" access tokens based on OAuth scopes. This is a challenging balance - RLS gives you fine-grained, row-level control, while OAuth scopes traditionally work at a higher level.

Our current thinking includes exploring these approaches:

1. Custom Access Token Hook: Extend the existing hook system to modify token claims based on OAuth context
2. OAuth-specific Access Token Hook: A new dedicated hook that runs only for OAuth token generation
3. JWT Template System: Define templates that control token structure based on client/scope combinations

Initial Limitations & Future Roadmap#

Phase 1:

• Authorization code flow with PKCE
• Refresh tokens
• No scope management initially (tokens have full user privileges, rely on RLS for authorization)

Phase 2:

• OpenID Connect support
• Scope management system & customization of tokens generated by OAuth flows

We Need Your Feedback!#

We'd love to hear your thoughts on:

1. Scope Management & Token Customization#

Currently, we're starting without a scope system: OAuth tokens will work like regular session tokens with full user privileges. Authorization happens via RLS policies. We're exploring ways to "scope down" OAuth tokens while preserving RLS:

• Would you prefer Custom Access Token Hooks, OAuth-specific hooks, or JWT templates?
• How should OAuth scopes translate to token restrictions?
• Would you need granular scopes immediately or is basic token customization enough to start?

2. OpenID Connect Features#

As we plan OIDC support, which features are most critical for you?

• Userinfo endpoint
• ID tokens
• Specific claims in ID tokens
• Session management
• Other OIDC features?

3. Dashboard UI for OAuth Client Management#

What would you need in the dashboard?

• Client registration and management
• Consent history and revocation
• Token analytics
• Scope configuration (when available)
• Testing tools?

4. Your Use Cases#

What would you build with this? We're especially interested in:

• Use cases we haven't considered
• Integration scenarios with existing systems
• Security or compliance requirements
• Performance or scaling considerations

Questions?#

Drop your questions, feedback, and use cases below! We're actively working on this and your input will directly influence the implementation.

We've fully rolled out the Deno 2.1 compatible release on all regions serving Edge Functions. You don't need to change your existing Edge Function invocations; the nearest region will automatically serve them using the Deno 2.1 release.

Along with the Deno 2.1 release, the features we announced during the launch week also became available in all regions: https://supabase.com/blog/persistent-storage-for-faster-edge-functions

Fallback to Deno 1.45#

In case your Functions start experiencing any compatibility issues with Deno 2.1, you can temporarily fallback to the 1.45 release in two ways:

• Add query parameter forceDenoVersion=1 to your function requests

• Add x-deno-version: 1 header in requests

If you have any issues and questions about this update, please create a support request

What changed#

Using realtime-js library in Node.js < 22 will require to set transport for Realtime

What do I need to do#

For most users (Browser, Node.js 22+): No changes required For Node.js < 22 users: You’ll need to make a small change to explicitly set the WebSocket transport (see line 9 below).

[!WARNING]
We are working on a fix for the type definition as currently it's not being accepted as a WebSocketLike interface.

Why did we change it#

We have been facing multiple issues where the dynamic import of ws was breaking several runtimes and environments. The first environment where this become a serious issue was with Expo which required us to tackle the issue.

Previous attempts#

Multiple NPM entrypoints#

PR: https://github.com/supabase/realtime-js/pull/476

First approach chosen in conjunction with the Expo team but ended up creating several issues in other runtimes (namely Deno and Browser) so we reverted to use another method

Polymorphic client#

PR: https://github.com/supabase/realtime-js/pull/485

Second approach chosen as it's usually the "default" as we accepted the overhead of having a polymorphic WS connector but this created issues with Vercel ( https://github.com/supabase/supabase-js/issues/1437 )

Current approach#

After our several attempts in handling how Javascript runtimes handle dynamic imports we had to change the way we support Node.js < 22 as it was the original source of the issue due to the lack of native WebSocket support

The changes are implemented in realtime-js@2.15.1 with the changes from https://github.com/supabase/realtime-js/pull/514 The changes are implemented in supabase-js@2.55.0 with the changes from https://github.com/supabase/supabase-js/pull/1529

We opted to use this approach as it fully prevents the usage of dynamic imports; it avoids external library issues; has a path for upgradability and avoids multiple entrypoints which proven to be error prone.

As part of the restructuring of the python environments, both the gotrue and supafunc python packages are being deprecated, in favor of supabase_auth and supabase_functions respectively.

gotrue 2.12.4 and supafunc 0.10.2 have both been published with no changes other than metadata changes, and including deprecation warnings when importing from them.

[!WARNING] Please note that 2.12.3 is the last version where both gotrue and supabase_auth are the same, and they will diverge going forward. The same is valid for supafunc and supabase_functions version 0.10.1.

Affected libraries#

• supabase-py
• gotrue
• supafunc

Timeline#

Package name changes: December 14, 2024 Deprecation Notice Issued: August 8, 2025

Why?#

This name change has occurred in December 2024, in trying to keep name parity with the JavaScript libraries, but these old packages have been receiving the same updates through a script in the publishing workflow. As part of the python CI restructuring effort, it doesn't make sense to keep two versions of the same package around, and thus they're not going to receive patches anymore.

What You Need to Do#

Change all package references from gotrue to supabase_auth, and supafunc to supabase_functions, in pyproject.toml, setup.py, or other package metadata formats, and change all direct imports from those libraries (from gotrue import ...) to importing from the new ones instead (from supabase_auth import ...).

supabase-py 2.18.1 will drop all usages of gotrue and supafunc from the main library. If you are using gotrue and supafunc directly as transitive dependencies, please prefer importing directly from supabase instead (see this comment for more info).

[!WARNING] This is not going to be available for long, as feature differences are bound to occur sooner or later.

Thank you for your attention and continued support. If you have any questions, feel free to reach out through GitHub Discussions or our community channels.

As part of our ongoing efforts to make Dashboard easier to use, we’re moving service-related settings in their respective areas. Take database settings, for example:

• Previously: you had to go to Project Settings → Database to make database-related configuration changes.
• Now: Any database-related configuration can be found in Database → Configuration.

Project-level settings like Data API will remain in Project Settings.

Before	After
Before: No database settings to be found!	After: Database settings along with access control in one simple section.

Pretty simple. But, because we’re changing routes, this might confuse folks expecting to find things where they used to be.

Here’s how we’re making this change as smooth as possible:

• Redirects have been added so the old URLs will keep on working.
• References in documentation have been updated.
• The old navigation (e.g. Project Settings → Storage) will stick around for a few months. They’ll just be treated as shortcuts to their new homes.

What’s affected#

The full list of affected services and/or settings include:

• Database
• Data API
• Authentication
• Storage
• Edge Functions
• Log Drains

Previously	Now	Later
Previously: service-level settings scattered throughout Project Settings and their own areas.	Now: all moved out to their respective areas, but shortcuts remain here in Project Settings.	Later: we’ll remove these shortcuts to make Project Settings less noisy.

Code changes#

See #37580 for the Now changes (later today) and #37612 for the Later changes (scheduled for a few months from now).

What’s next#

Some of our settings aren’t so neat, bridging multiple services or arguably children of existing setting sections. Examples include Data API and Log Drains. We’re looking into how to better categorise them over time, which may mean more navigation changes. We’ll let you know if those happen.

Feedback#

As always, please let us know what you think or if you run into issues, here on the discussion. Thanks!

Version 17.4.1.062 of supabase was withdrawn.

"Withdrawn" means a problem was found with the image, and so it is set to "withdrawn" to prevent it's continued use for new projects.

An update will be released to our production servers ASAP. Customers are encouraged to update to this version as soon as you can after it becomes available.

However, a few customers may have created projects with it while it was released.

If so, you may see a status like this

Your options are:

1. Drop the existing project you created if it is new enough. Then, create a new which would come up under an earlier release number, and wait for update
2. Or, keep the existing project for now, and wait for update.

Once the update is available, you'll see a prompt to upgrade in the https://supabase.com/project/_/settings/infrastructure tab

Combined View for Logs#

In the upcoming days, we'll be releasing a new interface on the dashboard for logs with a unified view across all your services, along with improved filtering and real-time updates! You no longer need to find a specific collection that you'd want to look for logs from, and can now conveniently query through a single interface, which will also provide a better top-level view of your project 🙂

This is very much a heavy work in progress, but we'd be keen to hear your thoughts on what you love, what's missing, and anything at the top of your mind! Sign up here for early access to give it a try!

What we'd like to know from you#

• Any bugs or issues that you might have run into while using the new UI
• Any ideas or suggestions that you reckon will improve the DX based on how find logs
• Feel free to leave any feedback in this thread too!

As part of our ongoing commitment to providing a secure and reliable experience for all developers, we will drop support for Node.js 18 in accordance with our Support Policy.

Affected libraries#

• supabase-js
• auth-js
• realtime-js
• functions-js
• storage-js
• postgrest-js

Timeline#

Deprecation Notice Issued: July 16, 2025 End of Support for Node.js 18: October 31, 2025

Why?#

Node.js 18 reached its official end of life on April 30, 2025 and no longer receives security updates or critical fixes. Continuing to support unsupported runtimes introduces risks for both developers and end users.

What You Need to Do#

Please upgrade to a supported Node.js version (20 or later) before October 31, 2025 to ensure continued compatibility with future releases of our libraries.

Thank you for your attention and continued support. If you have any questions, feel free to reach out through GitHub Discussions or our community channels.

Overview#

We're going to roll out a Realtime Settings screen that will allow you to setup parameters for your Realtime account.

Usage#

In the Realtime section of the Dashboard, under Settings, you will find the settings you can change.

Currently we're giving you control over:

• Channel restrictions - Control wether you allow public access to your channels. Public access means that you can use Private and Public channels. As a reminder, Private channels are the ones to which you have setup Realtime Authorization.
• Database connection pool size - The amount of connections allocated to Realtime Authorization RLS checking. This will impact your join rate by being able to increase the rate of checks for your private channels. Be aware this will consume more direct connections from your database available connections
• Max concurrent clients - If you have disabled the spending cap you are able to increase the number of concurrent clients and change your Rate Limit for this specific flag.

Edge Functions are executed in the region closest to the user making the request. This helps to reduce network latency and provide faster responses to the user.

However, if your Function performs many database or storage operations, invoking the Function in the same region as your database may provide better performance. Some situations where this might be helpful include:

• Bulk adding and editing records in your database
• Uploading files

Previously, the region could only be set via the x-region header in the request. However, in some instances (e.g., CORS requests, Webhooks), the headers set in the request cannot be controlled. Considering these limitations, we've also made it possible to set the region via the forceFunctionRegion query parameter.

Please check the Regional Invocations guide for more details.