Open-source realtime infrastructureSupport the project
Own realtime infrastructure. Keep the clients you already ship.
Sockudo is a self-hosted Rust realtime server. Keep Pusher clients on Protocol V1, or opt into Ably REST and WebSocket compatibility, excluding Live Objects. Move to Protocol V2 durability, horizontal fanout, push, and AI Transport when you need them.
Client compatibilityChoose the edge. Keep control of the server.
View scope
Deployed in your infrastructureSockudoRust + Tokio · one server, multiple protocol edges
Open sourceHorizontal fanoutDurable recoveryPush + AI Transport
Documentation map
Start with the decision you are making.
The homepage routes operators, backend teams, client developers, and AI product teams into the part of the docs that answers their next production question.
Launch the server
Install Sockudo, choose a runtime, configure apps, and get a local realtime endpoint running.
Open guideChoose a client path
Keep Pusher clients, use the opt-in Ably REST/WebSocket facade, or adopt Protocol V2 SDKs.
Open guideOperate the cluster
Plan scaling, metrics, webhooks, rate limits, queues, durable history, and recovery paths.
Open guideBuild AI transport
Layer agent streams, rollups, push, annotations, and recovery on the same durable primitives.
Open guideRuntime architecture
A compatibility layer that grows into a durable platform.
Sockudo keeps the Protocol V1 contract stable while Protocol V2 unlocks history, recovery, annotations, push delivery, and AI stream primitives on the same fanout core.
Read history and recovery
Production surface
Everything operators expect before realtime becomes critical path.
Compatibility is the on-ramp. The docs also cover the stateful, distributed, and observable pieces that make Sockudo viable when missed events are not acceptable.
Pusher-compatible edge
Protocol V1 preserves Channels clients, Laravel Echo, auth shapes, and server publish flows.
Ably compatibility facade
Opt-in REST and WebSocket compatibility over JSON and MessagePack, excluding Live Objects.
Protocol V2 control
Native prefixes, message IDs, serial continuity, filters, deltas, annotations, and rewind.
Horizontal fanout
Redis, Redis Cluster, NATS, Kafka, RabbitMQ, Pulsar, Google Pub/Sub, Iggy, or memory.
Durable recovery
Hot replay buffers, durable history, opaque cursors, presence history, and mutable messages.
Push and operations
Push, webhooks, metrics, readiness, quotas, retries, provider status, and delivery signals.
SDK shelf
Client and server SDKs stay close to the protocol.
Every official SDK path includes installation, configuration, authentication, publish flows, history, and production guidance for teams adopting Sockudo incrementally.
Engineering notes
Design notes for the realtime edge.
The blog explains the tradeoffs behind the docs: protocol evolution, multi-node operations, SDK boundaries, and the practical shape of ownership.
Auth, origin checks, TLS, quotas
Durable history and version stores
Metrics, health, readiness, webhooks
Designing a realtime protocol that can evolve
How Sockudo preserves Pusher compatibility while adding serial continuity, native features, and migration room.
Running realtime infrastructure across nodes
Adapters, duplicate delivery, recovery, observability, and fanout failure modes for production clusters.
Choosing SDK surfaces for product teams
Where credentials belong, how client and server responsibilities divide, and which SDK surface to reach for.