Centrifugo delivers live application updates to connected users, such as a new chat message or a change shown on a dashboard. It keeps connections open to browsers or mobile applications, while your backend publishes events through its API. This is useful when you want real-time delivery without building connection management into every application backend. You still decide which users may subscribe to each channel and what happens when a client reconnects.
Deployment and operating notes
Centrifugo’s current installation documentation links its official Kubernetes Helm chart and describes the server’s generated configuration. The old stable chart is no longer the right source for deployment defaults. Current configuration separates client authentication, allowed origins, HTTP API access and administration, so historical HMAC or channel examples should be mapped to the selected server release.
Inventory client SDK versions, transports, token claims, channel permissions and the chosen engine before a server upgrade. If Redis is used for history or cross-node messaging, preserve its availability and persistence assumptions; adding Centrifugo replicas alone does not define message recovery. Test connect, publish, disconnect and reconnect with real clients, including expired tokens and denied channel access. Check reverse-proxy timeouts and WebSocket behavior along the actual ingress path. Roll out a small set of clients first where protocol compatibility permits, and retain the previous server image and configuration. Do not infer message durability or delivery guarantees from the old performance-oriented description.
Historical upstream link check · 2026-10-09
The recorded upstream address responded successfully (HTTP 200) on 2026-10-09. GitHub confirms that helm/charts is archived: this is a historical chart distribution, not evidence that the application itself is retired. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
Centrifugo is a real-time messaging server. It’s language-agnostic and can be used in conjunction with application backend written in any language – Python, Ruby, Perl, PHP, Javascript, Java, Objective-C etc.
Centrifugo runs as separate service and keeps persistent Websocket or SockJS connections from your application clients (from web browsers or other environments like iOS or Android apps). When some event happens you can broadcast it to all interested clients using Centrifugo API.
Highlights
- Fast server capable to serve thousands of simultaneous connections
- Easily integrates with existing application – no need to rewrite your backend code to introduce real-time events
- HTTP API to communicate from your application backend (publish messages in channels etc.). API clients for Python, Ruby, PHP, Go, NodeJS. Simple to implement new one
- Javascript client to connect from web browser over SockJS or pure Websocket protocol. Clients for iOS and Android on top of Websocket
- Scale to several machines with Redis, Redis Sentinel for high availability, consistent hash sharding.
- SHA-256 HMAC-based connection authentication and private channel authorization
- Different types of channels – private, user limited, client limited channels
- Flexible configuration of channels via namespaces
- Presence information for channels (show all active clients in channel)
- History information for channels (last messages sent into channels)
- Join/leave events for channels (client goes online/offline)
- Recover missed messages after network disconnect
- Built-in administrative web interface
- Possibility to use as WebRTC signaling server
- Ready to deploy (docker image, RPM/DEB packages, Nginx configuration, automatic Let’s Encrypt TLS certificates)
- MIT license.
Features in short
There are lots of projects for solving real-time problem. Most of them only provide PUB/SUB feature, i.e. a way to deliver messages to clients. Centrifugo have more to offer out of the box to build real-time apps. Here is a very short description of main features Centrifugo has.
Presence information. This is an information about current connections to specific channel. The most obvious example is chat room – we want to see to is online at moment.
Next are join/leave events. In the chat room example, these are notifications when someone joins or leaves the room.
Another thing is that Centrifugo allows to keep message history (cache) for channels during configurable amount of time and with configurable size. This is not very useful alone but allows to recover missed messages (during short network disconnections for example).
Another common problem is client load balancing. What if our application has 100k clients online? Of course in theory we can use only one machine to handle all connections (and even more). But this is bad because of two main reasons:
service availability. What if your Centrifugo machine breaks?
more clients mean more CPU resources and higher message latencies. Why not to relax your instance adding another one?
So to scale on several machines and load balance clients between them Centrifugo can be started with Redis engine. Centrifugo nodes will be connected over Redis PUB/SUB mechanism and all temporary information such as presence and message history information will be kept in Redis instead of process memory. Centrifugo works with Redis Sentinel to prevent Redis being single point of failure.
Sources & further reading
Spotted something that needs another look?
Help improve this page →