WebSockets on Vercel: native support, limits, and your options

Native WebSocket support shipped in public beta on June 22, 2026, built directly into Vercel Functions. Under the hood, accepting the upgrade triggers a standard function invocation. Whichever instance handles that invocation stays pinned to the connection for its full duration.

That pinning is the important detail. Vercel's own knowledge base is explicit: established connections are pinned to the function for its maximum duration, and future connections aren't guaranteed to land on the same instance. There's no built-in way to broadcast a message to connections held by other instances. There's no presence either, and no delivery guarantees beyond the single pinned connection. It also requires Fluid compute. But since this has been the default for new Vercel projects since April 2025, most current projects already meet the requirement.

There are three main ways to add WebSocket support to a Vercel app today.

As of the June 2026 beta, a single-instance, session-scoped connection can now run directly on Vercel Functions, with Fluid compute enabled. The default duration cap is 5 minutes. An extended 30-minute ceiling exists in beta, but only on Pro and Enterprise plans, with function-level configuration and specific Node.js and Python runtime versions.

• Works well for something like a single client holding one ongoing conversation with your backend.

• Doesn't give you fan-out, presence, or guaranteed ordering.

Anything with multiple subscribers, multiple instances, or a longer-lived connection still needs one of the options below. For a full breakdown of what native support does and doesn't give you compared to a dedicated pub/sub layer, see Vercel WebSockets vs Ably: fan-out, presence, and ordering compared.

A dedicated container, VM, or managed server, on a platform like Fly.io, Railway, or a traditional cloud VM, can hold persistent connections. Your Next.js application continues to deploy on Vercel; WebSocket connections route to a separate service you run and operate yourself.

• Gives you full control over the connection and a clean split from your Vercel deployment.

• Costs you the ongoing work of deploying, scaling, monitoring, and security-patching a second service.

• Doesn't solve fan-out, presence, or delivery guarantees on its own: those are still yours to build on top of the raw connection, the same tradeoff as running a coordination layer against Vercel's native beta.

• Adds a second point of failure and a cross-service auth boundary to manage.

Vercel's Knowledge Base page on WebSocket support still recommends this for anything beyond a single-instance connection, and lists providers explicitly, including Ably.

• 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.

Alternatively, you can stick with SSE, which works within Vercel's standard request-response model without any extra setup, for simple use cases. SSE may be sufficient if your use case doesn't need bidirectional communication (the user submits a message, the server streams a response, and there's nothing to send from client to server during generation), you're building for a stable network, and losing in-flight output on disconnect, no multi-device delivery, and cancellation that may not reach the server are all acceptable tradeoffs.

For simple chatbots, SSE's one-way limitation is manageable. For production AI chat and agent applications, it isn't, and neither is Vercel's native WebSocket beta on its own.

SSE can't carry a cancel or steer instruction from client to server while generation is in progress, since the connection only flows one way. It also can't survive tab switches, device changes, or mobile network transitions, since there's no connection model that outlasts a single HTTP request.

Native WebSocket support narrows the first problem. For a single pinned connection, cancel and steer signals now have a real bidirectional path to travel over. But it doesn't solve either problem at the level production AI chat and agent apps need.

It inherits the same function timeout as SSE, since a WebSocket connection is itself a function invocation. Long-running agents doing retrieval, reasoning, and tool calls still hit that ceiling.

And because the connection is pinned to one instance, multi-device continuity is still unsolved. Cancellation across devices needs a provider that can reach every instance a session touches, not a single pinned socket.

For the person using the app, that gap shows up directly: an agent that won't stop mid-response on one device, or a support handoff that loses context switching from phone to laptop, feels broken regardless of what's happening under the hood.

These are the problems the ChatTransport interface in Vercel AI SDK was built to address. For a detailed breakdown of the four production requirements that make this necessary, see Vercel AI SDK in production: when DefaultChatTransport needs a session layer.

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.

Once you've decided a third-party provider is the way to go, not every one is suited for AI chat and agent streaming. Here's four criteria to look for:

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

2. Bidirectional signaling. AI chat and agent applications need to send messages back to the server mid-session, to cancel, steer, or redirect a response, not just receive one. A provider built for this handles it natively, rather than requiring you to build it yourself.

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

4. 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.

Each of those four requirements maps directly to something Ably AI Transport already does:

1. Session continuity comes from automatic reconnection recovery, no configuration needed for brief disconnects. Persisted history is a separate, opt-in feature for longer retention windows, but it isn't what session continuity relies on.

2. Bidirectional signaling runs through Ably's channel model, so cancel and steer messages travel back to the server without a side channel.

3. Fan-out goes to any number of subscribers, not just one pinned connection.

4. Protocol fallback is handled automatically on networks that block WebSocket upgrades.

It plugs into the Vercel AI SDK through the same ChatTransport interface described earlier in this page. Adopting it doesn't touch your agent code, tool calls, or UI, only the transport underneath changes. It also adds durable sessions that survive device switches and reconnects, and support for a human to take over a conversation mid-stream, neither of which you'd get from a raw connection alone.

Visit the Ably AI Transport overview, read the documentation, or sign up free.

Ready to build? Get started with Ably AI Transport for the Vercel AI SDK.

Connect a third-party WebSocket provider to useChat through a ChatTransport implementation. Vercel's Knowledge Base lists recommended providers, and swapping the transport doesn't require changes to your agent code or UI.

For simple single-device chatbots on stable networks. It breaks down for long-running agents, sessions that need to survive tab switches, and anywhere cancellation needs to reliably reach the server.

Yes. It's required, and has been the default for new Vercel projects since April 2025, so most current projects already meet the requirement without extra configuration.

Yes. A dedicated container, VM, or managed server, on a platform like Fly.io, Railway, or a traditional cloud VM, can hold the connection, while your Next.js application continues to deploy on Vercel. You run and operate that service yourself.

Only for a single connection. Cancel and steer signals have a real bidirectional path to travel over, but that stops at the one pinned instance: it doesn't extend across devices, and it doesn't survive a dropped connection.