vaultbase

Sync that survives the real world

Offline-first with a persistent disk-backed queue, live SSE streaming when connected, and 3-way merge conflict resolution when edits collide. Permission-filtered — you only see events for files you can read.

Sync flow
Client A
Edits locally
queue: 3 pending
Server
Merges + broadcasts
SSE → filtered
Client B
Receives live
stream: connected
14:03:01 A pushes runbook.md (hash: a3f2..)
14:03:01 Server: clean merge with base (no conflict)
14:03:02 B receives SSE event (B has read access → delivered)
14:03:05 A + B both edit deploy.md → 3-way merge
14:03:05 Conflict in lines 12-18 → markers inserted, sidecar created

How it works

Live SSE streaming

When the editor is connected, the server pushes file change events over a persistent SSE (Server-Sent Events) connection. Updates arrive in real time — typically under 100ms from the moment a change is committed on the server. The SSE stream is permission-filtered: you only receive events for files your role can read. An engineering editor won't see HR file changes scroll by, even if they happen on the same server.

The editor titlebar shows sync status at a glance: ● Synced, ● 3 pending, or ● Offline.

Offline-first: persistent disk-backed queue

Edits made while offline are written to a persistent queue on disk — not held in memory. Close your laptop, lose Wi-Fi on a flight, or shut down the app entirely. When you reconnect, the queue drains automatically. Edits are applied in order, and each one goes through the same merge process as a live edit.

The queue survives app restarts. There is no "forgot to save before going offline" failure mode. If the file is on disk, the edit is in the queue.

3-way merge conflict resolution

When two clients edit the same file concurrently, VaultBase performs a 3-way merge using the common ancestor as the base. Non-overlapping changes merge automatically — if you edit line 5 and a colleague edits line 40, both changes apply cleanly. When edits overlap, VaultBase inserts standard conflict markers:

<<<<<<< local
Your version of the paragraph.
=======
Their version of the paragraph.
>>>>>>> remote

The editor detects conflict markers and shows a banner with one-click resolve: accept local, accept remote, or accept both. For manual resolution, edit freely and remove the markers.

Nothing is lost: conflict sidecar files

Every conflict also creates a sidecar file: deploy.conflict-2026-04-09T14:03:05Z.md. This is a full copy of the remote version at the time of conflict. Even if you resolve by accepting local, the remote version is preserved on disk. Sidecar files can be cleaned up manually or via vaultbase sync prune-conflicts.

This design means conflict resolution is never destructive. You can always go back.

Why it matters

Close your laptop and go

Disk-backed queues mean your work is safe before you think about saving. No "sync failed" pop-ups, no lost edits. Open the lid and everything catches up.

Collaboration without shouting

Real-time SSE means your team sees changes as they happen. No manual refresh, no "pull latest." The vault stays current across every open client.

Conflicts are recoverable

Sidecar files and conflict markers mean you never lose the other person's work. One-click resolve in the editor handles the common case; manual merge handles the rest.

Permission-aware streaming

Event streams are filtered by your role. You won't see file names, change events, or metadata for files you can't access. Security doesn't stop at the HTTP layer.

Related features

Download VaultBase

Free. Works offline. No account needed.

Open source. AGPL-3.0. Plain markdown files. Export anytime.