Introduction

Runnev is event streaming over plain HTTP. A stream is an ordered, durable log addressed by a base62 id. You publish batches to it with POST and read them back with a long-lived GET that streams server-sent events.

The mental model

One publisher appends batches to a stream. Each batch lands at a monotonically increasing sequence number. Any number of subscribers read the stream independently, each holding its own cursor, which is just the sequence of the last batch it has seen. A subscriber that disconnects reconnects with its cursor and continues exactly where it left off.

publisher --POST /v1/streams/{id}/{seq}-->  +------------- stream {id} -------------+
                                            |  ... 41821  41822  41823  41824(head)|
                                            +---+-------------+--------------+-----+
                    GET (Accept: text/event-stream), each at its own cursor   |
                          |             |              |                      |
                       sub A          sub B          sub C                 sub D
                      cursor 41824   cursor 41822   cursor 40010          cursor head

That is the entire model. There is no exchange, no routing key, no consumer group to configure. A stream is a log; publishers write to the head; readers move a cursor forward.

When to use Runnev

Runnev fits when you need to move an ordered flow of events across a network you do not fully control:

• Fan out domain events (orders, jobs, telemetry) to several independent readers.
• Deliver live updates to browsers, mobile apps, or serverless functions that cannot hold a raw socket.
• Bridge a backend to workers that come and go and need to resume without losing their place.
• Ship a firehose to an analytics sink that occasionally falls behind and catches up from a cursor.

When not to use it

It is the wrong tool when you need queue semantics:

• Per-message acknowledgement and redelivery to a specific worker. Runnev has no per-consumer acks. Use a task queue.
• Competing consumers that each take a slice of the work off one shared queue. Runnev delivers the whole stream to every subscriber.
• Strict exactly-once processing with no dedup on your side. Runnev is at-least-once with idempotent writes; dedup is a one-line check but it is your check.

The four operations

New here? The quickstart gets you from nothing to a running subscriber in a few minutes.