Centrifugo is an open-source, language-agnostic real-time messaging server that delivers messages to online users over WebSocket, HTTP-streaming, Server-Sent Events, GRPC, and WebTransport, and it is built for teams that want user-facing PUB/SUB without writing and operating the transport layer themselves.

What it is

Centrifugo is a scalable real-time messaging server written in Go and licensed under Apache-2.0. It is a PUB/SUB server built on top of modern real-time transports, with the concept of channel subscriptions at its core, which makes it a user-facing PUB/SUB server rather than a raw message broker. A backend application communicates with Centrifugo over a simple HTTP or GRPC server API to publish messages into channels, while clients subscribe to those channels using one of the official SDKs or through a unidirectional approach that carries no SDK dependency. The project is language-agnostic by design, so it can sit beside any backend stack, and it deliberately decouples business logic from the real-time transport layer. In this registry it is filed under Infrastructure & Operations / Databases.

The concrete problem it solves is that making PUB/SUB production-ready is the hard part: it has to be efficient, flexible, and reachable from many different application environments. Instead of wiring custom WebSocket handling, subscription tracking, reconnection recovery, and permission checks into every product, a team runs Centrifugo once and lets its backend publish into channels. It replaces that self-built plumbing, and it is positioned as a self-hosted alternative to Pubnub, Pusher, Ably, socket.io, Phoenix.PubSub, and SignalR, so real-time features such as chat, live comments, multiplayer games, real-time data visualizations, collaborative tools, and AI streaming responses can be added without owning the transport machinery.

Key capabilities

• Efficient real-time transports: WebSocket, HTTP-streaming, Server-Sent Events (EventSource), GRPC, and WebTransport, which is marked experimental.
• Built-in scalability with Redis, Redis Cluster, or Redis-compatible storage such as AWS ElastiCache, Valkey, KeyDB, and DragonflyDB, plus PostgreSQL or Nats.
• Simple HTTP and GRPC server API so the application backend can publish into channels from any language.
• Asynchronous PostgreSQL and Kafka consumers that support transactional outbox and CDC patterns.
• Flexible connection authentication through JWT or proxy-like authentication, where Centrifugo issues a request to the backend.
• Rich subscription model covering stream (client-side and server-side), map, shared poll, and proxy subscription streams, with channel subscription multiplexing over a single connection.
• Hot message history in channels with automatic message recovery on reconnect and cache recovery mode, which delivers the latest publication immediately upon subscription.
• Delta compression in channels based on the Fossil algorithm, online channel presence with join and leave information, channel namespaces, and various channel permission strategies.

Who uses it and how

• Product teams adding chat, live comments, or collaborative editing to an existing application, where the backend keeps business logic and Centrifugo handles fan-out to connected clients.
• Game and simulation developers pushing real-time state to many concurrent connections, using Redis or Nats behind multiple Centrifugo nodes.
• Backends that need transactional outbox or CDC delivery, using the asynchronous PostgreSQL and Kafka consumers rather than publishing directly.
• Teams standardizing on one real-time server across several services and languages, since the HTTP and GRPC API and the official SDKs are language-agnostic.
• Operators who want to watch live connections and publish into channels during development through the embedded admin UI.

Getting started

The README quick start runs the centrifugo/centrifugo:latest Docker image, for example docker run -it --rm -p 8000:8000 centrifugo/centrifugo:latest centrifugo --client.insecure --admin.enabled --admin.insecure, then opens http://localhost:8000 for the admin UI. The insecure flags exist only for a frictionless local trial and must never be used in production; native binaries, Homebrew, and packages are covered in the installation instructions, followed by the quickstart tutorial for connecting a first client.

How it compares

Centrifugo is described as a self-hosted alternative to Pubnub, Pusher, and Ably, so the difference is licence and control rather than feature parity: those are hosted services, while Centrifugo is Apache-2.0 software that a team runs on its own infrastructure, which keeps message data inside that infrastructure and turns the cost model into self-operated infrastructure rather than a hosted subscription. Against socket.io, Phoenix.PubSub, and SignalR it is not a library bound to one runtime or framework but a standalone server with an HTTP and GRPC API, multiple transports, and Redis, PostgreSQL, or Nats based scaling.

When to use it — and when not to

A self-hoster must operate Centrifugo itself along with the scaling and history layer it is pointed at, which means Redis, Redis Cluster, or Redis-compatible storage, or PostgreSQL or Nats, and production connection authentication requires JWT or a proxy-like request to the backend. The quick start flags shown above disable authentication and are explicitly for local trial only, so anyone unwilling to configure real authentication and a shared broker should not pick it for production. The README excerpt available in this registry entry is truncated mid-sentence, and WebTransport is still experimental, so the installation and quickstart documentation at centrifugal.dev remains the authoritative source.

docker run -it --rm -p 8000:8000 centrifugo/centrifugo:latest centrifugo \
  --client.insecure --admin.enabled --admin.insecure
# ^ insecure flags: for local trial only, never use in production