Building a real-time feature into a Next.js app looks deceptively straightforward at first — add socket.io-client to your React component, create an API route, import Socket.IO server-side, and you're done. It works perfectly in local development. Then you deploy to Vercel and connections start dropping, messages stop arriving, and the browser console shows a stream of reconnection attempts. The problem isn't Socket.IO. It's that Vercel's serverless execution model and WebSocket's persistent connection requirement are incompatible by design. This guide explains why, and gives you an architecture that actually holds up in production.
Why Next.js and Socket.IO Have a Complicated Relationship
To understand the incompatibility, you need to understand how Vercel runs Next.js API routes. When a request hits a Next.js API route on Vercel, the platform spins up a serverless function — a short-lived Node.js execution context — to handle it. The function processes the request, sends a response, and the context is torn down. There is no persistent process sitting idle between requests. Each invocation is completely stateless.
WebSockets work the opposite way. A WebSocket connection starts with an HTTP handshake, then upgrades to a persistent TCP connection that stays open for the duration of the session. The server process must remain alive, connected, and able to receive messages at any point. When a user sends a chat message 45 seconds after connecting, the same server process that accepted the original connection needs to handle it.
When you try to use Socket.IO inside a Next.js API route on Vercel, the serverless function accepts the WebSocket upgrade, processes the initial connection event, then gets terminated because it's treated as a request-response cycle. The client-side Socket.IO library retries the connection and a new serverless invocation handles it — but any rooms the client had joined, any in-memory state, and any connections to other clients are gone. At low traffic this produces mysterious message delivery failures; at higher traffic it triggers Vercel's rate limiting because each Socket.IO reconnection attempt looks like a new request.
The Correct Architecture
The solution is clean separation: a standalone Express + Socket.IO server running on a persistent host handles all WebSocket connections, while Next.js handles the frontend rendering and non-realtime API needs. The Next.js frontend connects to the Socket.IO server via its public URL.
You have three practical deployment options for the Socket.IO server:
Railway — the simplest option. Push a Node.js project, Railway detects it automatically, and provides a persistent container with a public URL. Free tier gives you $5 of compute credit per month (enough for low-traffic apps). Paid plans start at around ₹800/month for dedicated resources. Railway's automatic TLS means your WebSocket connections use wss:// without any manual certificate configuration.
Render — similar to Railway. Free tier runs a persistent web service that sleeps after 15 minutes of inactivity, which causes a cold start delay on first connection. The $7/month (approximately ₹580) paid tier keeps the service always-on. Better suited for production than the free tier for WebSocket applications because cold starts break the connection experience.
DigitalOcean Droplet — a ₹600/month basic Droplet (1 vCPU, 1 GB RAM) gives you a plain Linux server you fully control. Install Node.js, run your Socket.IO server with PM2 for process management, and use Nginx as a reverse proxy to handle the WebSocket upgrade and TLS. More setup work than Railway or Render, but no surprise cold starts and you own the infrastructure completely.
Building the Socket.IO Server
Here is a production-ready Express + Socket.IO server in TypeScript with JWT authentication in the handshake and basic rate limiting:
// server.ts
import express from 'express';
import { createServer } from 'http';
import { Server, Socket } from 'socket.io';
import jwt from 'jsonwebtoken';
import rateLimit from 'express-rate-limit';
const app = express();
const httpServer = createServer(app);
const io = new Server(httpServer, {
cors: {
origin: process.env.NEXT_PUBLIC_APP_URL, // e.g. https://yourapp.vercel.app
methods: ['GET', 'POST'],
credentials: true,
},
transports: ['websocket', 'polling'], // websocket first, polling as fallback
});
// Authenticate before connection is established
io.use((socket: Socket, next) => {
const token = socket.handshake.auth.token as string;
if (!token) {
return next(new Error('Authentication required'));
}
try {
const payload = jwt.verify(token, process.env.JWT_SECRET!) as { userId: string };
socket.data.userId = payload.userId;
next();
} catch {
next(new Error('Invalid token'));
}
});
// Track message rate per socket (simple in-memory approach)
const messageCounts = new Map<string, { count: number; resetAt: number }>();
function isRateLimited(socketId: string): boolean {
const now = Date.now();
const entry = messageCounts.get(socketId) ?? { count: 0, resetAt: now + 10_000 };
if (now > entry.resetAt) {
entry.count = 0;
entry.resetAt = now + 10_000;
}
entry.count++;
messageCounts.set(socketId, entry);
return entry.count > 20; // 20 messages per 10 seconds
}
io.on('connection', (socket: Socket) => {
const userId = socket.data.userId as string;
console.log(`User ${userId} connected — socket ${socket.id}`);
// Join a room specific to this user for targeted messages
socket.join(`user:${userId}`);
socket.on('join_room', (roomId: string) => {
socket.join(roomId);
socket.to(roomId).emit('user_joined', { userId, roomId });
});
socket.on('message', (payload: { roomId: string; content: string }) => {
if (isRateLimited(socket.id)) {
socket.emit('error', { code: 'RATE_LIMITED', message: 'Slow down' });
return;
}
io.to(payload.roomId).emit('message', {
from: userId,
content: payload.content,
timestamp: new Date().toISOString(),
});
});
socket.on('disconnect', (reason) => {
console.log(`User ${userId} disconnected — reason: ${reason}`);
messageCounts.delete(socket.id);
});
});
const PORT = process.env.PORT ?? 3001;
httpServer.listen(PORT, () => {
console.log(`Socket.IO server running on port ${PORT}`);
});Connecting from the Next.js Frontend
On the Next.js side, socket connections belong in a 'use client' component. Create a custom hook that manages the connection lifecycle — connecting on mount, cleaning up on unmount, and exposing connection state to the UI:
'use client';
import { useEffect, useRef, useState } from 'react';
import { io, Socket } from 'socket.io-client';
type ConnectionStatus = 'connecting' | 'connected' | 'disconnected';
interface UseSocketOptions {
token: string;
onMessage?: (payload: { from: string; content: string; timestamp: string }) => void;
}
export function useSocket({ token, onMessage }: UseSocketOptions) {
const socketRef = useRef<Socket | null>(null);
const [status, setStatus] = useState<ConnectionStatus>('connecting');
useEffect(() => {
const socket = io(process.env.NEXT_PUBLIC_SOCKET_URL!, {
auth: { token },
transports: ['websocket', 'polling'],
});
socketRef.current = socket;
socket.on('connect', () => setStatus('connected'));
socket.on('disconnect', () => setStatus('disconnected'));
socket.on('connect_error', () => setStatus('disconnected'));
if (onMessage) {
socket.on('message', onMessage);
}
return () => {
socket.disconnect();
socketRef.current = null;
};
}, [token]); // Re-connect if token changes (e.g., after login)
const joinRoom = (roomId: string) => socketRef.current?.emit('join_room', roomId);
const sendMessage = (roomId: string, content: string) =>
socketRef.current?.emit('message', { roomId, content });
return { status, joinRoom, sendMessage };
}The connection status drives UI feedback: show a "Connecting..." indicator during initial connection, a green dot when connected, and a "Reconnecting..." banner when the connection drops. Users in Kerala on mobile networks experience occasional drops — making reconnection state visible prevents them from thinking the app is broken.
Practical Use Case: A Kerala Restaurant Order Tracking System
Consider a Kochi restaurant chain where customers order via a web app, the kitchen sees orders appear in real-time, and delivery staff receive pickup notifications without anyone refreshing a page. Socket.IO rooms make this clean to implement.
When an order is placed, the system creates a room named order_[orderId]. Three parties join this room: the customer's browser tab (to watch status updates), the kitchen display screen (to receive the incoming order), and the delivery staff's phone browser (to receive the pickup notification when the order is ready).
// When order is placed — server-side (API route in Next.js)
// Emit to the Socket.IO server via HTTP to trigger the room event
await fetch(`${process.env.SOCKET_SERVER_URL}/internal/order-placed`, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'x-internal-secret': process.env.INTERNAL_SECRET!,
},
body: JSON.stringify({ orderId, orderDetails, kitchenId }),
});
// On the Socket.IO server — internal endpoint
app.post('/internal/order-placed', express.json(), (req, res) => {
const { orderId, orderDetails, kitchenId } = req.body;
const roomId = `order_${orderId}`;
// Notify kitchen display — kitchen has already joined `kitchen_${kitchenId}`
io.to(`kitchen_${kitchenId}`).emit('new_order', { orderId, orderDetails, roomId });
res.json({ ok: true });
});
// When kitchen marks order ready
socket.on('order_ready', ({ orderId }: { orderId: string }) => {
const roomId = `order_${orderId}`;
// Notify everyone in this order's room
io.to(roomId).emit('status_update', { orderId, status: 'ready_for_pickup' });
});The customer sees their order status change from "Preparing" to "Ready for pickup" without a page refresh. The delivery person's screen lights up with a pickup notification. The whole system works over a single persistent WebSocket connection per client, with no polling.
Scaling Beyond One Server
A single Node.js Socket.IO server can handle 10,000 to 50,000 concurrent connections depending on message frequency. For most Indian startups and SMEs, this is sufficient for years of growth. When you do need multiple server instances — either for high availability or for traffic beyond what one machine handles — you hit a new problem: a client connected to Server A cannot receive a message emitted by Server B.
The fix is the Socket.IO Redis adapter. Every emit goes through Redis pub/sub, which distributes it to all server instances. Add it to your server with two lines:
import { createAdapter } from '@socket.io/redis-adapter';
import { createClient } from 'redis';
const pubClient = createClient({ url: process.env.REDIS_URL });
const subClient = pubClient.duplicate();
await Promise.all([pubClient.connect(), subClient.connect()]);
io.adapter(createAdapter(pubClient, subClient));You also need sticky sessions — requests from the same client must route to the same server instance during the Socket.IO handshake polling phase. Both Railway and Render support sticky sessions. On a self-managed Nginx setup, add ip_hash to your upstream configuration.
Be honest with yourself about whether you need this. If your app has 500 concurrent users with moderate message frequency, one ₹1,200/month Droplet handles it without Redis or load balancing. Add complexity when metrics show you need it, not before.
Alternatives to Socket.IO in 2026
Socket.IO isn't the only option, and for many use cases it's not the simplest one.
Pusher / Ably — managed WebSocket platforms that handle all the infrastructure. Pusher's free tier covers 200 concurrent connections and 200,000 messages per day, sufficient for a small production app. Their paid plans run from ₹0 to ₹8,000/month depending on connection and message volume. You trade control for operational simplicity — no server to manage, no Redis to configure, no autoscaling to think about.
Supabase Realtime — if you're already using Supabase as your database, Realtime lets you subscribe to database changes directly from the browser via WebSockets. Inserts, updates, and deletes in your Postgres tables can trigger client-side events. This is elegant for apps where the real-time data is the database state itself — like a collaborative task board or a live inventory display. You write database records from your Next.js API route and the browser updates automatically.
Server-Sent Events — for one-directional data flows, SSE is simpler than WebSockets and works natively with Next.js API routes. The server keeps a response stream open and pushes events when they occur. Browsers auto-reconnect on disconnect. For use cases like live sports scores, stock price feeds, or notification systems where the browser only receives data, SSE eliminates the need for a separate server process entirely.
Frequently Asked Questions
Can I use Socket.IO with Next.js deployed on Vercel?
Not reliably. Vercel runs Next.js API routes as serverless functions — each invocation spins up in an isolated execution context, handles one request, and shuts down. A WebSocket connection requires a persistent, stateful process that stays alive between messages. When the serverless function completes its execution cycle, the TCP connection it was managing gets torn down. The correct solution is a separate Express + Socket.IO server deployed on Railway, Render, or a VPS — not an API route inside your Next.js project.
How many concurrent WebSocket connections can a ₹600/month DigitalOcean Droplet handle?
A ₹600/month Droplet (1 vCPU, 1 GB RAM) running a Node.js Socket.IO server can comfortably handle 10,000 to 15,000 concurrent WebSocket connections when messages are infrequent — for example, order status updates every few seconds. If connections are sending or receiving messages continuously, the practical limit drops to around 3,000 to 5,000 concurrent connections before CPU becomes a bottleneck. A 2 vCPU, 2 GB RAM Droplet at roughly ₹1,200/month extends this to 25,000 to 50,000 concurrent connections for moderate-frequency messaging. Monitor Node.js heap usage and event loop lag rather than just connection count.
Should I use WebSockets or Server-Sent Events for a live sports score feed?
Server-Sent Events are the better choice for a live sports score feed. SSE is a one-directional protocol — the server pushes events to the client over a regular HTTP connection, and the client only receives. For scores, the browser never needs to send data back to the server, making the bidirectional overhead of WebSockets unnecessary. SSE reconnects automatically when the connection drops, works through standard HTTP/2 multiplexing, and can be served from a regular Next.js API route — no separate server required. WebSockets are worth the added complexity only when the client also needs to send data, such as in live chat, collaborative editing, or multiplayer games.