How to use WebSockets with the Vercel adapter?

[alexbjorlig]

I would like to experiment with WebSockets. Our application is delpoyed using the official Vercel adapter.
Now that Vercel announced support for websockets, this made me think - is there an official way to use websockets in Sveltekit when using the Vercel adapter?

The end-goal would be to build something simple with socket.io, so we don't need a pusher subscription.

[brunnerh]

WebSocket support is in limbo, see #12973

@teemingc any news on when there will be websockets support? really really looking forward to it!

We're focusing on SvelteKit 3 right now. We will revisit WebSockets after

[brunnerh]

(In case you only need live data updates from the server rather than duplex communication, I would recommend using server-sent events for now.)

[MILLERMARRU]

Worth separating what's actually in limbo from what already exists. adapter-vercel itself doesn't wire up WebSocket upgrade handling today, that's exactly the gap tracked in #12973, and teemingc's comment confirms it's deprioritized behind SvelteKit 3 work.

The Vercel platform side is real though, and it isn't Next.js-specific. @vercel/functions ships experimental_upgradeWebSocket, and any Vercel Function that returns a Response from a Fetch-API-shaped handler can use it:

import { experimental_upgradeWebSocket, type WebSocketData } from '@vercel/functions'

export async function GET() {
  return experimental_upgradeWebSocket((ws) => {
    ws.on('message', (data: WebSocketData) => {
      ws.send(data)
    })
  })
}

A SvelteKit +server.js GET handler is exactly that shape, a function returning a Response, so in principle there's nothing framework-specific stopping you from calling this directly inside one, since adapter-vercel compiles each server route down to a Vercel Function already. I haven't seen anyone confirm adapter-vercel's build step passes that response through untouched rather than wrapping or re-serializing it, and that's the actual unknown behind the open issue, not whether Vercel supports WebSockets at all.

For getting unblocked now rather than experimenting: deploy the socket.io server as its own separate Vercel Function (outside the SvelteKit build, or even a separate minimal Vercel project) using experimental_upgradeWebSocket directly, and point socket.io-client at that endpoint from your SvelteKit frontend. That sidesteps the adapter question entirely and is the path most likely to just work today.

[latent-9]

Short version: you cannot run a WebSocket server on adapter-vercel. Vercel's serverless and edge functions are request-scoped and get torn down after each response, so they cannot hold the long-lived connection a WebSocket needs. SvelteKit's experimental WebSocket support only works on adapters that keep a persistent Node server alive (adapter-node or a custom server).

Practical options:

• Offload realtime to a managed service (Ably, Pusher, Supabase Realtime, or PartyKit) and keep the rest of the app on Vercel.
• Deploy just the WebSocket piece on a host that stays alive (Fly, Render, Railway) and point the client at it.
• If you only need one-way server to client updates, Server-Sent Events over a streamed endpoint do work on Vercel and are much lighter.

So the app itself can stay on Vercel. The socket server just has to live somewhere persistent.

[teemingc]

I don't think that's true. https://vercel.com/docs/functions/websockets seems to imply it's possible now

[brunnerh]

...and most server-sent events connections are also long-lived.

[kaminagakur4]

@MILLERMARRU's snippet is the right call, and the unknown you named is answerable from the package itself. The Response never mattered.

experimental_upgradeWebSocket doesn't hand the handshake back through the return value. It reads the runtime bridge off globalThis[Symbol.for('@vercel/request-context')], and the typing for that hook says exactly what it does (@vercel/functions@3.9.3, get-context.d.ts):

Low-level WebSocket upgrade provided by the runtime bridge. Writes a 101 response on the underlying socket, detaches it from the ServerResponse, and returns the raw req/socket/head tuple for use with libraries like ws.

So by the time your handler returns, the 101 is already on the wire and the socket is detached. What comes back is a 204 placeholder. Whether adapter-vercel passes that through untouched or wraps it makes no difference to the connection. That closes the SvelteKit half: the adapter isn't the blocker.

What I can't confirm from here is the half that actually decides it, which is whether Vercel's launcher populates ctx.upgradeWebSocket for a function that adapter-vercel emits rather than only for Next.js routes. Two things lean against it. Vercel's WebSockets doc introduces the API purely as a Next.js workaround, verbatim: "Next.js does not expose an API for handling WebSocket upgrades. As a workaround, you can use the experimental_upgradeWebSocket() API". Every non-Next example on that page exports a native http.Server instead. And the library carries a specific error for this exact case, in websocket/index.js:

experimental_upgradeWebSocket is not available in the current runtime environment.
This feature requires a Vercel runtime that supports WebSocket upgrades.

That makes it cheap to settle. Put one +server.js behind a preview deploy, point a wss:// client at it, and see which you get. That error means the bridge doesn't reach adapter-vercel functions. An echo means it does. Either result is worth posting here, since the thread has been circling this for a week.

Two things that will bite before you get that far. ws is an optional peer dependency of @vercel/functions, so npm i @vercel/functions doesn't bring it and you'll hit "The "ws" package is required" at runtime. And on the socket.io route the client needs path: '/api/socket-io/socket.io' and transports: ['websocket'], because socket.io appends /socket.io and otherwise defaults to HTTP long polling.

Last thing, and it's the one that matters most for dropping Pusher. The same doc says new connections aren't guaranteed to reach the same function instance, and tells you to keep rooms, presence and pub/sub in an external store. A module-level io with in-memory rooms will only reach the clients that landed on that instance, silently. socket.io only broadcasts across instances with an adapter, so you'd be back to running Redis, which is a fair chunk of what you were trying to avoid.