Changelog

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.

A couple of months ago, we started migrating our Edge Functions platform to use Deno 2.1. Deno 2 bridges the gap between Node and Deno by supporting Node's built-in APIs, npm modules, and package.json. This would make it easy to migrate existing Node apps to run in the Edge Functions platform.

Previously, we announced that you can start testing Deno 2.1 locally for your Edge Functions. Thanks to everyone who tried and gave us feedback.

Today, we give you the option to preview Deno 2.1 on our hosted platform. You should try running your existing Edge Functions with Deno 2.1 and report any bugs/issues.

You can first run deno lint locally on your Edge Functions code with no-deprecated-deno-api rule to find any breaking changes in Deno 2.

Once you have updated your functions, you can test them in our hosted platform as follows:

How to test for Deno 2 compatibility#

There are two ways to force your functions to run on the Deno 2 preview cluster.

• Add query parameter forceDenoVersion=2 to your function requests

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

Note: Deno 2 Preview cluster traffic will be served from us-east-2 region. You don't need to set the region explicitly.

Also, in the next couple of days, we will notify projects currently using deprecated APIs via email to update their functions to use Deno 2.

When are we fully rolling out Deno 2.1?#

Based on the feedback and issues we discover in this preview, we will decide the timeline on making Deno 2.1 the default runtime in our hosted platform. Current ETA is within 3-6 weeks.