All posts
AWS Architecture

WebSockets on Vercel Functions Are Generally Available: The Limits, the Bill, and What You Still Build

By

November 2, 2026

6 min read

Since October 20, 2026, Vercel Functions serve WebSocket connections on every plan, with Express, Hono, Socket.IO, Bun, FastAPI and Next.js. Connections close at the function's maximum duration (300 seconds on Hobby, up to 800 on Pro), each is pinned to one instance, and memory is billed while any connection is open. What that means for your design and your bill.

WebSockets
Vercel
Realtime
Serverless

Vercel announced general availability of WebSockets in Vercel Functions on October 20, 2026, after a public beta that began in June. It says it has carried 300 million connections since the beta and handles about 15 million a day. For teams already on Vercel, it removes the usual reason to stand up a separate realtime service. It doesn't remove the work that makes realtime hard.

How it works

  • A connection starts as an ordinary HTTP GET with an Upgrade header, so routing middleware, rewrites, Firewall rules and rate limits apply to it like any request. Rate limits count upgrade requests, not messages.

  • Each connection is pinned to the one function instance that accepted it. With Fluid compute, which WebSockets require, one instance holds many connections.

  • Standard libraries work: ws, Socket.IO (WebSocket transport only), Express, Hono, h3, Nitro and Nuxt, Bun.serve, and FastAPI, Django Channels or Flask-Sock in Python.

  • Next.js has no API for upgrades, so Vercel provides upgradeWebSocket() in @vercel/functions 3.10.0 and later for route handlers.

The limits that shape your design

Limit

Value

What it means

Connection lifetime

The function's max duration: 300 seconds on Hobby; 300 by default and up to 800 on Pro and Enterprise; 1,800 in beta for some runtimes

Every client reconnects at least every 5 to 30 minutes. Reconnect logic is required, not optional.

Instance affinity

A connection stays on one instance; a reconnect may land on another, or on a newer deployment

Rooms, presence, counters and history have to live outside the function, in Redis or a database

Fan-out

Bun's publish and subscribe reach only sockets on the same instance

Broadcasting to everyone in a room needs a shared channel such as Redis pub/sub

Deploys

Existing connections stay on the old deployment until they close

Two versions of your message handling run side by side for up to the max duration

File descriptors

1,024 per instance, shared with the runtime

Vercel doesn't say how proxied connections count against this. Load-test before planning on thousands per instance.

From Vercel's WebSockets and Functions limits documentation, November 2026.

Is this the right place for your realtime feature?

A short call on what you're building usually settles whether it belongs on Vercel, on AWS, with a managed service, or doesn't need a live connection at all.

What it costs

WebSockets use the normal Fluid compute pricing: Active CPU only while code is processing a message, provisioned memory for as long as an instance has work in flight, an invocation per connection, and data transfer. An open connection counts as work in flight, so an instance holding even one idle socket keeps billing memory. In Washington, D.C. (iad1), memory is $0.0106 per GB-hour and Active CPU $0.128 per hour; invocations are $0.60 per million on Pro.

1,000 users, connected 8 hours a workday (22 days), 2,200 messages each a day

Monthly

Reconnect invocations at 800-second lifetime (792,000)

About $0.48

Active CPU at 1 ms per message (48.4 million messages)

About $1.72

Memory: each 2 GB instance holding connections for those 176 hours

About $3.73 per instance

If the connections spread over 5 instances

About $19 for memory

If they spread over 50

About $187 for memory

Plus

Fast Data Transfer, and Redis for shared state and fan-out

Our arithmetic from Vercel's published iad1 rates. Vercel doesn't publish how many connections share an instance, which makes memory the line to measure.

What you still build

  1. Client reconnects with backoff, resubscription, and catch-up of anything missed while disconnected.

  2. A durable store for messages and state, so a reconnect to a different instance or deployment loses nothing.

  3. Authorization checked on upgrade and again for actions that matter, since a connection can outlive a revoked session.

  4. Message handling that tolerates two deployments running at once.

  5. Dashboards for open connections, reconnect rate and message rate, and a load test of a reconnect storm after a deploy.

Planning a launch on this?

We'll go through your design and expected traffic with you and tell you where it will hurt first. Thirty minutes, free.

hoolco Monthly Review

Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.

As of November 2, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.