Self-Hosting Supabase? Two Silent Default Changes Land This Week. Check Your Config Before It Breaks Your Login Flow.
Self-Hosting Supabase? Two Silent Default Changes Land This Week. Check Your Config Before It Breaks Your Login Flow.
If you self-host Supabase, two default changes are landing the week of July 6, and neither one is going to show up in a launch post or a keynote. The default API_EXTERNAL_URL in the self-hosted config now includes the /auth/v1 path prefix. And the Postgres log_connections setting is moving from on to off: projects created after July 9 default to off, with log_connections and log_disconnections now controllable through the config API.
That's it. That's the whole news. It's boring, it's small, and it's exactly the category of change that quietly wastes a Saturday when you pull the latest config and your login flow starts behaving differently and you have no idea why.
Why the boring stuff is the dangerous stuff
Nobody gets burned by the big, announced breaking changes. Those come with migration guides and everybody braces for them. You get burned by the two-line default flip in a changelog you didn't read, because it changes behavior without changing your code, so nothing looks wrong until something is very wrong.
Self-hosted Supabase is the definition of this risk for a solo operator. The whole reason you self-host is control and cost: one VPS, or one container stack, running your database, your auth, your storage, your API gateway, all managed by you and only you. There's no account manager emailing you a heads-up. There's no managed-platform team quietly handling the migration in the background. There's you, a docker compose pull, and whatever the defaults decided while you weren't looking.
The API_EXTERNAL_URL change
API_EXTERNAL_URL is the base URL your Supabase stack advertises to the outside world. It's what gets baked into things like auth redirect links, email confirmation URLs, and the endpoints your client SDK talks to. The default is moving from http://localhost:8000 to http://localhost:8000/auth/v1, the OAuth redirect placeholders in docker-compose.yml become ${API_EXTERNAL_URL}/callback, and the SAML SSO endpoints shift from /sso/saml/* to /auth/v1/sso/saml/*. When the default gains that /auth/v1 prefix, the concern is a mismatch: if your client SDK, your redirect configuration, or your reverse proxy is built around the old shape of that URL, and the default underneath shifts, the auth round-trip can resolve to a path that isn't where the thing it's looking for actually lives. Supabase is explicit that custom OAuth providers won't work without the change, so this isn't cosmetic if you rely on social login.
The failure mode isn't a crash. It's subtler and more annoying: a confirmation link that 404s, a redirect that lands on the wrong path, a login that works in your local setup because your local config predates the change and breaks in the environment where you took the new default. That's the worst kind of bug: the one that passes every test you run on your machine and only appears where it costs you.
I'm not going to tell you it will definitely break your setup, because it depends on how you've wired your URLs and proxy. I'm telling you it's the specific thing to check, because "auth base URL default changed shape" is precisely the change that produces a "why can nobody log in" ticket two days after a routine update.
The log_connections change
The second one is smaller but worth thirty seconds of thought. log_connections going from on to off means Postgres stops writing a log line every time a connection opens. New projects from July 9 inherit the off default, and Supabase is migrating existing Free and Pro projects to the new default too, so this isn't only a new-project concern.
For a lot of people, off is the sane default: connection logging is noisy and most of the time you don't need it. But if you've ever chased connection-pool exhaustion, an auth loop hammering new connections, or a runaway client on your self-hosted setup, that log line is the breadcrumb you follow. If it silently goes quiet, you lose a diagnostic exactly when the kind of problem it helps with is the kind you're likely to hit on a single-box deployment under load. The good news is it's now controllable through the config API, so this is a decision you get to make rather than a capability you lose. You just have to know to make it.
What I'd actually do
Pin your Supabase version. If you're running latest or pulling images without a fixed tag, that's the underlying problem, and it's bigger than these two changes. Pin to a specific version so updates are something you choose, on a day you've set aside, not something that arrives with a routine pull.
Read the changelog before you pull, not after something breaks. This is the unglamorous discipline that separates self-hosting that works from self-hosting that eats your weekends. Two minutes on the Supabase changelog before a docker compose pull is the cheapest insurance you'll buy all month.
Verify API_EXTERNAL_URL matches what your client SDK and your redirects actually expect. Test the full auth round-trip (sign up, confirmation link, redirect, login) in a staging environment that mirrors prod, not just locally where your old config might be masking the change.
Decide on connection logging on purpose. If you run close to your connection limits or you've debugged pool issues before, turn log_connections back on through the config API and keep your breadcrumb. If you don't need it, let it stay off and enjoy the quieter logs.
Here's the honest counter-take, because self-hosting takes enough flak already: none of this is an argument against self-hosting Supabase. Self-hosting is a real, sane hedge against platform risk: the disappearing free tier, the surprise pricing change, the vendor decision you don't control. This is just the tax that comes with it, and it's a fair one: when you own the stack, you own the changelog too. The people who get burned aren't the ones who self-host. They're the ones who self-host and then run it like a managed service, pulling latest and hoping. Own the box, own the config, and a week like this one is a five-minute check instead of a Saturday.
Author
Lukas
@lukcombinator