v0.1.79 — 12 Jun 2026
Bug Fix — Cookie-based SSR auth now works when internal and public Supabase URLs differ
Who is affected: Self-hosted deployments that set both
SUPABASE_INTERNAL_URL and NEXT_PUBLIC_SUPABASE_URL to different values
(for example, internal service DNS for server code and public HTTPS URL for
browser access).
What was wrong
After introducing SUPABASE_INTERNAL_URL, server-side requests could fail to
pick up browser auth cookies in some environments. Sessions appeared valid in
the browser but were not consistently recognized by middleware/SSR code.
Root cause
Supabase SSR derives the cookie name from the URL passed to
createServerClient. When server code used SUPABASE_INTERNAL_URL, that
derived cookie name could differ from the browser cookie name derived from
NEXT_PUBLIC_SUPABASE_URL.
What changed
Server-side clients now explicitly set the cookie name derived from
NEXT_PUBLIC_SUPABASE_URL via cookieOptions.name, while still connecting to
Supabase through SUPABASE_INTERNAL_URL for server-to-server traffic.
Before / After
| Scenario | Before this fix | After this fix |
|---|---|---|
| Internal URL differs from public URL | ❌ Cookie-based SSR auth could fail intermittently | ✅ Cookie-based SSR auth resolves consistently |
| Server network path | ✅ Internal URL used | ✅ Internal URL still used |
| Browser auth cookie compatibility | ❌ Could mismatch | ✅ Explicitly aligned |