Vercel Adds WebSocket Support: Run Node.js Socket.IO Projects Directly

If you previously deployed real‑time chat, collaborative editing, or online‑status features to Vercel, you likely accepted the convenience of serverless pages but had to host WebSocket backends elsewhere. Vercel now fills that gap by adding WebSocket support in a public beta.

This is what’s supported

Vercel Functions can now accept WebSocket connections, maintaining bidirectional communication between client and server code. This directly benefits several common scenarios:

AI streaming interactions : not just SSE one‑way output, but continuous client‑to‑server events.

Chat rooms and notifications : a persistent connection enables real‑time message push.

Collaborative apps : document editing, whiteboards, presence, and room sync gain a natural transport layer.

Games and interactive pages : low‑frequency real‑time interactions no longer require a separate backend platform.

The official Vercel example uses standard Node.js code:

import express from 'express';
import { createServer } from 'http';
import { WebSocketServer } from 'ws';

const app = express();
const server = createServer(app);
const wss = new WebSocketServer({ server });

wss.on('connection', (ws) => {
  ws.on('message', (data) => {
    ws.send(data);
  });
});

export default server;

Developers appreciate that no special Vercel‑specific transformation of a regular Node.js WebSocket service is required.

Socket.IO works too, but watch this detail

Vercel’s docs confirm that higher‑level libraries like Socket.IO are usable, provided the client forces the WebSocket transport. Socket.IO normally falls back to HTTP long‑polling before upgrading, but Vercel’s beta only guarantees raw WebSocket connections.

Typical client configuration:

import { io } from 'socket.io-client';

const socket = io('https://your-domain.com', {
  path: '/api/socket-io/socket.io',
  transports: ['websocket'],
});

This enables existing Socket.IO projects to stay on Vercel without rewriting to plain ws, preserving rooms, namespaces, and broadcast capabilities.

The real challenge: scaling WebSockets in a serverless world

WebSockets look simple but become complex when placed in serverless or on‑demand environments. Matteo Collina, a prominent voice in the Node.js community, notes that long‑lived connections occupy resources and raise routing, allocation, and connection‑bundling issues when scaling.

Vercel’s model ties each WebSocket connection to a single Function instance for its lifetime. Fluid Compute allows a Function instance to handle multiple connections, explaining why the feature works yet why it cannot be treated as an “infinitely scalable in‑memory chatroom.”

Two important limits to remember:

WebSocket support requires Fluid Compute, which is enabled by default for new projects.

Connections are subject to the maximum execution time of a Vercel Function; once the limit is reached, the client must reconnect.

Reconnections may land on a different Function instance, and new deployments can receive new connections while old ones remain on previous deployments. Consequently, application state must not be stored in memory.

Production‑ready implementations should externalize the following data:

Room‑to‑channel mappings

Online presence information

Counters

Cross‑instance broadcast coordination

State recovery after reconnection

Vercel’s example mentions Redis as an external store, reinforcing the pattern: WebSocket handles the connection, while persistent state lives elsewhere.

What this means for full‑stack front‑end developers

Previously, Vercel projects often suffered a split architecture: pages, API routes, and Server Actions lived on Vercel, while real‑time services ran on a separate platform, adding deployment, CORS, auth, and monitoring overhead.

With WebSocket support in Vercel Functions, small teams can keep their tech stack unified. Node.js‑centric internal tools, AI demos, and collaborative prototypes no longer need a large, separate real‑time infrastructure.

The real value is not just the headline “Vercel now supports WebSocket,” but the return of real‑time capability to the default full‑stack workflow: a Next.js front‑end can write an API, access a database, and now also expose a WebSocket endpoint without leaving the Vercel ecosystem.