SvelteKit + Supabase: cookie-based SSR client in hooks.server.ts, per request

SvelteKit + Supabase: cookie-based SSR client in hooks.server.ts, per request

TL;DR

SvelteKit renders on both sides, so agents pick one client and use it everywhere. That breaks in both directions: the browser client has no cookies on the server, and a shared server client leaks sessions between requests. A client created at module scope in $lib/ and imported by +page.server.ts files is shared across requests.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Steps

1. Install @supabase/supabase-js and @supabase/ssr.

   Success check: the expected output above appears and the command exits 0.

2. In hooks.server.ts, create the server client per request with createServerClient, wiring its cookie interface to SvelteKit's event.cookies: getAll from event.cookies.getAll(), setAll writing back through event.cookies.set().

   Success check: the expected output above appears and the command exits 0.

3. Expose the session/user on event.locals in the handle function so load functions and server routes can read auth state without rebuilding clients.

   Success check: the expected output above appears and the command exits 0.

4. In +layout.ts (the universal load), create the browser client with createBrowserClient for client-side navigation. Server load functions (+page.server.ts) use the request-scoped server client from locals.

   Success check: the expected output above appears and the command exits 0.

5. Verify with supabase.auth.getClaims() on the server before trusting who the user is. getSession() on the server reads an unverified cookie.

Compatibility

Tool: Supabase. The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

SvelteKit + Supabase: per-request server client via hooks.server.ts

The leak to check for

Symptoms are intermittent: user A occasionally sees user B's data, usually under load when requests overlap. The fix is always the same, create it inside the request handler.

Quick test

Two browsers, two users, hit a server-loaded page that shows the email at the same time. Then expire the access token and confirm navigation still works, the hooks refresh keeps the session alive.

Verified against live Supabase docs 2026-09-26: https://supabase.com/docs/guides/auth/server-side/creating-a-client