Next.js and WebSockets

The plain-language idea

A WebSocket connection is a single TCP connection, upgraded from an HTTP request, that both client and server keep open indefinitely so either side can push messages at any time. That requires one specific server process to hold that connection in memory for the connection's whole lifetime.

Next.js's default deployment target — Vercel, and most serverless/edge platforms modeled on it — runs each request as an independent, short-lived function invocation. There's no guarantee that two requests from the same browser land on the same process, invocations are expected to finish quickly (and get killed if they run long), and the whole scaling model assumes requests are stateless and interchangeable. A Route Handler can't hold a socket open for an hour without either the platform killing it or the platform being unable to horizontally scale, because "which server has this socket" becomes state the platform now has to track. This isn't a Next.js limitation exactly — it's a mismatch between what WebSockets require (a stateful, long-lived process) and what serverless compute is designed to make cheap (stateless, short-lived ones).

The real patterns route around this rather than fighting it:

• A managed realtime service (Pusher, Ably, Supabase Realtime, PartyKit) — your Next.js app talks HTTP to their API to publish events; they run the actual long-lived connections on infrastructure built for it.
• Server-Sent Events (SSE) from a Route Handler — one-directional server-to-client streaming over a plain HTTP response, which fits a fetch-based Route Handler far better than a raw socket does, at the cost of losing client-to-server push.
• A separate, always-on WebSocket server — a small Node process (on a VM, a container, or a platform with long-running compute) that your Next.js app is otherwise independent from, reached via its own domain or port.
• Self-hosting Next.js on a persistent Node server — if you're not on serverless at all, a custom server can attach a WebSocket server to the same HTTP server Next.js is already running on, since the "one process holds the connection" assumption is satisfied by construction.

See it in a real thing: SSE from a Route Handler for a live notification feed

// app/api/notifications/stream/route.ts
export async function GET() {
  const encoder = new TextEncoder();

  const stream = new ReadableStream({
    start(controller) {
      const send = (data: string) => {
        controller.enqueue(encoder.encode(`data: ${data}\n\n`));
      };

      const interval = setInterval(() => {
        send(JSON.stringify({ count: getUnreadCount() }));
      }, 5000);

      // Runs when the client disconnects — without this, the interval
      // keeps the connection (and the server-side work) alive forever.
      return () => clearInterval(interval);
    },
  });

  return new Response(stream, {
    headers: {
      "Content-Type": "text/event-stream",
      "Cache-Control": "no-cache",
      Connection: "keep-alive",
    },
  });
}

// app/notifications/notification-badge.tsx
"use client";

import { useEffect, useState } from "react";

export function NotificationBadge() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const source = new EventSource("/api/notifications/stream");
    source.onmessage = (event) => setCount(JSON.parse(event.data).count);
    return () => source.close();
  }, []);

  return <span>{count}</span>;
}

This gets server-to-client push over a Route Handler's own Response object — no separate socket infrastructure, no NextRequest/NextResponse extensions needed, just a streamed HTTP response the browser's built-in EventSource knows how to consume. The tradeoff is baked into the protocol: SSE is one-directional, so a chat app that needs the client to send messages back still needs a second channel (a normal fetch POST, or a Server Action) alongside it.

What people usually miss

Watch out

• This isn't a bug or a missing feature — it's an architectural mismatch. Serverless compute is cheap and scales well precisely because it assumes requests are short and stateless. A raw WebSocket in a Route Handler fights that assumption directly, on every platform built around it, not just Vercel.
• SSE gets you push notifications without a socket, but it's one-directional. It solves "server tells the client something changed," not "client and server exchange messages in real time" — a genuine bidirectional need (live cursors, chat, collaborative editing) still needs a real WebSocket or a managed realtime service.
• Self-hosting on a persistent Node server changes the calculus entirely. If you're running next start (or a custom server) as one long-lived process rather than deploying to serverless functions, you can attach a ws server to the same HTTP server and it works exactly like it would in any Node app — the constraint is about the deployment model, not about Next.js as a framework.
• A managed realtime service isn't a downgrade — it's usually the right call even when self-hosting is an option. Running your own WebSocket infrastructure means owning reconnection logic, horizontal scaling with sticky sessions or a shared pub/sub layer, and backpressure handling; a service built for exactly this problem is often less total engineering effort than reinventing it.

The genealogy: an extension of the streaming and serverless-runtime story

This connects directly to the runtimes lesson: the Node.js and Edge runtimes Next.js Route Handlers can run in are both built around short-lived invocations, which is the same root constraint that rules out a long-lived WebSocket inside one. It's also a sibling to server-rendered streaming with Suspense — both are about pushing data to the client incrementally over time — but Suspense streams a single response once and finishes, where a live feed (via SSE or a socket) keeps sending indefinitely after the initial response has already completed.