Centrifugo vs managed platform

• Running Centrifugo commits your team to operating a cluster of servers and the broker behind them: scaling, patching, and staffing on-call for it. Outages, roadmap delays, and re-architecture come on top, and none of them show up on an invoice.

• Centrifugo PRO adds features such as push notifications, analytics, tracing, and SSO, but your team still runs the infrastructure underneath.

• A managed platform replaces the servers, the work of running them, and the guesswork about reliability with one subscription backed by stated guarantees.

• Self-hosting holds up if you already run realtime infrastructure and on-call, have strict data residency requirements, or operate at small scale. Otherwise, operational strain, not the bill, is usually the first sign it's time to move.

• Moving from a managed platform to Centrifugo can lower your bill, but it swaps a subscription for infrastructure, engineering time, and risk your team owns indefinitely. Consider all three before counting it as a saving.

If you've chosen, or are considering choosing, to run Centrifugo in production, it's worth recapping what that involves.

On the build side, you need a distributed broker (commonly Redis or NATS) and a cluster of Centrifugo nodes in front of it for horizontal scale and failover. Centrifugo's own Helm chart documentation confirms this directly, recommending three replicas in its own high-availability reference configuration.

That can seem simple enough, but owning all of that means managing every layer underneath it indefinitely, from the broker and cluster nodes to the OS and network they run on. This maintenance overhead is easy to underestimate, but here's what you're really taking on:

• Capacity planning and scaling, so the cluster keeps up with steady growth, event-driven surges, and mass client reconnections.

• Failover testing, so the cluster behaves as expected when a node goes down.

• Regional redundancy, so a single-region incident, such as an AWS us-east-1 outage, doesn't take your entire realtime layer down. This is separate from node-level failover, and most self-hosted setups don't start with it.

• Security patching and dependency upgrades, so that known vulnerabilities are closed quickly. Centrifugo has shipped 18 releases and published 11 security advisories (two rated critical) in 2026 so far, each needing your team's review and rollout, plus four major versions with breaking changes since 2021.

• Monitoring and alerting, so problems in the cluster, the broker, or client connections surface before your users notice.

• Backup and disaster recovery, so anything you persist can be restored.

• Incident response, so someone owns the realtime layer when it fails, on top of the rest of your stack.

Although Centrifugo provides more out of the box than raw WebSockets, it doesn't offer any guarantees around message delivery or exactly-once delivery, and its ordering guarantee applies within a channel, not across channels.

In practice, that means building idempotency handling into your application for at-least-once delivery, writing your own ordering logic for anything that spans multiple channels, and adding reconciliation logic to catch messages sent while a client was disconnected. That's real engineering work, not a config flag, and it's on your team to build it or accept the gap.

Beyond that, the following aren't part of the open source version:

• Realtime analytics (via ClickHouse)

• User and channel tracing

• Operation rate limiting

• SSO for the admin UI

• Several scalability and bandwidth optimizations

If they matter to you, that means building your own equivalent services or paying for Centrifugo PRO. PRO isn't priced publicly, but the rest of the self-hosting bill - infrastructure and engineering time - is covered next.

Most of the cost of self-hosting Centrifugo isn't servers. It's the team that runs them: operations, patching, and a 24/7 on-call rotation that doesn't shrink after launch. Google's SRE guidance sizes a sustainable rotation at eight engineers minimum.

If you're on a managed platform and considering Centrifugo, set that all-in figure against your subscription, not against the free license. If you already self-host, swap in your own infrastructure bill and your team's actual rates: broker, compute, staging, monitoring, data transfer, and DDoS protection, plus the engineering hours to operate and patch the system and the cost of your on-call rotation.

MobyMax, which serves live learning tools to more than 28 million students, ran this calculation when it considered building its own realtime infrastructure on AWS:

The "cost" of self-hosting isn't just the infrastructure and engineering bill above. It also carries five risks that don't show up in that number, and they land on your team regardless of how you got here.

Centrifugo carries no SLA at either tier, and PRO adds prioritized support, not a stated remedy if something slips. Ably's 2022 survey of 500+ engineering leaders found 65% of teams building their own realtime infrastructure had an outage or significant downtime in the previous 12 to 18 months. Almost half (46%) named keeping service running through local or regional failures as their main challenge.

The window to recover is tight: at 99.99% uptime, you have about 13 minutes a quarter to detect, diagnose, and fix every incident. ITIC's 2024 survey found over 90% of mid-size and large enterprises put the cost of a single hour of downtime above $300,000. Our dedicated Centrifugo reliability page walks through exactly what Centrifugo does and doesn't guarantee.

Today's infrastructure is sized for today's scale. When a single broker becomes the bottleneck, the next step is architectural: moving to Redis Cluster, splitting namespaces across brokers (a PRO feature), or switching broker engine. Each one is a migration done under live traffic, and it tends to arrive when the system is under the most load.

Every audit or customer security questionnaire has to cover the infrastructure you built. You have to document and prove that it meets the required standards yourself, rather than pointing to a vendor's existing certification.

Distributed realtime systems (brokers, failover, backpressure) are a specialized skill set that takes longer to hire for than a generic backend role. When that knowledge lives with one or two people, their departure can turn routine maintenance into a rebuild.

On-call adds to the load. In Ably's survey, over 40% of respondents weren't paid for on-call, so the cost shows up in salaries, retention, and burnout instead. Folding the realtime layer into an existing rotation doesn't remove that load; it adds to the pager for people who already carry one.

Operational work draws from the same engineering time as the product, and that drain grows with scale. In Ably's 2022 survey of engineering leaders, 93% of self-built realtime projects needed four or more engineers, 53% took longer to build than planned, and half needed $100,000 to $200,000 a year in upkeep. More than half cited redeploying engineers from infrastructure to core product work as a top reason for switching to a managed platform.

HubSpot, which runs live chat for 268,000+ companies on Ably, considered self-hosting. But despite already dedicating a sizeable share of its engineering team to infrastructure, it couldn't make the case work:

Moving to Ably instead delivered a 60% upfront CAPEX saving and a further $300,000 a year in reduced infrastructure and engineering costs, compared with the self-built alternative HubSpot had been considering (full case study).

A managed platform removes the server, the cluster, and the operational burden of running them. In their place, you get a subscription backed by explicit service guarantees, instead of guarantees your team has to build and prove itself. That's worth factoring in before writing the subscription off as pure overhead.

Ably is one such managed platform. Its infrastructure runs across multiple regions, with no single point of congestion. It's built around four pillars of dependability - each one addressing a way in which self-hosted realtime infrastructure tends to fail in practice:

• Performance: a 6.5ms median message delivery latency, the round trip for a message to be published and received at the edge of Ably's network within a single region. This is engineered into the protocol and routing layer rather than left to whatever the infrastructure happens to deliver.

• Integrity: a 100% message delivery guarantee, backed by multi-region redundancy, so ordering and exactly-once delivery are the platform's job, not logic your application has to reconstruct.

• Reliability: 99.999999% message survivability, a 99.999% uptime commitment (a contractual SLA on Business and Enterprise plans), and 100% actual uptime over the past seven years. All of this comes from treating fault tolerance as a design decision rather than an outcome of on-call discipline.

• Availability: infrastructure across two to ten regions per cluster, scaling horizontally with demand rather than forcing a re-architecture at some growth threshold.

You can read more on how Ably's architecture is built around these four pillars on Ably's platform page.

Put side by side, the difference between what you'd own self-hosting with Centrifugo and what Ably owns instead looks like this:

That comes at the cost of the control self-hosting gives you. You're adopting Ably's model for each of these four pillars, rather than tuning your own. It also means a different kind of dependency. Instead of building around Centrifugo-specific behavior, your application builds around Ably's APIs and channel semantics. But in return, capacity, failover, patching, and on-call for all of that infrastructure become Ably's responsibility, not yours.

This means your engineers can prioritise building product features, not fixes, and they don't have to work around infrastructure issues. As Fin (previously Intercom) found:

If you're on Centrifugo and already considering a move to a managed platform, chances are you've faced outages, patched around delivery gaps yourself, or felt the on-call rotation start to wear thin. If it feels like you've outgrown your current setup, you probably have. But here are six clear signs that it's time to make the move:

1. An outage already cost more than a subscription would have. Add the engineering hours spent firefighting to the business cost of the downtime, and compare that to a managed platform's SLA-backed uptime for the same period.

2. On-call for the realtime layer is burning people out. Repeated after-hours pages, engineers trying to swap out of the rotation, or a key person leaving with undocumented cluster knowledge all mean the setup depends on specific people, not a repeatable process.

3. You're evaluating, or using, Centrifugo PRO just to close feature gaps. Price PRO plus your existing infrastructure and engineering time against a managed platform subscription, rather than stacking a second license on what you already operate.

4. You can see a re-architecture coming. Sharding the broker, adding a region, or rebuilding for unanticipated traffic is expensive, done reactively, and cheaper to avoid by moving first.

5. An audit or security questionnaire is asking for guarantees you don't have. When the infrastructure carries no SLA, you have to write and prove those commitments yourself, case by case, rather than pointing the auditor to a vendor's existing certification.

6. Your roadmap keeps slipping due to infrastructure firefighting. It's the slow-burn version of the other signals: invisible sprint to sprint, but it compounds.

Genius Sports hit this point running its own on-premises RabbitMQ clusters to deliver live sports data, watching hardware costs climb while its infrastructure team constantly firefought outages.

That's not to say Centrifugo is never a fit. Self-hosting on Centrifugo holds up well, and can be a genuine saving, in a few specific cases:

• Infrastructure and on-call for realtime systems already exist in-house, so running one more service is a marginal cost, not a new one

• Data residency or network isolation requirements rule out a third-party platform entirely

• Message volume and connection counts are small enough that operational overhead stays low

• Your team has deep, specific expertise running Go services and the brokers Centrifugo depends on

But if none of these describe your team, remember that staying with or moving onto Centrifugo isn't "free". You're taking on the costs and risks covered above in exchange for a lower subscription line. If you're already self-hosting and living with outages or on-call burnout, the case for moving to a managed platform should already have been made. The next section covers what that move actually involves.

Moving to a managed platform isn't a rip-and-replace, and it doesn't have to happen in one move. The concepts carry over: presence, channel history, authentication, and connection handling all still exist on a managed platform. It's the mechanics underneath each one that change, and that's where the real migration work sits.

In practice, most teams work through it channel by channel or workload by workload. Both systems typically run in parallel long enough to validate that presence, auth, and reconnection behave the way the application expects, before traffic moves across for good. How much work that takes depends on how tightly the application is coupled to Centrifugo-specific behavior, rather than to general pub/sub concepts that would carry across to another provider.

Ably runs the infrastructure, the clustering, and the on-call. Your team gets to spend that time on the product instead of keeping a realtime cluster alive. When you're ready to talk specifics, our team can walk through your setup directly.

Start free or talk to us about migrating from Centrifugo.

Partly. PRO adds features such as push notifications, analytics, tracing, and SSO, plus observability tools, performance optimizations for reconnect-heavy traffic, and prioritized support, which can make operating easier. But you still run the broker and nodes, and on-call, capacity planning, and upgrades stay with your team. That's where most of the ongoing work sits: in our estimate, operations and on-call make up the majority of the monthly cost, and PRO doesn't take them off your plate.

Client-side code that calls Centrifugo-specific APIs, subscribes to its channel semantics, or relies on its reconnection behavior will need to be reworked. Your application's data model and business logic typically don't. The migration guide's checklist helps you scope this for your setup.

Not as standard. Neither Centrifugo OSS nor PRO includes an uptime, latency, or delivery SLA, and PRO's prioritized support doesn't guarantee a response time. PRO's license allows service levels to be negotiated in a separate agreement, but any uptime you promise your own customers still depends on how your team runs the cluster.

Only if your team already meets the conditions covered above: existing in-house infrastructure and on-call, hard data residency requirements, or small enough scale that operational overhead stays low. Outside those conditions, the money saved on the subscription is typically spent again in engineering time, incident risk, and the guarantees you now have to build and prove yourself.