Changelog

We are changing the default value of the Postgres log_connections setting from on to off for new projects, and will be migrating all Free and Pro projects to the new default configuration. This reduces log volume and noise, and aligns with industry-standard defaults (RDS, GCP Cloud SQL also default to off). We will be exposing this configuration to all users via dashboard and API for better log management, with log_connnections and log_disconnections now available via the Update postgres config API route and will take effect from 9 July onwards.

Who's affected#

• New projects (all tiers) created after 9 July will have log_connections=off by default.
• Existing Teams + Enterprise customers (including HIPAA add-on customers) - Configuration is unchanged
• Existing Free / Pro customers - log_connections will be turned off from 9 July. This configuration can be re-enabled below

How to re-enable#

You can re-enable log_connections via the dashboard under Database > Settings. It can also be re-enabled programmatically via the Management API via the Update postgres config API route. Changes will only take effect from 9 July onwards.

Learn more about PostgreSQL logging settings in our logging documentation.

What's Changing?#

The week of July 6, 2026, the default self-hosted Supabase configuration for API_EXTERNAL_URL will change to include the /auth/v1 path prefix:

• API_EXTERNAL_URL will default to http://localhost:8000/auth/v1 (previously http://localhost:8000)
• GOTRUE_JWT_ISSUER in docker-compose.yml will change to ${API_EXTERNAL_URL} (the actual URL will stay unchanged)
• OAuth redirect configuration placeholders in docker-compose.yml will become ${API_EXTERNAL_URL}/callback
• The API gateway routes for SAML SSO move from /sso/saml/* to /auth/v1/sso/saml/*, so SAML ACS and metadata endpoints become …/auth/v1/sso/saml/acs and …/auth/v1/sso/saml/metadata

This aligns self-hosted Supabase with the platform behavior, and the CLI.

Why?#

• Consistency across deployments. API_EXTERNAL_URL behaves identically on platform, self-hosted, and CLI.
• Custom OAuth providers work out of the box. GoTrue builds custom-provider callback URLs as API_EXTERNAL_URL + /callback. With the prefix now in the base URL, that resolves to …/auth/v1/callback and matches the existing API gateway route.
• SAML aligns with the /auth/v1 convention used by every other auth endpoint, rather than living at a bare /sso/saml/* path.
• The docs become accurate. The guidance that "your callback URL is built from API_EXTERNAL_URL" is now literally true, instead of relying on the /auth/v1 prefix being manually prepended in the compose file.

Am I Affected?#

You are affected if you run self-hosted Supabase from the ./docker directory and pull updates from master, and any of the following apply:

• You've overridden API_EXTERNAL_URL in your .env (e.g. https://my-domain.com) - you'll need to change it to https://my-domain.com/auth/v1.
• You maintain a customized docker-compose.yml with OAuth providers - the redirect URIs change from ${API_EXTERNAL_URL}/auth/v1/callback to ${API_EXTERNAL_URL}/callback to avoid a doubled /auth/v1 prefix.
• You use SAML SSO - your IdP points at the old /sso/saml/* endpoints and must be updated to /auth/v1/sso/saml/*. This is the main breaking case.

You are not affected if you:

• Use the Supabase platform
• Have OAuth providers registered with Google/GitHub/etc. - the final callback URL is unchanged (…/auth/v1/callback), so no re-registration in the provider's developer console is needed
• Don't use SAML SSO and pull the new docker-compose.yml and .env.example together without local changes - the defaults stay consistent

What Should I Do?#

If you pull the updated docker-compose.yml and .env.example together with no customizations, no action is required unless you use SAML SSO.

If you've customized API_EXTERNAL_URL:

1. Append /auth/v1 to your value (e.g. https://my-domain.com → https://my-domain.com/auth/v1)
2. If your override file sets OAuth redirect URIs, change them from ${API_EXTERNAL_URL}/auth/v1/callback to ${API_EXTERNAL_URL}/callback
3. Restart the stack

If you use SAML SSO:

1. Pull the updated docker-compose.yml (or update your Kong and Envoy routes to /auth/v1/sso/saml/acs and /auth/v1/sso/saml/metadata)
2. Restart the stack
3. Re-fetch your service provider metadata from {API_EXTERNAL_URL}/auth/v1/sso/saml/metadata and update your IdP (ACS URL, SP entity ID) with the new endpoints
4. See the self-hosted SAML SSO guide

If you'd rather defer: keep your existing API_EXTERNAL_URL without the /auth/v1 suffix and retain your current OAuth/SAML configuration. This is a default change, not a removal - but we recommend aligning soon, since custom OAuth providers won't work without it.

Rollout#

Realtime Broadcast can now send and receive binary payloads in addition to JSON. This lets you broadcast compact binary data without the overhead of JSON encoding.

Binary payloads are supported across every way you send a Broadcast message: the client libraries (over WebSocket), the REST API, and directly from your database.

When to use binary payloads#

Binary shines whenever your data is numeric, high-frequency or densely packed. In these cases JSON's textual encoding adds significant overhead.

• Sensor and telemetry streams. Connected devices emit steady streams of numeric readings. These can be temperature, accelerometer values, GPS coordinates, battery levels, etc. They can be packed into fixed-width binary fields, where a reading that takes 20–30 characters as JSON text fits in just a few bytes across thousands of devices.
• Screenshot and presentation streaming. A presenter or support agent shares a live view by broadcasting periodic image frames (JPEG/PNG) to viewers. Each frame is transient and inherently binary, so there's no need for durable storage and no reason to pay the base64 tax. Just send the image bytes straight to everyone watching.

Usage#

Client libraries (WebSocket)#

Pass an ArrayBuffer/ArrayBufferView (Uint8Array for example) or the equivalent in non-JS SDKs as the payload.

REST API#

Single-message endpoint where Content-Type selects application/json vs application/octet-stream. channel.httpSend() from JS.

Database#

realtime.send_binary() with a bytea payload.

Minimum versions#

• WebSocket (supabase-js): 2.91.0
• WebSocket (supabase-swift): 2.44.0
• REST API through httpSend (supabase-js): 2.107.0
• Realtime server version: 2.103.2

We are in the process of adding support to binary payloads across all SDKs.

⚠️ Binary payloads sent to clients on older SDK versions (or SDKs that don't support binary payloads) are silently dropped.

More information can generally be found in the Broadcast page of the Realtime guides.