Deploying to multi-node / cluster environments like k8s and impact on sessions, etc.

[205g0]

Describe the problem

From the docs, in particular the part about $app/stores, it is not clear how we can deploy Sveltekit in multi-node environments such as Kubernetes.

With express I would store session data on a database, single instance or replicated and get always the session from there. Hence, I can scale express indefinitely since it stays stateless. Is this also possible with SvelteKit? Meaning Svelte's session store would always get the session data from a db before it answers the request?

A simple chart of such an architecture:

The problem behind: Even if some cluster orchestration software allows to create sticky sessions, so requests hit the same node, it is not always possible to solve this problem on the cluster layer (e.g., when using BGP, autoscaling down, etc.) and it's in general more complicated than just storing the sessions on the db if latter is fast.

Describe the proposed solution

A paragraph in the docs stating if deploying to a multi-node cluster is possible and/or what trade-offs would be encountered (assuming the cluster layer does not offer sticky sessions).

Alternatives considered

No response

Importance

would make my life easier

Additional Information

No response

[rmunn]

Session handling is left up to you, using the provided hooks. In the configuration you're describing, you would write a handle hook runs first, takes the request, and extracts (for example) a session ID from a cookie and attaches that session ID to request.locals. Then the getSession hook would run, talk to the database and fetch the session data given the session ID, and return an object with the session data that the client should see (which will populate the $session store on the client). (Note: You could also do the DB query in the handle hook rather than the getSession hook, depending on whether you want that session data loaded for endpoints or just for pages. The best way to do that will depend on your app and what precisely you store in the session.)

Which means that scaling up would not be a problem, because session data would always be fetched from the DB service no matter which node answered the request.

[Angie9218]

Na

[205g0]

Ok, glad to hear and to summarize:

• To "sessionize" a page => in handle, do extract the session ID from the cookie and enrich request.locals, in getSession get session data from db and return in order to populate the $session store in the client
• To sessionize an endpoint => do all above in handle and before returning the endpoint's response; reason: the response depends very much on the session data in a typical app, .e.g,, the settings json of an individual user

Did I get it right?

[Angie9218]

Yes

[CaptainCodeman]

You can improve your scalability further by making the session cookie data into a bearer token (JWT)

This means you only need to do the database lookup when you are signing in or refreshing the access token, rather than on every single HTTP request.

The request effectively contains all the data needed to create the response (from a user info / permission perspective). The token is typically signed so you can verify that it hasn't been tampered with but this is a quick operation without any network request or database lookup (you should really do this even if using the DB sessions, so it's not extra work).

[lkj4]

The token is typically signed so you can verify that it hasn't been tampered with but this is a quick operation without any network request or database lookup

But how would I invalidate existing JWT tokens out in the wild if "it is just a quick operation without any network request or database lookup"?

[CaptainCodeman]

You can use two tokens, an access token and a refresh token. The access token is shorter lived and re-generated periodically using the refresh token. The time period it's valid for depends on the tolerance that makes sense for your app, it could be an hour for instance, which means changes to permissions would take half-an-hour on average to be reflected. But for some operations, you can insist that the token has to be refreshed, to check for access being revoked etc...

This will maybe explain it in more detail than I can:
https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

[lkj4]

This sounds like OAuth and all its complications. Why not just one short-lived, rolling token? Rolling means, that its expiration date gets extended on every request by a short time period. And in the case of invalidation, not anymore.

[CaptainCodeman]

It is, but it's not implementing OAuth completely, it's more just "consuming it as a client". The reason you wouldn't use a single token is that at some point a request will be made where the token has expired and as you say, what then? All you can do is re-authenticate the user at that point so the experience becomes poor OR you have to make the expiration period longer than you really want.

The access + refresh token has been thought through and allows for longer lived sign-in states while also shortening the lifetime of the access token and providing a mechanism for periodic re-checks.

[lkj4]

Ok, so you say...

• have a 1h access token with the userId encoded, so at least I save one db request to validate the session and getting the user id
• the refresh token has just the refreshTokenId encoded and is saved/read from the db

=> in a emergency I just invalidate the refreshToken by changing some field or deleting it and in the worst case, the user/bad actor has still max. 1h access to the system, not great but in specific use cases bearable

if I got it right, what I still wonder: I assume that I cannot save more stuff, e.g. user settings, in the access token in order to save further db requests, too small in size and I have to save stuff both to the token and the database which creates just a more complex system. Then, I have the benefit of just having one db request less? If I have tons of microservices which all authenticate all the time, this would add up. But even then, if I use some replicated DB with enough RAM and smart caching in the samte datascenter, I shouldn't see a significant latency by using just the db as a session store with one access token which is saved/read on the db. And I would get immediate invalidations and a much simpler system. Hope I missed something. but pls correct me if I am wrong.

[CaptainCodeman]

You save more than 1 db request - you save doing any db lookup for session on every request.

If something is really critical, you can insist that an access token is a freshly minted one to diminish any risk from the 1hr window but you can also keep a cache of revoked tokens which can be in-memory and quicker to check than storing sessions in a db for all users (you're just handling rare exceptions). And you can always make the access token 10 minutes, or a day, whatever makes sense for your system.

You can store additional claims in a token, to avoid looking things up. These might be flags (e.g. admin) or roles - whatever you need to be able to approve a request without doing an extra lookup.

[kinthaiofficial]

Multi-node SvelteKit deployments on k8s have a few specific considerations worth planning for:

Session state — the core problem:
SvelteKit's handle hooks run per-request, but if you store session data in-memory (a common pattern with @sveltejs/kit/vite), different pods will have different session stores. User A's session on Pod 1 won't be visible to Pod 2.

Solution: externalize session storage
Use Redis as the session store. Any k8s pod can read/write session state, requests can route to any pod:

// hooks.server.ts
import { RedisStore } from 'connect-redis';
import Redis from 'ioredis';

const redis = new Redis(process.env.REDIS_URL);

export const handle: Handle = async ({ event, resolve }) => {
  const sessionId = event.cookies.get('session_id');
  if (sessionId) {
    event.locals.session = await redis.get(`session:${sessionId}`);
  }
  return resolve(event);
};

Load balancer session affinity:
Alternative to Redis: configure your k8s ingress with session affinity (nginx.ingress.kubernetes.io/affinity: cookie). Sticky sessions route the same user to the same pod. Simpler, but pods can't gracefully drain — you'll lose sessions when a pod restarts.

Static assets:
If you're serving static assets from SvelteKit, make sure your CDN/ingress handles asset routing correctly. Better: serve static assets from a CDN (Cloudflare, CloudFront) and let SvelteKit handle only SSR traffic.

Health checks:
SvelteKit doesn't have a built-in health endpoint. Add one in hooks.server.ts:

if (event.url.pathname === '/healthz') {
  return new Response('ok');
}

What's the session strategy you're evaluating? Cookie-based, JWT, or server-side with external store?

[kinthaiofficial]

SvelteKit on Kubernetes works well but requires a few adjustments from the default single-instance setup.

The main challenge: session and state

SvelteKit's server-side load functions and form actions are stateless by design, which is great for K8s. The tricky part is anything that requires sticky sessions (WebSockets, SSE) or server-side session storage.

# If you're using SvelteKit's session/cookie handling:
# K8s service with session affinity for WS connections
apiVersion: v1
kind: Service
metadata:
  name: sveltekit-app
spec:
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 3600
  selector:
    app: sveltekit

Adapter selection matters:

# Use node adapter for K8s (not static, not Vercel)
npm install @sveltejs/adapter-node

// svelte.config.js
import adapter from '@sveltejs/adapter-node';
export default {
  kit: {
    adapter: adapter({
      out: 'build',
      precompress: true,
    })
  }
};

Health checks:

livenessProbe:
  httpGet:
    path: /health
    port: 3000
  initialDelaySeconds: 10

SvelteKit doesn't expose /health by default — add a +server.js route:

// src/routes/health/+server.js
export function GET() {
  return new Response('ok', { status: 200 });
}

Horizontal scaling works cleanly if you externalize sessions (Redis, Postgres) rather than using in-memory stores. The @sveltejs/adapter-node itself is stateless — shared state management is the application's responsibility.