A primitive, not a database
An append-only op log on the server, a durable outbox on the client. No Postgres, no container, no WebSocket.
Nothing acknowledged yet.
Empty. Every write has landed.
Go offline and keep writing — ops queue with no sequence number,
because nothing has confirmed them. Come back online and the outbox
drains: the journal assigns each op a seq, and only then
is it safe to forget locally.
Why this exists
Every credible offline-first engine — Electric, PowerSync, InstantDB — wants Postgres and a long-running container. On an all-Cloudflare stack that is a second backend, forever. (Zero wants both too, and doesn't do offline writes at all — it says so itself.) Triplit had a Durable Object adapter, then its co-founder joined Supabase and it has sat unmaintained since. Meanwhile a Durable Object is a single-threaded ordering point, per user — which is the thing everyone else needs Postgres for.
It is a primitive, not a database. You bring the storage and the meaning.
Ops are immutable facts appended to a log. If your writes are events — "this happened" — you don't have a conflict problem. If you genuinely need merge, you want a CRDT.
A socket is useless in a basement. Sync happens when the app is open and the network exists.
Bring your own IndexedDB. The package ships two entry points and nothing else.
The journal can't fold the log — it never reads a payload, which is what keeps it a primitive. So a client folds and the journal stores the result opaquely. Optional, and refusable: the log alone always rebuilds you.
Quickstart
Server — the log
Extend the Durable Object and export it. One instance per user is the
whole design: idFromName(userKey) buys serialized writes
and natural isolation, for free.
// worker.ts
import { SyncJournal } from "durable-sync/server";
export class Journal extends SyncJournal {}// wrangler.jsonc
{
"durable_objects": {
"bindings": [{ "name": "JOURNAL", "class_name": "Journal" }]
},
"migrations": [
{ "tag": "v1", "new_sqlite_classes": ["Journal"] }
]
}
Then forward POST and GET from your own route.
Note what you do not route: DELETE (reset).
The Durable Object serves it, but it stays reachable only through the
binding — expose exactly what you want public.
Client — the outbox
Commit locally, queue the op, let the network catch up. apply
must be idempotent: an op can arrive more than once.
import { createSync, localStorageCursor }
from "durable-sync/client";
export const sync = createSync({
endpoint: "/api/sync",
outbox: dexieOutbox(db.outbox),
cursor: localStorageCursor("myapp.cursor"),
stateKey: "myapp.syncState",
// Idempotent: an op can arrive twice.
async apply(op) {
if (op.kind !== "note") return false;
const note = op.payload as Note;
if (await db.notes.get(note.id)) return false;
await db.notes.put(note);
return true;
},
// Pushing is always safe. Pulling might not be.
canPull: async () => !(await inProgress()),
});// Writing is local-first.
await db.notes.put(note);
await sync.enqueue({ opId: note.id, kind: "note", payload: note });
void sync.now({ force: true }); // never await on a user pathThe outbox must be durable. Until a push is acknowledged it may hold the only copy of a write, and memory does not survive iOS killing a backgrounded PWA. Put it in IndexedDB.
Four incidents
These are the reason the package exists. Each is a real bug from the app this was extracted from — and each one looked completely fine from the outside, which is the point.
Silent data loss
Behind an auth proxy like Cloudflare Access, an expired session
redirects to a same-origin login page. fetch
follows it and reports 200. Drain the outbox on
res.ok and you delete writes that never landed.
What this does Validates the reply's shape before touching the queue. The outbox only drains against something the journal demonstrably wrote.
Silent stall
Reset the log and every client still holds a sequence number from the
old one — usually past the rebuilt one. So
seq > cursor matches nothing and the client
never syncs again, quietly, forever.
What this does
Every pull carries an epoch. A client that sees a new one
replays from zero. apply is idempotent, so replay is cheap.
Silent corruption
Applying a remote op mid-workout overwrote the working weight that the finish logic reads back — and silently dropped a 5×5 to a 3×5. Pushing is always safe. Pulling is not.
What this does
canPull() defers the pull while something is in flight.
Eventual consistency makes waiting free.
Unrecoverable
The journal is addressed by a server-side identity while ops carry whatever the client selected. Write as the wrong one and the data is filed under someone else — permanently, in an append-only log. The gate was on the engine; a caller went straight to the transport.
What this does
The transport isn't exported. canWrite() can't be skipped,
not even by force. There is one way in.
What this does not do
apply is yours.createSync is single-tenant — one instance per identity, memoized.If you need any of those, you want a real sync engine — Zero, Electric, PowerSync — and the Postgres that comes with it. Here's an honest comparison ↗
Prior art
Cloudflare's own, and the closest thing to this. Delta sync over a WebSocket, with an IndexedDB read cache — so it shows last-known state offline, it just has no write queue. Its README files that under a heading called "Maybe won't do." This does it.
Had a Durable Object adapter. Unmaintained since September 2025 — not archived, but nothing merged or released since. Still worth reading.
A real CRDT. Use it if you genuinely need merge.
Also a real CRDT, with a different set of trade-offs.