WebSockets on Vercel: why serverless functions can't host them

Vercel's serverless functions operate on a request-response model. Each incoming request triggers a function invocation. When the function returns a response, the invocation ends.

WebSockets require the opposite. A WebSocket connection is persistent and bidirectional - the server holds the connection open, receiving messages from the client and sending messages back, for the lifetime of the session. There's no request-response boundary to trigger a new invocation, and no persistent process to maintain state.

The architectures are incompatible. Vercel's Knowledge Base is direct: Vercel Functions do not support acting as a WebSocket server.

Vercel's Fluid Compute feature allows functions to persist between requests, reducing cold starts and making long-running AI streaming practical. It's part of what makes production AI deployment on Vercel viable.

But Fluid Compute doesn't change the connection model. Streaming responses and WebSocket connections are different things. A streaming SSE response is still a standard HTTP response - the function returns a body that streams progressively, and the connection closes when the stream ends. A WebSocket upgrade requires the server to maintain the connection indefinitely after the HTTP handshake.

Vercel's community documentation is explicit: WebSocket connections are not supported even with Fluid Compute enabled. The distinction Vercel draws is between streaming (which Fluid Compute enables) and persistent bidirectional connections (which it doesn't).

Host the WebSocket server outside Vercel's serverless tier. A dedicated container, VM, or managed server can hold persistent connections. Your Next.js application continues to deploy on Vercel; WebSocket connections route to a separate service. This gives you full control and keeps your Vercel deployment clean, at the cost of running and scaling additional infrastructure.

Use a third-party WebSocket provider. Vercel's Knowledge Base page on WebSocket support recommends this explicitly. The listed providers are: Ably, Convex, Liveblocks, Partykit, Pusher, PubNub, Firebase Realtime Database, TalkJS, SendBird, and Supabase. You connect your application to the provider's infrastructure and use their client libraries to subscribe and publish. The WebSocket server is managed for you.

Stay on SSE for simple cases. If your use case genuinely doesn't need bidirectional communication - the user submits a message, the server streams a response, and there's no need to send anything from client to server during generation - SSE may be sufficient. The limitations are real: no stream recovery on disconnect, no multi-device delivery, cancellation that may not reach the server. But for a simple chatbot on a stable network, SSE is still a defensible starting point before adding transport complexity.

For simple chatbots the SSE constraint is manageable. For production AI applications, the failure modes accumulate fast.

Long-running agents hit Vercel's function timeout limits - 300 seconds at maximum. A multi-step agent doing retrieval, reasoning, and tool calls can get close. Sessions that need to survive tab switches, device changes, or mobile network transitions require a connection model that outlasts any single HTTP request. And sending a cancel or steer instruction to the server while generation is in progress is structurally impossible over SSE: the connection is one-way.

These are the problems the ChatTransport interface in Vercel AI SDK was built to address. Rather than bind useChat to a specific protocol, Vercel made transport pluggable. A third-party WebSocket provider connects to useChat through a ChatTransport implementation, and your application code doesn't change:

const { messages, sendMessage, stop } = useChat({
  transport: new MyWebSocketTransport()
});

The hook, the agent, the tool calls, and the UI rendering all stay as they are. The transport is what changes.

Not every WebSocket provider is suited for AI streaming. The specific requirements:

Session continuity on reconnect. The provider should support offset-based message history so a reconnecting client can catch up without replaying the entire generation or losing output that arrived during the disconnect.

Bidirectional signaling. AI applications need to send structured messages from client to server during a session - cancel, steer, redirect. A provider that supports typed channel messages handles this as a first-class operation.

Fan-out. Delivering the same stream to multiple clients - tabs, devices, a monitoring dashboard - requires the provider to support channel subscriptions where multiple clients share a single session.

Protocol fallback. Enterprise networks and mobile connections don't always support WebSocket upgrades reliably. A provider with automatic fallback to HTTP streaming or long-polling keeps the application working on networks where WebSockets fail.

Ably AI Transport integrates with the Vercel AI SDK to add durable sessions, multi-device sync, and bidirectional control to your chat application. Visit the Ably AI Transport overview, read the documentation, or sign up free

Ready to build? Get started with Vercel AI SDK.

Sources: Vercel KB: Do Vercel Serverless Functions support WebSocket connections?; Vercel Fluid Compute; Vercel Function Limits; AI SDK UI Transport documentation; AI SDK 5 announcement.