Self-Hosted Supabase v0.7.0 Brings Three API Gateway Compatibility Changes

Supabase's self-hosted v0.7.0 release deserves more attention than its version number suggests. The maintainer labels it as a breaking API gateway change in the release notes, and the release body names three compatibility shifts that can affect clients, authentication links, and database exposure. None of them is difficult to understand in isolation. The risk comes from upgrading a running stack while assuming that the gateway behavior stayed the same.

The first change is the most visible to tooling. The Data API OpenAPI specification at /rest/v1 is no longer accessible through an anon or publishable key. A team that used that endpoint to generate a client, expose an API catalog, or let a low-privilege tool inspect the schema should test the new access path before moving the tag into production. This is not the same as saying that every REST request now fails. It is a specific change to access to the OpenAPI document, and the release note does not claim more than that.

The second change affects URL construction. API_EXTERNAL_URL now includes /auth/v1, and SAML SSO endpoints move under /auth/v1/sso/saml/*. Deployments that assemble callback URLs themselves, put an auth gateway behind a reverse proxy, or have an identity provider configured with an older path should compare the generated URL with the new layout. A stale callback can look like an authentication outage even when the database and GoTrue services are healthy.

The third change is about the default schema list. The release says that PGRST_DB_SCHEMAS now drops the protected storage schema by default. That is a safer default for many installations, but it can surprise a stack that deliberately exposed storage-related objects through PostgREST. Operators should decide whether that exposure was intentional, then make the setting explicit rather than relying on an old default.

A small release with a real upgrade checklist

The safest way to approach this tag is to treat it as a configuration review. Before upgrading, record the current values for the API external URL, the PostgREST schema list, and any client or CI job that reads /rest/v1 to discover the API. Then run a staging instance of v0.7.0 and exercise the actual paths used by the application. The self-hosting guide provides the surrounding deployment context, but the release itself is the authority for these three changes. The point is not to invent a migration script from a four-line release note. It is to turn each stated breaking change into a test that reflects your deployment.

Teams using Supabase as a managed service should not assume this note applies to them in the same way. This release is explicitly for the self-hosted tag. The Supabase profile is still the right place to compare the product and hosted-plan context, but the operational changes here concern the self-hosted gateway and its environment variables.

The distinction matters for internal documentation too. A runbook that says “the REST schema is discoverable with the public key” is now too broad for a self-hosted v0.7.0 stack. A runbook that hard-codes the old SAML callback path is similarly fragile. Update those statements with the deployment version beside them, so a future operator can tell whether a failure is a version mismatch or a real service incident.

What to test first

Start with the client that uses the OpenAPI document. If it only reads the document during development, the fix may be as simple as using a privileged server-side path during schema generation. If a running service depends on that access, the change is more consequential and should block a blind upgrade.

Next, test the complete authentication loop rather than only the login screen. Include the redirect through the reverse proxy, the SAML assertion consumer path, and the callback that returns the user to the application. The new /auth/v1 prefix is easy to miss because the rest of the stack can still answer health checks.

Finally, test a request that depends on objects in the protected storage schema. If the application should not see those objects, the new default is a helpful boundary. If it should, declare the desired schema list explicitly and review the exposure as part of the change.

The verdict is straightforward: self-hosted operators should not apply v0.7.0 as a routine image refresh. Read the three release notes, stage the tag, and verify the API discovery, auth callback, and storage-schema assumptions that your own stack makes. For a deployment with none of those dependencies, the release may be low drama. For one that has them, the compatibility check is the work.