local-first  · 

Local-first memory for coding agents, optionally synced

Docmancer keeps your coding agents' memory local by default. When you want it on a second machine or shared with a team, encrypted cloud sync uploads ciphertext and never the memory itself.

Most memory tools for coding agents start by asking you to send your data somewhere. You sign up, you paste an API key, and from then on the record of what your team decided lives on someone else's server. Docmancer starts from the opposite default: everything runs on your machine, and the only thing that ever leaves is ciphertext you explicitly opt into uploading.

This post explains exactly what stays local, what the optional cloud path does, and how the boundary between the two is drawn so you can reason about it rather than trust a marketing claim.

What local means here

When you install Docmancer and index your agents' memory, nothing touches the network:

pipx install docmancer --python python3.13
docmancer setup
docmancer sync
docmancer query "why did we pick Railway for production workers?"

The default engine is a static model2vec embedding model vendored inside the package, sqlite-vec for dense retrieval, and SQLite FTS5 for lexical search. There is no API key to set, no vector database daemon to run, and no model to download. setup and sync harvest the memory your agents already wrote, reconcile it into reviewed context packs, and compile that context back into each agent's always-loaded file. query searches it. Every one of those steps completes offline.

Recall, capture, the terminal explorer, MCP search, the local security audit, Git-based team memory, and Markdown export all work the same way, with or without an account. That is deliberate: the features that make Docmancer useful day to day do not depend on a server being reachable, funded, or trustworthy.

What actually leaves the machine, and when

There are exactly two paths that can send anything out, and both are opt-in.

The first is consolidation drafting. If you run docmancer memory consolidate, Docmancer sends selected memory atoms to OpenRouter to produce a single review-only markdown draft. Before any text leaves, a privacy filter redacts likely secrets and credentials, and the command prints a cloud-use notice you have to confirm. Without OPENROUTER_API_KEY set, the command exits cleanly and touches nothing. This path is optional maintenance, not the core memory loop, and the everyday distill-and-review flow that reconciles your packs is deterministic and fully local.

The second is encrypted cloud sync, which exists so your reviewed context can follow you to a second machine or a teammate without giving up the local-first guarantee.

How encrypted sync draws the boundary

Cloud sync is off until you connect an account:

docmancer cloud connect --base-url https://api.docmancer.dev --create-recovery
docmancer cloud sync
docmancer cloud devices

Connecting shows a verification code and opens an approval page, then stores a recovery key you keep offline. The important part is what the server receives. Memory text, tags, and local file paths are encrypted on the device before anything is uploaded, using a workspace key that the service never holds. What the API stores and relays is ciphertext, along with the delivery metadata it needs to route revisions between your devices. It cannot read your memory, and neither can anyone who compromises the server.

Adding a second device follows the same rule. A new device unwraps the workspace key only after an already-trusted device approves it, and the approval step shows a fingerprint so you can confirm you are trusting the right machine rather than an impostor. docmancer cloud devices lists every registered device with its trust state and last-seen time, and you can revoke any of them.

Offline is the normal case, not an error state

Because the local store is the source of truth, losing connectivity changes nothing about how you work. Local writes create immutable revisions and queue encrypted envelopes. When the network returns, the client retries idempotently, verifies device signatures and ciphertext, writes the decrypted records durably, and only then advances its transport cursor. If you never reconnect, recall, capture, the terminal explorer, MCP, docs, audit, and Git memory keep working exactly as before.

Disconnecting is equally undramatic:

docmancer cloud disconnect

Disconnecting does not delete anything local. Remote export and remote deletion are separate, explicit account operations, so stepping away from the cloud never silently destroys the memory you have on disk.

Why this ordering matters

The reason to build memory local-first is not ideology, it is failure modes. A hosted-only memory layer fails in ways you cannot fix: the vendor goes down, changes pricing, gets breached, or shuts the product. Docmancer inverts that. The durable copy of your team's decisions lives on your machine in an inspectable SQLite database, the reconciliation that turns raw notes into reviewed context runs deterministically without a model, and the network is an optional convenience layer that only ever sees ciphertext. You get the multi-machine and team benefits of sync without handing over the thing that makes the memory valuable.

Try the local path first

pipx install docmancer --python python3.13
docmancer setup
docmancer sync
docmancer status
docmancer query "what deployment decisions have we recorded?"

Run it with no account and no key, and confirm from docmancer status that everything indexed locally. When you want the same reviewed context on another machine, the encrypted cloud sync guide walks through connecting a device and approving a second one.