Soketi vs Centrifugo vs Pusher vs Ably: the realtime reality check for Next.js (2026)

Quick answer (2026)

If you want a self-hosted realtime server that is genuinely maintained, pick Centrifugo: it is Apache-2.0, written in Go, and shipped v6.9.2 on August 18, 2026. If you want the cheapest managed on-ramp with a free tier you can actually launch on, pick Ably (6M messages a month at $0) or Pusher Channels if you value a simpler mental model over headroom. And Soketi, the Pusher-protocol drop-in that half the internet still recommends, has not shipped a release since March 25, 2024. That is the finding that reorders this whole comparison, and almost nothing on the first page of Google mentions it.

There is a second thing the search results have not caught up with. Vercel Functions now serve WebSocket connections natively, and Next.js has an escape hatch for it. That changes the "you cannot do realtime on Vercel" advice you will find in almost every older thread, but it comes with two constraints that decide whether you still need one of these four products at all.

We run the ShipGarden gallery by self-hosting the building blocks we recommend, so this is a hands-on read rather than a feature-table paraphrase. Every version, star count, download figure and price below was read from the source on August 19, 2026.

What we are actually comparing

Four products, two shapes.

Self-hosted servers are a binary you run. You pay for a VM and your own time. Two candidates:

• Soketi is a Node.js WebSocket server that implements the Pusher protocol. That is its whole pitch: point the official Pusher client SDKs at your own box and stop paying Pusher. It is AGPL-3.0 licensed.
• Centrifugo is a Go server with its own protocol and SDKs. It is not a drop-in for anything; it is a dedicated realtime transport layer you put beside your app. Apache-2.0 licensed.

Managed services are an API key. You pay per message and per connection. Two candidates:

• Pusher Channels is the incumbent, sold on simplicity: channels, events, done.
• Ably is the one sold on guarantees: message ordering, delivery guarantees, global edge routing.

The reason a Next.js team ends up on this page is nearly always the same. You built a feature that needs a push from server to browser (live cursors, a chat panel, a job-progress bar, streaming tokens) and discovered your framework does not hand you a WebSocket server. So the real question is not "which of these four is best" but "which of these four do I need, given where my app runs."

The honest comparison table

Star counts, release dates, issue counts and licenses read from each project's GitHub repository on August 19, 2026. Prices read from each vendor's own pricing page in August 2026. Numbers move; re-check before you commit a budget.

Soketi: the recommendation that aged out

Soketi is a good idea. Implementing the Pusher protocol means every Pusher client SDK, every framework integration, and every tutorial written for Pusher works against a server you run yourself. Its own description is exactly that: a "next-gen, Pusher-compatible, open-source WebSockets server." For a team already paying Pusher and watching the bill scale with connection count, swapping the host and keeping the client is a genuinely elegant migration.

The problem is that the project has stopped. Reading the Soketi repository on August 19, 2026: the latest tagged release is v1.6.1, published March 25, 2024. The most recent commit on the default branch is dated the same day, and GitHub records the last push to the repository as March 3, 2025. There are 140 open issues. It is not archived, and nobody has declared it dead, which is precisely why it keeps getting recommended. But every other repository in the Soketi organisation is quieter still, with most last touched in 2023 or 2024.

Meanwhile people are still installing it: the @soketi/soketi npm package recorded 3,097 downloads in the week ending August 17, 2026. That gap between "still adopted" and "not maintained in over two years" is the actual risk here, and it is worth naming plainly. A WebSocket server sits on the public internet holding long-lived connections. It is not a build-time dependency you can pin and forget.

The licence deserves a mention too. Soketi is AGPL-3.0, not MIT. For most teams running it as a standalone server beside their app this is fine, but if your legal position is that you cannot ship AGPL code, it is a conversation to have before the proof of concept, not after.

Pick Soketi if: you have an existing Pusher-SDK codebase, you want to self-host it this quarter with minimal client changes, and you are willing to own the server yourself, including patching it. Do not pick it because a 2024 blog post said it was the modern option.

Centrifugo: the one that is actually being worked on

Centrifugo is the opposite profile. The Centrifugo repository shows v6.9.2 released on August 18, 2026, one day before we read it, following v6.9.1 on July 13, 2026 and v6.9.0 on July 7, 2026. That is a real, boring, monthly release cadence. It carries 10,637 stars against 24 open issues, which is a healthier ratio than Soketi's 5,633 against 140.

Architecturally it is a standalone Go server that sits beside your backend rather than inside it. Your app publishes to Centrifugo over an API; Centrifugo owns the connections and fans messages out. Its own documentation describes a channel-subscription pub/sub model that lets you "decouple the business logic from the real-time transport layer," and it scales by running multiple nodes behind a broker: Redis, Redis Cluster or NATS. Redis is the path most people take.

It also carries the widest transport list of the four: WebSocket, HTTP-streaming, Server-Sent Events, WebTransport and gRPC. That matters more than it sounds. If a corporate proxy eats your WebSocket upgrade, SSE is a fallback you already have rather than a second integration.

The honest caveats are two. First, it is not Pusher-compatible, so you adopt Centrifugo's own client SDK and its own concepts (channels, tokens, presence) rather than reusing anything. Second, it is genuinely more operational surface than a managed key: a Go binary, a config file, JWT-based connection auth, and Redis once you go multi-node. Its JavaScript client, published to npm as centrifuge, is at v5.7.1 as of August 14, 2026 and is MIT licensed even though the server is Apache-2.0, which is the friendlier arrangement for your frontend bundle.

Pick Centrifugo if: you want to self-host, you expect this to still be running in three years, and you would rather learn one well-maintained system than inherit an unmaintained one.

Pusher Channels and Ably: what you are actually buying

The managed pair are easy to describe and easy to price badly, because they meter different things.

Pusher Channels prices on two axes only: peak concurrent connections and daily messages. The Sandbox tier is free at 100 connections and 200,000 daily messages, then Startup is $49 a month for 500 connections and 1 million daily messages, Pro is $99 for 2,000 connections and 4 million, and Business is $299 for 5,000 connections and 10 million (Pusher Channels pricing, August 2026). The ladder continues to $1,199 for 30,000 connections. The virtue is that you can predict the bill on the back of an envelope. The vice is the same thing: those are hard ceilings, and the jump from 500 to 2,000 connections doubles the price whether or not your message volume moved.

Ably prices on a base plus usage. The free tier is materially more generous for a launch: $0 for 6 million messages a month, 200 concurrent channels and 200 concurrent connections. Standard is $29 a month plus usage and lifts you to 10,000 concurrent channels and 10,000 concurrent connections; Pro is $399 a month plus usage at 50,000 of each. Usage is billed at $2.50 per million messages, $1.00 per million connection minutes and $1.00 per million channel minutes (Ably pricing, August 2026).

The comparison people get wrong: Ably's headline entry price ($29) is lower than Pusher's ($49) and its connection ceiling is twenty times higher, but the "plus usage" is not decoration. Connection minutes are the line that surprises teams, because an idle open tab bills the same as a busy one. If your product keeps a dashboard open all day for every user, model connection minutes before you model messages. If your product sends bursts to briefly-connected clients, Pusher's flat ceiling is often cheaper and always simpler.

The Next.js part, which changed in 2026

Here is the piece almost every current search result gets wrong, and it is the reason we wrote this comparison rather than a fifth "top realtime tools" list.

The received wisdom is that Vercel cannot hold WebSocket connections, so a Next.js app on Vercel must offload realtime to a managed service or a separate always-on box. That was true for years. It is no longer accurate. Vercel's own documentation, last updated July 24, 2026, states plainly that "Vercel Functions can serve WebSocket connections, keeping a bidirectional connection open between a client and your server-side code" (Vercel WebSockets documentation, 2026).

Three constraints decide whether that helps you.

1. Next.js needs an escape hatch. Vercel's docs say directly that "Next.js does not expose an API for handling WebSocket upgrades." The workaround is experimental_upgradeWebSocket() from the @vercel/functions package, used inside a route handler. Note the word experimental_ in the export name. Nitro, Hono, Express and Bun get first-class treatment; the App Router gets a flagged API. If you are picking infrastructure for something you intend to leave alone for two years, weigh that.

2. Connections die on a timer. Vercel's docs state that WebSocket connections close when the function reaches its maximum duration. On Hobby that maximum is 300 seconds. On Pro and Enterprise the default is also 300 seconds, extendable to 800 seconds, with a 1800-second extended maximum in beta. So on a Hobby project every connection is torn down at least every five minutes by design, and your client must reconnect, resubscribe and reload state each time. Vercel's own guidance says exactly that. This is workable for a chat panel. It is a poor fit for a long-running collaborative session where reconnect churn is visible to the user.

3. State cannot live in memory. New connections are not guaranteed to reach the same function instance, and after a deploy new connections land on the new deployment while old ones drain. Presence, rooms, counters and pub/sub fan-out all have to live in an external store, with Redis being the usual answer. Which means that if you go this route, you have adopted a Redis dependency anyway, and the gap between "native Vercel WebSockets" and "run Centrifugo with Redis" is smaller than it first looks.

Also worth knowing: WebSockets on Vercel require Fluid compute, which is the default only for projects created on or after April 23, 2025. An older project needs to turn it on.

So which one

The decision collapses to three questions.

Does your realtime feature tolerate a forced reconnect every few minutes? If yes, and you are already on Vercel, try the native path first. You will avoid a vendor entirely. Build the reconnect logic properly on day one rather than day ninety, and put shared state in Redis from the start.

If no, do you want to run a server? If you do not, pick a managed service, and pick on billing shape rather than features: Ably if you want the bigger free tier and a higher connection ceiling and you have modelled connection minutes, Pusher if you want a bill you can predict without a spreadsheet.

If you do want to run a server, pick Centrifugo. Not because Soketi's design is worse (the Pusher-compatibility trick is genuinely clever) but because one of these two projects shipped a release yesterday and the other last shipped one in March 2024. On a component that terminates public connections, maintenance is a feature, and it is the feature that matters most.

One boundary worth drawing, because we see it conflated constantly: none of these four are a job queue. If what you actually need is "run this work reliably in the background and tell the user when it finishes," the realtime transport is the last ten percent of that problem. The durable-execution question comes first, and we covered that separately in our Node.js workflow engine and job queue comparison. Likewise, if the push you need is an email, an in-app inbox or a mobile notification rather than a live socket, that is notification infrastructure, which is a different category with different economics.