Supabase TLS Cipher Change: Check Client Apps Before November 10

Short answer: Most current web and server clients should keep working, but any client that reaches a hosted Supabase project API through an old operating system, browser, runtime, TLS library, or unmaintained embedded device needs review before November 10, 2026. Inventory every client version still in use, confirm it can negotiate TLS 1.3 or one of Supabase's retained TLS 1.2 cipher suites, update legacy clients, and test the application path—not just a generic HTTPS request.

Supabase published the deprecation notice on October 12, 2026. It says removal will happen November 10, 2026 at the earliest, so that is a preparation deadline rather than a promise that the change will happen at a particular minute. Supabase also plans to notify affected project owners by email on October 14.

What Supabase is changing

Hosted Supabase project APIs currently accept TLS 1.2 and TLS 1.3. Supabase plans to stop offering four CBC-mode TLS 1.2 cipher suites:

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS 1.3 is not changing. TLS 1.2 will remain available with six AEAD suites based on AES-GCM or ChaCha20-Poly1305. The exact retained list is in the Supabase TLS documentation.

The change is about transport compatibility. It does not change API keys, authentication, database grants, or Row Level Security policies. A successful TLS connection also says nothing about whether a request is authorized. Keep authorization testing separate with a Supabase RLS launch checklist.

Which Supabase connections are affected?

The hostname and service matter more than the SDK name.

Connection path	In scope for this change?	What to inventory
Auth on <project-ref>.supabase.co or a custom domain	Yes	Browsers, mobile or desktop apps, server runtimes, and third-party integrations
Data API / REST / GraphQL on the project domain	Yes	Every shipped client version and every backend worker calling the API
Storage on the project domain	Yes	Upload, download, signed-URL, and image-delivery clients
Realtime on the project domain	Yes	WebSocket clients, device software, and long-lived installed apps
Edge Functions on the project domain	Yes	Browsers, apps, webhooks, and server-to-server callers
Direct Postgres connection	No	Track it separately under Postgres SSL requirements
Supabase pooler connection	No	Track it separately under Postgres SSL requirements
Management API at api.supabase.com	No	No action for this specific cipher removal
Self-hosted Supabase	No, according to the notice	Your own TLS terminator and configuration remain your responsibility

A custom domain does not avoid the change. Supabase says the same project-API TLS settings apply to the default project hostname and custom domains.

Who needs to act first?

Prioritize clients whose software lifecycle is outside the normal browser-update path:

1. Installed mobile and desktop apps with old versions still in circulation.
2. Embedded clients, smart displays, kiosks, set-top boxes, or appliances that may no longer receive OS updates.
3. On-premises agents or customer-managed servers with an old runtime or TLS library.
4. Third-party integrations where you do not control the HTTP stack.
5. Old browser and operating-system combinations that your support policy still covers.

For a typical current browser or maintained cloud runtime, the likely result is “no change required,” but do not turn that expectation into evidence. Supabase reports that fewer than 0.0001% of project connections used the deprecated suites in September 2026. That platform-wide figure indicates narrow exposure; it does not prove that none of your clients depend on them.

Build a client inventory before you test

Start from deployed reality, not only the current repository. AI-built applications are often handed off after a fast launch, while older native builds, scheduled workers, and integration scripts keep running elsewhere.

Use one row per materially different client version:

Field	Example evidence
Client and version	iOS app 2.4, warehouse kiosk image 2024.11, Node worker release SHA
Supabase hostname	Default project domain or exact custom domain
Service used	Auth, Data API, Storage, Realtime, or Edge Function
OS / runtime / TLS library	Supported version plus a vendor or runtime reference
Current cipher evidence	TLS 1.3, a retained TLS 1.2 suite, unknown, or deprecated-only
Owner and update path	App store release, device image, server deployment, vendor ticket
Decision	Compatible, update required, replace, retire, or escalate
Verification record	Test date, build identifier, environment, result, and reviewer

Include every client version that is still usable, not only the latest one. A current codebase can be compatible while an older installed release is not.

How to decide whether a client is at risk

Supabase's test is precise: a client is affected when it cannot use TLS 1.3 and the only TLS 1.2 suites it shares with the project API are the four CBC-mode suites being removed.

Classify each inventory row:

• Compatible: the actual client uses TLS 1.3, or it supports at least one retained TLS 1.2 suite.
• Needs evidence: the client currently connects, but its OS, runtime, TLS library, negotiated protocol, or cipher support is unknown.
• At risk: the client cannot use TLS 1.3 and supports none of the retained TLS 1.2 suites.

Do not use “the request returned 200 today” as the compatibility test. Until removal, Supabase still offers the deprecated suites. A legacy client can therefore succeed now by negotiating exactly the option that will disappear.

Check the configuration the application actually uses: operating system, runtime, linked TLS library, and any protocol or cipher overrides in code or deployment settings. Avoid inferring support from a development laptop when the real client runs on a device or customer-managed host.

Update the client, then test the application path

For an affected client, update the operating system, runtime, or TLS library to a supported release that can use TLS 1.3 or a retained TLS 1.2 suite. Remove custom cipher restrictions that unnecessarily exclude the retained options, but do not weaken certificate validation or add an insecure fallback to preserve connectivity.

After the update, exercise each Supabase path the client really uses in a controlled test environment:

• complete the normal Auth flow with a non-privileged test account;
• read and write a harmless test record through the Data API, including an expected denial case;
• upload and retrieve a non-sensitive Storage object if the client uses Storage;
• connect, receive an expected event, and reconnect if it uses Realtime;
• invoke the relevant Edge Function and verify both success and failure behavior.

Record the client build, OS or runtime version, TLS evidence, project hostname, test environment, timestamp, and result. A broad statement such as “Supabase works” is not a useful handoff artifact.

Use non-sensitive fixtures and the least-privileged credentials appropriate for the test. Transport compatibility is not a reason to expose a service_role key or broaden project access. For credential boundaries, see how to scope Supabase access to one client project.

Plan for clients you cannot update

Do not wait for the removal date to discover that a device fleet has no upgrade path. For every at-risk client, choose an explicit disposition:

• ship a supported client update and set a minimum version;
• replace or retire the legacy device or integration;
• move the affected workflow to a maintained intermediary you control, with a documented threat model and authorization boundary; or
• contact Supabase support with the client and cipher requirements if the update cannot be completed in time.

Supabase says the date may move later based on customer feedback, but a possible delay is not a remediation plan. Preserve the evidence and owner for each decision so the client can understand any remaining operational dependency.

What belongs in the client handoff

The handoff should contain more than a ticket marked done:

1. The full client-version inventory and affected Supabase services.
2. The compatibility classification and evidence for each row.
3. Links to the October 12 notice and current TLS documentation.
4. Updates shipped, minimum supported versions, and any retirement decision.
5. Application-level test results, including expected authorization failures.
6. The owner of any unresolved vendor or Supabase support case.
7. A reminder to recheck the official removal date before the release window.

This is a small compatibility project, not a reason to redesign the application. The useful outcome is proof that every supported client can still reach the exact Supabase services it needs after the old cipher options are gone.

If you are preparing an AI-built app for client delivery, add this evidence to the broader Sentrail launch-readiness checklist. It keeps the TLS change in proportion alongside authorization, secrets, dependencies, deployment configuration, and rollback evidence.

Sources

• Supabase changelog: An outdated subset of TLS 1.2 ciphers will be disabled on project HTTP APIs, published October 12, 2026.
• Supabase documentation: TLS for project APIs, checked October 13, 2026.

Disclosure: This article was prepared with AI assistance and checked against the primary sources listed above. It is general technical guidance, not evidence of a Sentrail scan, a customer incident, or a test of your clients.