RevenProx: frequently asked questions

RevenProx is an open-source, high-performance Server-Sent Events (SSE) proxy built in Zig by dotcommoners. It sits at the streaming edge and relays long-lived SSE connections to very large numbers of clients, using a brokerless NNG mesh for distributed state, UUID topic-based routing for targeted delivery, and JWT authentication. It is MIT-licensed and self-hostable.

RevenProx is architected for 10M+ concurrent connections spread across 100+ proxy instances. Because it is brokerless and horizontally scalable, you scale by adding instances to the NNG mesh rather than growing a central broker. Zig’s low, predictable per-connection memory is what makes holding millions of idle-but-open streams practical.

Yes. RevenProx is released under the MIT license and the source is on GitHub at github.com/dotcommoners/revenprox. You can read, modify, self-host, and deploy it freely.

It means the proxy instances talk to each other directly over NNG (nanomsg-next-gen) to form a peer-to-peer mesh, with no central message broker in the middle. State — which topics exist and where subscribers live — is kept consistent across the mesh using bloom filters, merkle trees, and vector clocks. Removing the broker removes the usual pub/sub scaling ceiling: any instance can accept a publish and route it to subscribers anywhere, so you add capacity by adding nodes.

Server-Sent Events is a simple, HTTP-native, one-way (server-to-client) streaming protocol: a long-lived HTTP response that emits events over time, with built-in auto-reconnect. That is a perfect fit for fan-out workloads like token streams, dashboards, notifications, and feeds, where clients mostly receive. WebSockets are full-duplex and better when you need low-latency bidirectional messaging. RevenProx is purpose-built for the one-way, massive-fan-out SSE case; clients that need to send data back do so over ordinary HTTP requests.

RevenProx builds to a single static binary with Zig (for example, zig build -Doptimize=ReleaseSafe) and runs on your own infrastructure. You run instances, they form the NNG mesh, and you scale by running more of them. Docker and Kubernetes deployment guides are provided in the documentation at docs.dotcommoners.com/revenprox.

Clients present a JWT, which RevenProx verifies via a webhook to your own auth service rather than embedding your auth logic. Verification results are cached so reconnect bursts do not hammer your auth service, and a circuit breaker trips if that upstream degrades — protecting a struggling dependency instead of amplifying the outage.

By UUID topic. Clients subscribe to a topic and publishers publish to a topic; the mesh routes each event only to the instances holding subscribers for that topic, which then write it down the matching local SSE connections. UUID topics give an effectively unlimited, collision-free namespace, so you can mint a topic per user, session, document, or conversation without coordination.

Holding millions of mostly-idle connections makes per-connection memory, not CPU, the dominant cost. Zig has no garbage collector and no heavyweight runtime, giving small and predictable per-connection overhead — so a node’s capacity is a number you can plan a fleet around. That is what makes the 10M+ concurrent, 100+ instance target reachable.

With three primitives working together: bloom filters give each instance a compact summary of which topics it has subscribers for (so peers can skip forwarding events that would go nowhere); merkle trees let instances compare state by exchanging hashes and reconcile only the parts that differ; and vector clocks order updates across nodes without a global clock, detecting concurrent changes so the mesh converges instead of racing.

No. RevenProx is self-hosted infrastructure that you run yourself — there is no vendor control plane and no per-message billing. If you would prefer never to operate a mesh, a managed pub/sub service trades that ownership for someone else running it; see the comparison page for the tradeoffs.