# Sockudo: a self-hosted realtime server with Pusher compatibility

> Sockudo is a Rust WebSocket and HTTP server that speaks the Pusher protocol for drop-in clients and adds its own Protocol V2 with recovery, durable history, mutable messages and a push pipeline. It is now a monorepo that also carries the client SDKs, the operator dashboard and a Helm chart, which is a much larger surface than a single server binary.

**sockudo/sockudo** — Blazingly fast pusher drop-in replacement written in rust

- Repository: https://github.com/sockudo/sockudo
- Website: https://sockudo.io/
- Stars: 828 · Forks: 72
- Language: Rust
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/sockudo-sockudo

## What the Pusher compatibility actually means

Sockudo describes itself as a high-performance Rust realtime server for WebSocket and HTTP publish workloads. It keeps strict Protocol V1 compatibility with the Pusher protocol, then adds Protocol V2 features for teams that need stronger delivery semantics and product-level control.

The framing in the README's own summary line is more precise than a marketing phrase: Pusher-compatible at the edge, Sockudo-native where you need recovery, history, mutable messages, push, AI Transport and first-party SDKs.

The distinction that matters for an evaluation is between the two protocols. Protocol V1 keeps the `pusher:` and `pusher_internal:` event prefixes and is a strict compatibility target, so an existing Pusher client library is expected to work against it. Protocol V2 uses the `sockudo:` and `sockudo_internal:` prefixes and is native to the server.

The feature table in the README makes the boundary explicit. Serial and message_id are stripped from delivery in V1 and native on relevant frames in V2. Recovery and rewind, mutable messages, annotations, tag filtering and deltas are all marked as not available in V1 and native in V2. AI Transport is an optional feature and runtime config in V2 only.

So a Pusher client is a way in, not a way to get the newer features. A team that wants recovery has to move its clients to V2, and the README warns that protocol defaults vary by SDK, so each package README has to be checked rather than assumed.

## The monorepo and what is inside it

The repository has changed shape, and the README says so plainly: this repository is now the Sockudo monorepo, containing the server, the Rust workspace crates, the dashboard, deployment assets, docs, official realtime client SDKs, HTTP server SDKs and the TypeScript AI Transport SDK.

The Cargo workspace shows the server's own decomposition.

```toml
members = [
  "crates/sockudo-protocol",
  "crates/sockudo-filter",
  "crates/sockudo-core",
  "crates/sockudo-app",
  "crates/sockudo-cache",
  "crates/sockudo-queue",
  "crates/sockudo-rate-limiter",
  "crates/sockudo-metrics",
  "crates/sockudo-webhook",
  "crates/sockudo-delta",
  "crates/sockudo-push",
  "crates/sockudo-ai-transport",
  "crates/sockudo-ably-compat",
  "crates/sockudo-adapter",
  "crates/sockudo-mcp",
  "crates/sockudo-server",
  "crates/sockudo-simulator",
  "benches/ai",
]
```

The crate names map onto the feature list, which is a good sign for a codebase that has to stay comprehensible as it grows. Protocol, filter, cache, queue, rate limiter, metrics, webhook, delta, push and the adapter are all separate crates, and there is a dedicated simulator crate and a Criterion benchmark crate for the AI hot paths.

The repository layout listing in the README adds the rest: client-sdks/ for the realtime client SDKs and the AI Transport SDK, server-sdks/ for the HTTP SDKs for backend publishers, dashboard/ for the operator API and a Vue UI, docs/, config/, ops/ for migrations, charts/ for the Helm chart, tests/ for conformance, dashboard, load and binary fixtures, and tools/ for probes and chaos tooling.

One detail is worth noting for anyone with existing references: the SDK directories preserve their original repository names, so package metadata, release scripts and issue references stay recognisable. There are also separate examples/ files, including tag_filtering.rs, moderation_flags.js, reactions_summary.js and read_receipts.js, which document the V2 semantics by example.

## Running it locally with Docker Compose

The quickest path to a running server is the compose file at the root of the repository.

```bash
git clone https://github.com/sockudo/sockudo.git
cd sockudo
make up
```

Four services come up by default, and their ports are listed in the README's table.

| Service | URL |
| --- | --- |
| Sockudo server | `http://localhost:6001` |
| Prometheus metrics | `http://localhost:9601/metrics` |
| Dashboard UI | `http://localhost:5174` |
| Dashboard API | `http://localhost:3460` |

The compose file itself shows the driver configuration, and it is worth reading because the server is assembled from swappable backends. The adapter, cache, queue and rate limiter drivers are all set to redis, the app manager driver is memory, and the metrics driver is prometheus, with the metrics enabled and bound to port 9601 with a `sockudo_` prefix. The Redis key prefix is `sockudo:` and the instance process id comes from the hostname.

The repository has around a dozen other compose files, each for a different shape, including ones for the dashboard, for dev, for production, for AI transport, for Redis cluster, for a multinode setup, for Iggy in single node and cluster forms, for OpenTelemetry, for a unix socket and for a test setup. That list is a reasonable map of the deployment questions the project expects people to have.

For the Helm route, the chart lives under charts/ and is also published as an OCI artifact.

## Installing a binary or building from source

The Linux install path is a single script, and the README describes what it checks.

```bash
curl --proto '=https' --tlsv1.2 -sSfL \
  https://sockudo.io/install.sh | sh
```

The installer detects GNU libc or musl and verifies the archive's SHA-256 checksum, and the installation guide covers version pinning and custom installation paths. The curl flags are the safer form of the same thing, pinning the protocol and requiring TLS 1.2.

Building from source needs a Rust toolchain.

```bash
rustup toolchain install stable
git clone https://github.com/sockudo/sockudo.git
cd sockudo

cargo run -p sockudo
```

The feature flags matter, and the README gives two useful shapes. A production-oriented build enables the pieces a deployment needs.

```bash
cargo build -p sockudo --release --features "v2,redis,postgres,push"
```

And a full build enables everything the server can expose.

```bash
cargo build -p sockudo --release --features full
```

The workspace pins edition 2024 with rust-version 1.95, and the resolver is set to version 3, which means a recent toolchain is a hard requirement rather than a recommendation. The Dockerfile builds on rust:1.99-bookworm, so the container and the local toolchain are close to each other in practice.

The Kubernetes route is a Helm install from the published OCI chart.

```bash
helm install sockudo oci://ghcr.io/sockudo/charts/sockudo --version 4.7.0
```

And the README gives a fuller production shape with Redis, ingress, autoscaling, a pod disruption budget and a service monitor, all set through --set flags. The defaultApp.existingSecret is worth noting because it constrains the Secret contents: it must contain `default-app-secret`, and may also include `default-app-id` and `default-app-key`.

## Fanout, history and the delivery semantics

The parts of Sockudo that go beyond broadcasting are the parts worth understanding before deploying.

Horizontal fanout runs through a pluggable adapter, and the README lists the supported backends: Redis, Redis Cluster, NATS, RabbitMQ, Google Pub/Sub, Kafka, Pulsar and Apache Iggy, the last of which in either single node or replicated VSR cluster form. The compose files include a dedicated Redis cluster and Iggy cluster setup, which suggests the clustering paths are exercised rather than theoretical.

Durability is layered. The README describes durable history, hot replay buffers, two-tier recovery, `until_attach` history reads, and degraded or reset-required continuity state. That last term is the interesting one: there is an explicit state where continuity is broken and the client has to be told to reset, rather than the server silently pretending the gap did not happen.

Mutable messages are versioned, with create, update, delete, append, summary, latest-visible reads and version history. Presence has membership plus retained presence-history transitions and snapshots. Annotations cover reactions, receipts, moderation, a summary projection and raw annotation streams.

The push pipeline covers FCM, APNs, Web Push, HMS and WNS. And the AI Transport is described as optional and built on the same versioned-message, history, recovery, push and presence primitives rather than a parallel streaming path, with a separate `ably-compat` facade exposing a reduced Ably AI Transport surface.

That last design choice is the one to look at closely. Building AI Transport on the existing primitives means one set of delivery semantics serves both, rather than a second system with different guarantees.

## Where Sockudo is the wrong tool

The first limitation is the operational surface. A self-hosted realtime service is a server, a fanout adapter, a database, a dashboard, a metrics endpoint, a set of SDKs and a Helm chart, and each of those is something to monitor. A team that only needs a chat channel or a live dashboard has taken on a distributed system to get it.

The second is the protocol split. If your client library is written against the Pusher API and you do not want to change it, you get V1, and with it no recovery, no rewind, no mutable messages, no annotations and no tag filtering. The features that make the server interesting are exactly the ones that need client changes, and the README is explicit that V2 defaults vary by SDK.

The third is the release cadence and the version spread. The recent releases are v5.1.0 from 2026-10-01, v5.0.1 from 2026-08-21 and v5.0.0 from 2026-08-20, so the server moves fast, and the README points to a feature comparison file and a changelog for what changed. The Helm chart version quoted in the install command is 4.7.0 while the server is at 5.1.0, so the chart and the server have separate version lines and you have to track both.

The fourth is the Rust toolchain requirement. Edition 2024 and rust-version 1.95 mean a team pinned to an older stable Rust cannot build from source, which pushes them to the prebuilt binary or the container.

The fifth is that the README is a long document with a lot of surface, and a few details live in files rather than in it. The ack section is cut off in the version available here, the delta compression has its own document at DELTA_COMPRESSION.md, and the docs directory holds the installation guide and the SDK publishing runbook.

## Sockudo compared with Pusher, Ably and a plain WebSocket server

The comparison with Pusher is the one the project is built around, and the difference in approach is ownership of the infrastructure. Pusher is a hosted service with a per-message and per-channel pricing model and a client library per language; Sockudo is the same protocol on a machine you control, with the operational burden and the data residency that implies. A team that needs to avoid a per-message bill, or that cannot send its traffic to a third party, has a reason to run this.

Ably is the more technical comparison, and it is where the `ably-compat` facade comes in. Ably's model is a set of channel types with presence and message history, plus a transport-agnostic protocol; Sockudo's V2 is a Pusher-shaped protocol with recovery and rewind, mutable messages and annotations. The Ably compatibility surface is explicitly described as reduced, so it is a bridge for tested AI Transport workloads rather than a full replacement.

The third comparison is with a plain WebSocket server, and this is where the value of the whole thing has to be justified. A WebSocket server written in any language will broadcast messages to connected clients. It will not do cross-node fanout, connection recovery with a serial, durable history with rewind, message mutation with version history, presence with a snapshot, annotations with reaction and receipt semantics, a multi-provider push pipeline, or a client SDK maintained for you. Each of those is a piece of distributed-systems work that the crates/ directory here represents.

The honest framing is that Sockudo is cheaper to run than a hosted provider at scale and more expensive to run than a dozen lines of WebSocket code, and the decision is about which side of that line your product sits on.

## Licence, tooling and the state of the project

The licence is MIT, with the LICENSE file at the root of the repository, and the workspace package metadata points at it. The repository is not archived and the last push was on 2026-10-19, so the project is actively worked on, and the 5.1.0 release is recent enough that the tree and the tag are close together.

The tooling is thorough for a project of this size. There is a CHANGELOG.md, a CONTRIBUTING.md, a CODE_OF_CONDUCT.md, an AGENTS.md and a CLAUDE.md, plus a deny.toml for cargo-deny, a .cargo/ directory whose config the Dockerfile explicitly preserves so that repository rustflags such as `--cfg tokio_unstable` survive the container build, and a fuzz/ directory for fuzzing.

The presence of benches/ai/ for permanent Criterion benchmarks on the AI hot paths and benches/presence/ for presence performance budgets is a good sign, because it means the performance claims in the feature list have a place to be checked in continuous integration. The loadtest/ and tools/ directories add load and chaos tooling, and tests/ carries conformance, dashboard, load and binary fixtures.

Two practical notes for anyone picking this up. The SDK publishing is governed by root workflows and there is a documented runbook at docs/sdk-publishing-2026.md that should be read before releasing packages or touching registry setup. And SwiftPM packages are mirrored to standalone package repositories, so the Swift package does not come from this monorepo directly.

## Conclusion

Sockudo suits a team that wants to leave a hosted realtime provider behind without rewriting its clients first, and that also wants recovery, message mutation and push without assembling those pieces separately. It is the wrong choice for a project that only needs a WebSocket broadcast, since the operational surface here is a server, a fanout adapter, a dashboard and a set of SDKs. Before deploying, decide which protocol your clients will speak, because the README states that V2 is not enabled by default in every SDK, and read the feature comparison file, since the choice between V1 and V2 determines whether recovery and history exist for you at all.

## FAQ

### What is Sockudo and is it compatible with Pusher?

Sockudo is a Rust realtime server for WebSocket and HTTP publish workloads that keeps strict Protocol V1 compatibility with the Pusher protocol. It also offers Protocol V2 with the sockudo: event prefix, adding recovery, rewind, mutable messages, annotations, tag filtering, deltas and an optional AI Transport.

### How do I run Sockudo locally?

Clone the repository, change into the sockudo directory and run make up. The default services are the Sockudo server on port 6001, Prometheus metrics on port 9601, the dashboard UI on port 5174 and the dashboard API on port 3460.

### Which message brokers can Sockudo use for fanout?

The adapter supports Redis, Redis Cluster, NATS, RabbitMQ, Google Pub/Sub, Kafka, Pulsar and Apache Iggy, the last in single node or replicated VSR cluster form. The default compose configuration sets the adapter, cache, queue and rate limiter drivers to redis.

### How do I install Sockudo with Helm?

Run helm install sockudo oci://ghcr.io/sockudo/charts/sockudo --version 4.7.0, or helm install sockudo ./charts/sockudo from a checkout when developing the chart. The README also shows a production shape with Redis, ingress, autoscaling, a pod disruption budget and a service monitor.

### What does the sockudo: protocol add over the pusher: protocol?

Protocol V2 adds native serial and message_id on relevant frames, recovery and rewind through hot replay and durable history, mutable messages under sockudo:message.*, annotations, tag filtering and deltas, and an optional AI Transport. Protocol V1 strips serial and message_id and has none of those features.

### What licence is Sockudo released under?

MIT, with the LICENSE file at the root of the repository, and the Cargo workspace package metadata pointing at that same file.

## Sources

- [License: MIT](https://github.com/sockudo/sockudo/blob/master/LICENSE)
- [Project website](https://sockudo.io/)
- [README](https://github.com/sockudo/sockudo/blob/master/README.md)
- [Releases](https://github.com/sockudo/sockudo/releases)
- [sockudo/sockudo on GitHub](https://github.com/sockudo/sockudo)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sockudo-sockudo