Durable Streams: an HTTP protocol for resumable, replayable streams
The data primitive for the agent loop.
At a glance
- What is it?
- Durable Streams is an MIT-licensed TypeScript monorepo that defines an HTTP protocol for ordered, offset-based streams with catch-up reads and live tailing, aimed at agent sessions and collaborative apps. It is in beta, and the README points install instructions at durablestreams.com rather than spelling them out.
- Who is it for?
- Adopt Durable Streams if you are building agent sessions or collaborative apps where clients reconnect constantly and you want resume semantics handled by the protocol instead of by a bespoke backend. Do not adopt it if your data already lives in Kafka and every consumer is a server, because the HTTP offset model buys you little there.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Durable Streams fills for agent sessions
The README frames the problem in terms of client fragility. WebSocket and SSE connections are easy to open but break when a tab is suspended, a network flaps, a device switches, or a page refreshes. When that happens, the README says, you either lose in-flight data or build a bespoke backend storage and client resume protocol on top. The project's answer is a stream that is addressable as a URL and readable from any offset, so a client that reconnects asks for what it missed rather than restarting the work.
The audience is specific. The README lists AI conversation streaming, agentic apps, database synchronization, collaborative editing, real-time updates, event sourcing, and workflow execution. What those have in common is a consumer that is a browser, a phone, or an edge worker rather than a backend service. Durable streams already exist inside database write-ahead logs and Kafka topics, but the README's claim is that they are not available as a first-class primitive for client applications. That is the gap this project is trying to occupy.
The framing also explains the name of the site's other posts: durable sessions for collaborative AI. If your product shows tokens arriving from a model and a user can refresh mid-response, the stream failing means the product failing, even when the model behaved correctly.
How the protocol works: HTTP, offsets, catch-up and tailing
The mechanism is deliberately plain. The README describes a minimal HTTP-based protocol for creating and consuming ordered, replayable data streams, with support for catch-up reads and live tailing. Streams are content-type agnostic byte streams, so the protocol does not prescribe what a message means; JSON mode and the higher-level packages layer structure on top.
Resumability is offset-based. A reader tracks its position and asks to resume from that point, which the README calls out as offset-based resumability and exactly-once message delivery over the public internet. Live tailing comes in two modes, long-poll and SSE, and the README states that both support catch-up from any offset. That combination matters: a client that has been offline for an hour and a client that is watching in real time use the same read path, just from different starting offsets.
The scaling story is CDN-shaped. Because everything rides on standard HTTP, the README says the design is CDN-friendly and that one origin can serve millions of concurrent viewers. That is a design claim, not a measured number, and the README does not publish a benchmark to support it. What is verifiable from the repository layout is the shape of the implementation: a PROTOCOL.md specification at the root, a packages/ directory with client and server packages, and a CLIENT_MATURITY.md file that suggests clients across languages are at different levels of completeness. The release list confirms this split, with @durable-streams/server and @durable-streams/state versioned separately at 0.3.x.
Installing Durable Streams and creating a first stream
The README does not include install commands. It routes installation through the Quickstart page at durablestreams.com/quickstart, which it describes as covering starting the server and creating your first stream. Treat that page as the source of truth for the exact commands, because the repository README and package.json do not spell them out.
What the repository does tell you is the toolchain the monorepo expects. The root package.json sets the package manager to pnpm@10.25.0 and declares an engines field requiring Node 22 or later, so any local work against the repository needs those versions.
{
"packageManager": "pnpm@10.25.0",
"engines": {
"node": ">=22"
}
}If you are working from a clone rather than from published packages, the root scripts give you the entry points. The start:dev script filters to the CLI package and runs its start:dev target, which is the closest thing in the repository to a documented way to bring the tooling up locally.
pnpm install
pnpm start:devThe README lists the CLI as the tool for creating, reading, appending to, and tailing streams, and links its documentation at durablestreams.com/cli. It does not reproduce the CLI flags, so the specific arguments for creating a stream are not something this article can state. For a first real use, the shortest path the README offers is the quickstart followed by the CLI page, then the TypeScript client page for programmatic reads and writes. The examples/ directory in the repository contains working reference applications, including chat integrations for the Vercel AI SDK, Cloudflare, and TanStack AI, a state example, a stream-db example, and a Yjs demo. Those are the concrete artifacts to read once the server is running.
Where Durable Streams is the wrong tool
The protocol is byte-oriented and content-type agnostic, which means it does not validate, index, or query what you put in a stream. If you need to ask questions across many streams, join events, or retain data with a query engine, a stream is a transport, not a store, and you will end up writing the indexing layer yourself. The README's event sourcing and database synchronization bullets describe streaming changes outward; they do not claim the stream replaces the database that produced them.
The second limitation is maturity, and the project says so itself. The README carries a status badge reading beta, and CLIENT_MATURITY.md exists as a separate file, which implies that not every language client is at the same level. The published versions back this up: the server and state packages are in the 0.3.x line. Anyone treating a 0.x protocol as frozen should read PROTOCOL.md before designing around it, because the README does not make a stability promise about the wire format.
The third is operational. The README's scaling argument rests on HTTP and CDN infrastructure, but it does not document retention, compaction, or what happens to a stream that grows without bound. Those questions are not answered in the README, and a team that needs a documented retention policy will have to look at the server documentation rather than the front page.
Durable Streams and the resumable stream pattern in other stacks
The closest familiar alternative is a resumable stream layer bolted onto Redis, the pattern associated with Upstash, where the stream buffer lives in Redis and a client resumes by replaying from an offset. The difference is where durability lives. In that pattern, Redis is the system of record for in-flight data and the resume protocol is something you implement against its API. Durable Streams inverts this: the protocol itself defines the offset semantics and the read modes, and the server implementation is a detail behind the HTTP surface. The README describes the protocol as production-proven from 1.5 years of use at Electric for real-time Postgres sync, which is the project's evidence for the semantics rather than for the code you would install today.
A second comparison is Kafka. Kafka gives you ordered, replayable logs with consumer offsets, and it is the obvious reference point for anyone who reads the phrase durable stream. The difference is the client. Kafka's consumers are services with a broker connection and a consumer group; Durable Streams targets browsers, mobile apps, IoT devices, and edge workers over plain HTTP. If your consumers are all backend services, Kafka's ecosystem is deeper and the offset model is not new. If your consumers are tabs and phones that reconnect constantly, the HTTP-native design is the reason to look here. The README also positions the project as composable, noting that higher-level abstractions can be built on top, and names Electric's real-time Postgres sync engine as one such layer.
Maintenance, releases and the MIT licence
The repository is not archived, and the last push was on 2026-09-10, which is days before this article. The release cadence visible in the release list is uneven in a way worth noting: @durable-streams/state@0.3.0 and 0.3.1 both landed on 2026-06-03, and @durable-streams/server@0.3.7 landed the same day. Three releases on one day, then a gap in the published list. That pattern is consistent with a changesets-driven monorepo, which the root package.json confirms through its changeset, changeset:version, and changeset:publish scripts. Version bumps are batched and published together rather than continuous.
The upgrade cost follows from that structure. Packages are versioned independently, so client, server, and state can drift apart, and the lockstep build script in the root package.json excludes internal and example packages from the standard build. A team pinning versions should pin each package separately and read the changeset entries rather than assuming the server version implies a client version.
The licence is MIT, which the README badge states and the repository LICENSE file carries. MIT permits commercial use and modification. The README's license badge links to the Electric repository's LICENSE path, which is a cosmetic inconsistency rather than a licensing one, but anyone doing a compliance review should read the LICENSE file in this repository rather than the badge target. Nothing here is legal advice.
Editorial conclusion
Adopt Durable Streams if you are building agent sessions or collaborative apps where clients reconnect constantly and you want resume semantics handled by the protocol instead of by a bespoke backend. Do not adopt it if your data already lives in Kafka and every consumer is a server, because the HTTP offset model buys you little there. Before committing, verify the install path at durablestreams.com/quickstart, since the README does not carry the commands, and read PROTOCOL.md to confirm the offset and delivery guarantees match what your client actually needs. Then pin the client and server package versions you settle on, because the published releases are still in the 0.3.x range.
Frequently asked questions
What are durable streams?
In this project, a durable stream is an ordered, replayable sequence of bytes addressable as a URL and readable over HTTP. The README describes the protocol as supporting catch-up reads from any offset and live tailing through long-poll and SSE modes, with exactly-once message delivery over the public internet.
What is a simple definition of stream?
The README treats a stream as a content-type agnostic sequence of bytes that can be read from an arbitrary offset, which is why the same read path serves both a client catching up after a disconnect and one tailing live data. It does not define the term more generally than that.
What is the purpose of streams in Durable Streams?
The stated purpose is to give client applications a durable, offset-based primitive for ordered data, so that refreshes, tab switches, and network changes resume where the client left off. The README lists AI conversation streaming, agentic apps, database synchronization, collaborative editing, real-time updates, event sourcing, and workflow execution as the patterns it targets.
What are the different types of data streams in Durable Streams?
The README distinguishes read modes rather than stream types: catch-up reads from a stored offset, and live tailing in either long-poll or SSE form. It also points to higher-level layers built on the byte stream, such as JSON mode, Durable State, StreamDB, and StreamFS.
Community notes