Supabase is disabling older TLS encryption – check your integrations

What Supabase is changing

Supabase has announced that older encryption options within TLS 1.2 will be removed from projects’ HTTP APIs. According to the Supabase changelog, the change may be implemented from 10 November 2026 at the earliest.

TLS is the security layer used when a client connects to an address over HTTPS. Before an API request is sent, the client and server agree on how to encrypt the connection. This agreement is called a TLS handshake.

A cipher suite is a set of technical rules for encryption. Supabase is removing older options that use CBC mode. These have known security weaknesses and may trigger warnings in security reviews. TLS 1.2 itself is not being removed. TLS 1.3 is not affected either. Only an older set of options within TLS 1.2 is being removed.

The change applies to traffic to the project’s standard Supabase domain and any custom domains. This includes requests to:

• Auth
• Data API
• Storage
• Realtime
• Edge Functions

Direct connections to Postgres, connections through Supabase poolers and requests to the Management API are not affected by this particular change.

The important point is to identify what actually opens the connection. If a browser calls Supabase directly, the browser and the user’s operating system are the client. If a server function calls Supabase, the server runtime is the client. If an external system sends a webhook to an Edge Function, the external system’s HTTP client must support the new configuration.

Which clients may stop working

A client is affected only if it can use neither TLS 1.3 nor any of the TLS 1.2 options that Supabase retains. Modern browsers, current server environments and maintained HTTP libraries should therefore normally continue to work.

The main risk lies with technology that is no longer updated:

• older operating systems and browsers
• old versions of mobile or desktop apps
• embedded devices with fixed software
• self-hosted integrations on old servers
• older Java, .NET, PHP, Node.js or OpenSSL environments
• partner integrations where you do not control the HTTP client
• scripts or scheduled jobs that have run unchanged for a long time

A Lovable app running in the browser normally uses the browser’s TLS support. This means that the same web app may work for one user but fail for another using a very old device.

Code running on Vercel instead uses the TLS support in the server environment where the function runs. A current runtime is less likely to be affected than an old, fixed environment. Even so, check which runtime the project actually uses in production. It is not enough to look at the default for a new project.

For webhooks, you need to distinguish between the directions. If Stripe or another service calls your Edge Function, that service is the client connecting to Supabase. If your Edge Function calls the service’s API, Supabase is not the server for that connection, so this change does not govern the outgoing traffic.

The Supabase JavaScript client does not decide on its own which cipher suite is used. This is usually determined by the underlying browser, operating system or server TLS library. Simply updating the supabase-js package is therefore not always the solution.

How to test before the change

Start by listing every route into the project’s HTTP API. Do not look only at the main app. Auth, file uploads, Realtime, background jobs and webhooks may use different clients.

Record the following for each connection:

• which Supabase address is called
• which function or integration makes the request
• whether the code runs in a browser, app, server or external service
• which operating system and runtime are used
• who is responsible for keeping the environment updated
• the oldest client version you still support

Then test the actual user flows from the oldest environment you intend to continue supporting. A successful login from your own modern computer tells you nothing about an old mobile app or an integration job owned by a partner.

There is an important pitfall: a standard test against Supabase may succeed today because the older options are still available. The test must therefore show that the client can connect using TLS 1.3 or a modern option within TLS 1.2.

If you have access to OpenSSL, you can run a restricted test from the same server, container or environment used by the integration:

openssl s_client -connect PROJECT.supabase.co:443 -servername PROJECT.supabase.co -tls1_2 -cipher 'ECDHE+AESGCM:ECDHE+CHACHA20' </dev/null

Replace the domain with the project’s actual domain. A completed handshake shows that this particular OpenSSL environment shares a modern option with Supabase. However, the test does not automatically prove that your application uses the same library or settings. You should therefore also make a real API request through the application’s own code path.

For external integrations, you will often need to ask the provider. Ask them to confirm the TLS support used by their webhook client or HTTP client. Also ask whether old installed versions may have a different configuration from their current service.

Use this checklist before testing:

• All Supabase domains and custom domains are documented
• All calling clients and integrations have been identified
• Older app versions still in use are included in the inventory
• The server runtime, operating system and TLS library have been checked
• External providers have confirmed their TLS support
• Critical flows have been tested from the oldest supported environment
• The results are documented so that the test can be repeated

How to update without unnecessary downtime

The best approach is to update the affected client’s operating system, runtime or TLS library. Do not try to re-enable weaker encryption in Supabase – the change is being made on the platform side and is intended to remove outdated options.

Start with the environments you control. Update server functions, background jobs and self-hosted integrations before client apps that require users to install a new version. Test the same user flows before and after the update.

For a mobile or desktop app, a compatible version needs to be released well in advance. If old app versions can still be used after the change, you should have a plan to show users a clear error message or prompt them to update. A raw TLS error rarely helps a user understand the problem.

Avoid combining the TLS update with major changes to authentication, database structure or API formats. A limited technical change is easier to test and roll back if something else goes wrong. You do not normally need to change your Supabase project, API keys or domain solely because of the cipher change.

If an old client cannot be updated, a proxy under your control may work as a temporary bridge. It accepts the client’s older connection and then creates a modern connection to Supabase. However, this is not a neutral shortcut. The proxy becomes a new security boundary that must handle certificates, authentication, logging, secrets, rate limiting and incidents. Use it only when the client genuinely cannot be updated, and set out a plan for removing the solution.

Roll out the change gradually where possible. Start with a test environment or a limited production route, verify login, data access, file handling, Realtime and Edge Functions, and then continue with the rest of the traffic.

Failure modes and what to monitor

When a TLS handshake fails, no normal HTTP request is sent. The error occurs before Supabase can read the path, headers or authentication details. The request may therefore be entirely absent from the project’s API logs.

Depending on the client, the error may be described as a handshake failure, an SSL error, a failed secure channel or a mismatch between the version and cipher. If users report that the app can no longer connect while the Supabase logs are empty, check the client’s network and TLS errors.

You should therefore monitor more than the Supabase logs:

• error reporting in web, mobile and desktop apps
• logs from server functions and background jobs
• delivery logs from webhook providers
• alerts for failed logins and uploads
• differences between new and older client versions

Also make sure your support instructions distinguish between a TLS error and a standard API error. Changing a database policy or creating a new API key will not resolve a failed handshake.

The practical aim is not to map every encryption detail. You need to know which systems connect, what technology they run and whether they can create a modern HTTPS connection. Once the technical foundations have been checked, you can spend more time on the next step – gaining paying customers.

Source: Supabase changelog