dotcommoners · Zig · MIT · SSE

SSE streaming to millions, brokerless.

RevenProx is a high-performance Server-Sent Events proxy built in Zig. It fans real-time event streams out to 10M+ concurrent clients across a distributed NNG mesh — with JWT auth, UUID topic routing, and a per-connection memory footprint small enough to make it affordable.

10M+ concurrent0 brokers100+ instancesMIT · self-hosted
revenprox — sse-proxy
# one static binary, then stream
$ zig build -Doptimize=ReleaseSafe
$ ./zig-out/bin/sse-proxy --config proxy.toml
▸ mesh   peered rp-2, rp-3  (brokerless)
▸ auth   webhook JWT · cache · breaker=on
▸ ready  listening :8080  conns=0/2000000

# subscribe a client to a UUID topic
$ curl -N localhost:8080/events/9f1c-a2 \
    -H "Authorization: Bearer <jwt>"
data: {"delta":"Hello"}
data: {"delta":" world"}

In one line

RevenProx is an open-source Zig SSE proxy for streaming real-time Server-Sent Events to 10M+ concurrent clients across 100+ instances over a brokerless NNG mesh — with JWT authentication, UUID topic-based routing, and a minimal per-connection memory footprint. MIT-licensed and self-hostable.

The problem: SSE at the scale of the whole internet

Server-Sent Events is the simplest way to push a one-way stream of updates from a server to a browser: a long-lived HTTP response that stays open and emits events over time. It is ideal for LLM token streams, live dashboards, notifications, and activity feeds. But the model has a hard edge — each connection stays open for the client's entire session, so a popular application does not have "requests per second," it has millions of connections held open at once.

At that scale the cost is not CPU; it is the memory and coordination overhead of every idle-but-open socket, and the fan-out problem of routing the right event to the right subset of those millions of clients. General-purpose reverse proxies and managed pub/sub services can be pressed into the role, but they either bottleneck on a central broker or make you pay per-message for infrastructure you could own. RevenProx is purpose-built for exactly this shape of workload.

Problem → Solution

Four hard problems, solved at the edge

These are not app problems — they are streaming-infrastructure problems. RevenProx fixes each at the source.

Problem

A broker becomes the ceiling. Every message and subscription passes through a central broker, so it is the thing you over-provision, license, and page someone about at 3am.

RevenProx

Brokerless NNG mesh. Instances peer directly; any node can accept a publish and route it to subscribers anywhere. You add throughput by adding nodes.

Problem

Idle connections are expensive. GC runtimes make millions of mostly-idle sockets costly and unpredictable — per-connection memory, not CPU, dominates the bill.

RevenProx

Low, predictable memory in Zig. No garbage collector and manual memory layout keep per-connection overhead small and plannable across a fleet.

Problem

Everyone gets everything. Naive fan-out floods every event to every connection, wasting bandwidth and leaking streams to clients that never asked.

RevenProx

Targeted UUID topic routing. Each event reaches only the instances holding subscribers for that topic, then only the matching local connections.

Problem

Auth storms take you down. Reconnect bursts hammer your auth service, and a degrading upstream turns into a thundering-herd outage.

RevenProx

Cached JWT + circuit breaker. Verification results are cached, and a circuit breaker trips when the auth upstream degrades — protecting it instead of amplifying the failure.

Capabilities

Real-time delivery, without a broker

Everything a streaming edge needs to hold millions of long-lived connections and route events precisely.

Massive scale

Architected for 10M+ concurrent SSE connections across 100+ proxy instances. Add capacity by adding instances to the mesh — throughput grows horizontally instead of pushing a single node harder.

Brokerless mesh

No central message broker to bottleneck, license, or babysit. State and events flow peer-to-peer across a fully distributed NNG mesh, kept consistent with bloom filters, merkle trees, and vector clocks.

UUID topic routing

Events are routed to subscribers by UUID topic, so each client receives exactly the streams it subscribed to — targeted fan-out instead of broadcasting everything to everyone.

JWT authentication

Clients are authenticated with webhook-based JWT verification. Results are cached to avoid re-hitting your auth service on every connect, and a circuit breaker shields that upstream when it degrades.

Built in Zig

No garbage collector and no heavyweight runtime means predictable, low per-connection memory — the property that actually governs cost when you hold millions of idle-but-open streams.

Self-hostable, MIT

Builds to a single static binary with Zig and runs on your own infrastructure. Docker and Kubernetes deployment guides are provided. Fully open source under the MIT license.

See the full feature breakdown →

Code

Plain SSE on the client. A brokerless mesh behind it.

Clients speak ordinary EventSource — no SDK. Each instance is a single Zig binary with a small config.

Client — subscribe with EventSource
client.js
// Browser client — subscribe to a UUID topic
const es = new EventSource(
  "https://edge.example.com/events/9f1c-…-a2",
  { withCredentials: true }
);

es.onmessage = (e) => {
  const token = JSON.parse(e.data);
  append(token.delta); // e.g. an LLM token
};
// SSE auto-reconnects; the mesh routes by topic.
Server — one instance in the mesh
proxy.toml
# config/proxy.toml — one instance in the mesh
[server]
listen        = "0.0.0.0:8080"
max_conns     = 2_000_000

[mesh]          # brokerless NNG peers
peers         = ["rp-2:7000", "rp-3:7000"]
gossip_ms     = 250

[auth]          # webhook JWT verify
webhook       = "https://auth.example.com/verify"
cache_ttl_s   = 300
breaker       = true
How it works

One publish, fanned out — no coordinator

A publish on any instance reaches every subscriber for that topic, wherever they are connected.

Publisherpublish(topic)rp-1rp-2rp-3Brokerless NNG meshclients · topic Aclients · topic B10M+ SSE conns

One publish, routed by UUID topic, fanned out to the right subscribers — no central broker.

Brokerless by design. Instances peer over NNG and keep distributed state consistent with bloom filters, merkle trees, and vector clocks — so there is no single node to bottleneck, license, or page someone about.

rp-1rp-2rp-3rp-4rp-5rp-6bloom filters · merkle trees · vector clocks — no coordinator

Every instance peers directly. State stays consistent with bloom filters, merkle trees, and vector clocks.

Read the full architecture — data path, state sync, auth flow, memory model →

10M+
Concurrent SSE connections
100+
Proxy instances in one mesh
0
Central brokers to run
Zig
No GC · predictable memory
MIT
Open source, self-hostable
Use cases

Where RevenProx fits

Any workload that pushes a one-way, real-time event stream to a very large audience.

AI & token streaming

Stream LLM tokens and agent events to huge audiences over a UUID topic per conversation — no broker in the path.

Live dashboards & metrics

Push fresh numbers to millions of open dashboards; targeted routing means each viewer gets only its streams.

Notifications & feeds

Deliver in-app notifications, activity, and presence the moment they happen, tied to your identity via JWT.

Multiplayer & collaboration

Broadcast the server-to-client half of live editors and shared sessions over a topic per room.

Market data & price feeds

Fan high-frequency tickers and odds out per-symbol; add watchers by adding instances, not a bigger bus.

CI/CD logs & build output

Relay bursty, long-lived build and deploy logs to browsers without polling or tying up app servers.

Explore detailed use cases →

Who it's for

Built for platform & infrastructure engineers

RevenProx is a piece of self-hosted infrastructure, not a SaaS. It is for teams that run their own streaming edge — platform, infra, and real-time engineers who need SSE fan-out at internet scale, want to own the data path, and would rather add nodes to a mesh than pay per message to a managed broker.

FAQ

Questions

What is RevenProx?

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

How many connections can RevenProx handle?

RevenProx is architected for 10M+ concurrent connections spread across 100+ proxy instances. Because it is brokerless and horizontally scalable, you add capacity by adding instances to the NNG mesh rather than scaling a central broker.

Why build an SSE proxy in Zig?

Zig gives RevenProx maximum throughput with a minimal, predictable memory footprint and no garbage collector — ideal for holding millions of idle-but-open streaming connections where per-connection overhead dominates cost.

Is RevenProx open source and self-hostable?

Yes. RevenProx is MIT-licensed and runs on your own infrastructure. It builds to a single binary with Zig and ships with Docker and Kubernetes deployment guides.

Read the full FAQ & glossary →

Stream at scale

Read the docs, browse the source, or reach out. Open source and self-hostable.

Get startedgithub.com/dotcommoners/revenproxContact us

contact@dotcommoners.com · Documentation