Vercel WebSockets: migrate or watch?

Vercel Functions can now hold real WebSocket connections. The June 22 public beta adds RFC 6455 upgrade support to Vercel Functions, with ws, Socket.IO, FastAPI WebSockets, python-socketio, Express, Hono, Nitro, and Nuxt listed as supported stacks. 1 2

For teams that already ship web apps on Vercel, this changes the shape of the platform. Real-time features no longer have to leave the Vercel runtime by default. The practical question is narrower: whether this beta is solid enough for your production path, or whether it should stay in a prototype branch until Vercel publishes clearer limits.

A WebSocket connection now pins to one Vercel Function instance for the lifetime of that connection. That matters because every message on that socket reaches the same instance, while Fluid Compute can let one instance handle multiple WebSocket connections. 2

Vercel is not selling this as a separate product tier. WebSocket traffic uses the existing Vercel Functions billing model: Function active time, Fast Data Transfer, and Fast Origin Transfer. Vercel's pricing page lists Hobby as free, Pro at $20 per month, and Enterprise as custom-priced. 2 3

Next.js projects need experimental_upgradeWebSocket() from @vercel/functions; Python ASGI support works with FastAPI WebSockets and python-socketio. Vercel's official sample app, vercel-labs/nextjs-websocket-chat-app, demonstrates a chat app with online presence, typing indicators, and Redis-backed broadcasting across instances. 2 4

Guillermo Rauch, Vercel's CEO, said on X that WebSocket and Socket.IO were now supported on Vercel "from CDN to Fluid" and called the release a "Special full circle moment for @vercel." The launch post had 1,156 likes and about 270,000 views in the research snapshot. 5

The first-order win is stack reduction. A Vercel-hosted app that only needs moderate real-time behavior can now keep its HTTP routes, server-rendered UI, and socket endpoint in one deployment surface instead of adding a separate realtime provider by default. Vercel's docs list chat, collaboration, live notifications, multiplayer experiences, and AI streaming interfaces as target use cases for the beta. 2

The second win is operational symmetry. WebSocket upgrade requests pass through the same routing and security controls as ordinary HTTP requests, including Routing Middleware, rewrites, Firewall rules, and rate limits. 2 For DevOps teams, that is cleaner than running a sidecar service whose ingress, auth, logs, and rate controls live elsewhere.

The third win is timing. Vercel also shipped zero-configuration Node.js API server deployment on June 23 and raised Pro-team concurrent builds from 12 to 500 on June 24. 6 7 Those are separate updates, but they point in the same direction: Vercel is reducing reasons to move API and realtime work off-platform.

The implementation still has serverless-shaped edges. Vercel says a WebSocket connection closes when the Function reaches its maximum duration, so clients must implement reconnection with exponential backoff. 2 That is acceptable for many chat, presence, notification, and dashboard workloads. It is a poor fit for clients that assume a single long-lived connection can survive without reconnect logic.

State also needs to live outside the Function instance. Vercel's documentation says in-memory state is not persistent across instances or deployments, and it recommends an external store such as Redis from Vercel Marketplace for shared state. 2 That pushes serious multi-room chat, collaborative editing, fan-out, and presence tracking into an architecture that still depends on a durable backend.

The main missing piece is limits. Vercel's public docs did not specify maximum connection counts, message-size ceilings, or idle-timeout values beyond the general Vercel Functions limits. 2 A low-interaction Reddit thread from r/AppDevelopers captured the early adoption mood: developers who had been using Supabase or Firebase for realtime features were interested in keeping a simpler Vercel-centered stack, but the thread did not provide production-scale testing data. 8

Migrate small realtime features now if the app is already on Vercel, the connection count is modest, and the feature can tolerate reconnects. Good candidates include admin dashboards, lightweight chat, collaborative cursors, deployment-status streams, and AI progress updates. The benefit is immediate: fewer services, one deployment target, and no separate WebSocket-specific pricing tier. 2

Prototype before migrating core realtime infrastructure if the workload has high fan-out, strict latency expectations, long-lived sessions, or cost sensitivity under sustained connection load. The beta docs leave important capacity numbers unpublished, and WebSocket connections still inherit Function-duration behavior. 2

Do not migrate only to remove Redis. Vercel's own sample architecture uses Redis for cross-instance broadcasting, and the docs say shared state must live in an external data store. 2 4 The feature removes the need for a separate socket server in some cases; it does not remove the need for a state layer.

The cleanest adoption path is a single non-critical realtime feature behind a flag. Measure active Function time, transfer volume, reconnect frequency, and instance fan-out before moving anything central. If Vercel publishes explicit connection and message limits during the beta, that table will decide how far this can move from convenience feature to default realtime platform.