Options / route for using MemPalace across two machines

[streeyt]

This looks amazing.

Before I jump in though, something I didn't find covered but seems like such a common case I probably just missed it:

I split my Claude Code life across a desktop Mac and a MacBook. I'd like a seamless "in sync" MemPalace between the two. Both mined initially and both updating my (one) palace on an ongoing basis.

As data storage seem local to each machine - what options would I have? Can I setup a local (to my LAN) or even cloud based storage alternative, with Neon etc?

Thanks

[director-LAC]

I am SUPREMELY interested in discovering best practice for this.

[director-LAC]

I burned a metric shit ton of Fable tokens to come up with a solution. here's the community writeup. In eventuality hopefully the mempalace team can come up with a sync solution but until then, its a start:

Syncing mempalace across multiple machines: a working community pattern

Shared for anyone hitting the "my two machines each remember different
things" problem. mempalace (as of 3.5.0) has no built-in multi-machine sync
(the export/import commands discussed in #452 are not shipped yet). The
pattern below has been running in production for me and survived a full
verification suite. It is built entirely on mempalace's public internals, so
anyone can reproduce it. Maybe it also serves as a design sketch if the
maintainers ever build this natively.

The problem

Run mempalace on two or more machines and each palace accumulates its own
memories. Machine A can recall things machine B has never heard of. Worse,
every obvious quick fix is a trap:

Do not file-sync the palace directory. Not with Dropbox, OneDrive,
Syncthing, an SMB share, or rsync while anything is running. The palace is
chroma.sqlite3 plus HNSW binary segment files that must change together.
Partial or non-atomic transfers silently corrupt the HNSW index (the classic
symptom: sqlite says 9,000 drawers, the vector index knows about 1,000, and
recall quietly falls off a cliff until mempalace repair). Multi-process
concurrent writers on one palace cause the same class of corruption, which is
exactly why 3.5.0 added the local write daemon.

So the sync has to be logical, not file-level: export memories as records,
re-file them on the other machine through mempalace's own write path.

The architecture in one paragraph

A private git repo is the transport and the ground truth. Every machine
appends its new memories to its own append-only JSONL journal files inside
that repo (journals/<MACHINE>/drawers-YYYY-MM.jsonl and friends), and on
each sync run replays every peer's journals into its own palace. Because each
machine only ever writes its own files, git merges are structurally
conflict-free. The fleet's ground truth is the union of all journals minus
the union of all tombstones. A dead machine loses nothing (its journals
remain), and a brand-new machine bootstraps the entire shared memory by
replaying everything.

journals/<MACHINE>/drawers-YYYY-MM.jsonl   one JSON record per drawer, append-only
journals/<MACHINE>/diary-YYYY-MM.jsonl     diary entries (they are drawers too)
journals/<MACHINE>/kg-YYYY-MM.jsonl        knowledge-graph entities/triples
tombstones/<MACHINE>.jsonl                 explicit "forget everywhere" ledger
state/<MACHINE>.json                       published health snapshot per machine

Each journal record carries the drawer's original id, verbatim content, all
its metadata, a content hash, and the origin machine name.

Why this is safe (the load-bearing mempalace internals)

1. Drawer IDs are deterministic and portable. MCP-added drawers are
   drawer_{wing}_{room}_{sha256(wing|room|content)[:24]} (see
   mempalace/ids.py, make_drawer_id_from_content). If you preserve the
   original id on import, replaying a journal is naturally idempotent: the
   same record imported twice is a no-op upsert.

2. There is a documented-safe write path. Since 3.3.5, every write method
   on ChromaCollection (get it via mempalace.palace.get_collection)
   acquires the same per-palace lock (mine_palace_lock) used by the miner,
   the MCP server, and the 3.5.0 daemon. Your importer becomes just another
   serialized writer. The lock is non-blocking and raises
   MineAlreadyRunning on contention, so wrap each batch in a retry with
   exponential backoff and you coexist politely with hooks and daemons.
   ChromaCollection.upsert(ids=..., documents=..., metadatas=...) accepts
   explicit ids, which is what makes id preservation possible.

3. Vectors never cross machines. Journals carry text, not embeddings.
   Every import re-embeds locally through the collection's own embedding
   function. No HNSW file is ever transferred, so the corruption vector is
   gone by construction. (Corollary: every machine must use the same
   embedding_model; enforce that in a preflight check.)

4. Export never opens chromadb. Read chroma.sqlite3 directly with a
   read-only URI (mempalace.config.sqlite_read_uri). The join you need is
   the same shape mempalace's own repair code uses:

   SELECT e.id, e.embedding_id
   FROM embeddings e
   JOIN segments s    ON e.segment_id = s.id AND s.scope = 'METADATA'
   JOIN collections c ON s.collection = c.id
   JOIN embedding_metadata fm ON fm.id = e.id AND fm.key = 'filed_at'
   WHERE c.name = 'mempalace_drawers' AND fm.string_value > :watermark
   ORDER BY fm.string_value

   Then fetch all embedding_metadata rows for those ids; the document text
   itself is the metadata key chroma:document. Every drawer has filed_at,
   which gives you an incremental watermark (keep a generous overlap window,
   e.g. 48 hours, and dedup re-reads against a local index; id determinism
   makes overlap free).

The details that will bite you if you skip them

Echo prevention. When machine B imports A's drawer, B must never re-export
it as its own or the record ping-pongs forever. Stamp every imported drawer
with an origin_machine metadata key, and have the exporter skip any row
that carries one.

Do not sync the registry rows. Rows with room = "_registry" (or ids
starting _reg_) are per-machine "this transcript was already mined" state.
Importing them onto a peer suppresses that peer's own mining. Filter them out
of exports. Same for the mempalace_closets collection, which indexes local
file paths.

Deletions: make them explicit or do not make them at all. mempalace
deletes are hard deletes with no tombstones, and source-file prunes
(mempalace sync) are inherently machine-local. If you naively mirror
deletions you will one day propagate an accident to every machine. My rule:
sync is add-only, and the only deletion that propagates is an explicit
forget <drawer_id> command that deletes locally and appends to a tombstone
file every machine applies before importing. Tombstones win over journals
forever.

Diary entries are drawers. tool_diary_write files ordinary palace
drawers (room diary, type diary_entry), so a drawer exporter gets them
for free.

Knowledge-graph triples need direct SQL. Triple ids hash the insert-time
recorded_at, so replaying add_triple() on another machine mints a
different id. Import triples with direct sqlite INSERTs preserving the
original id (the KG db is WAL-mode and tolerates cross-process writers).
Handle three cases: id already present (no-op, or apply valid_to if the
incoming record is an invalidation), same active (subject, predicate, object)
present under a different id (map it, do not insert a duplicate fact), and
absent (insert verbatim). Invalidations are just valid_to updates, which
also means a timestamp watermark misses them; the KG tables are tiny, so
full-scan and diff instead.

Content updates. update_drawer changes content in place without
touching filed_at, so a watermark exporter never sees it. Carry a content
hash in every journal record and run an occasional "deep" export pass that
re-emits rows whose hash changed; importers apply those as updates
(last-write-wins on export time).

A semantic guard is worth having. Two machines sometimes file the same
fact independently with different wording (different content hash, different
id). On import, run the equivalent of mempalace_check_duplicate (a vector
query) for human-authored records and skip anything above ~0.9 similarity.
Log the skips instead of dropping them silently so you can audit false
positives.

Preflight before every run. Check: git remote reachable; peer machines
publish the same embedding_model and mempalace version (compare via the
state/*.json snapshots); hnsw_capacity_status is not DIVERGED (if it is,
keep exporting, because sqlite is exactly the ground truth in that state, but
skip importing and alert); PRAGMA quick_check is clean. Fail loudly into
the state file so the other machines can see a sick peer.

Operational shape

• One deterministic Python script (stdlib + mempalace imports only) with
  subcommands: setup, export [--bootstrap|--deep], import, sync,
  forget, status. The script lives inside the sync repo itself, so
  git pull at the start of each run self-updates the tooling fleet-wide.
• A sync run is: preflight, pull --rebase, apply tombstones, import peers
  from saved line offsets, export own new records since watermark, publish
  state snapshot, commit and push (retry pull --rebase on push races; per-
  machine files mean the race is only ever non-fast-forward, never a content
  conflict).
• Schedule it daily per machine with staggered start times (a per-user
  Task Scheduler time trigger needs no elevation on Windows; cron elsewhere).
  Memory rarely needs fresher than daily; run it manually when it does.
• Adding machine N: clone, register the machine name, import everything
  (expect it to take about as long as a large mine, since it re-embeds),
  export --bootstrap its own history, schedule. Roughly 15 minutes of
  hands-on time.

At my scale (about 9,000 drawers, two machines) the bootstrap export is
around 10-15 MB of JSONL and the daily incremental is trivial. Everything
month-shards, so no journal file grows unbounded.

Verify before you trust it

Write a test harness before pointing it at a second real machine. Mine runs
against the live palace with a scratch repo and asserts: export emits exactly
the new drawer and re-export emits nothing; a simulated peer journal imports
and is findable via search; imported records are never re-exported (echo);
double import leaves the drawer count byte-stable; a tombstoned id stays dead
even through a forced re-import; the semantic guard skips a near-duplicate;
KG ids survive round-trip including invalidation replay; and, with a second
process deliberately holding the palace lock, the importer backs off and
completes cleanly with repair-status still OK afterwards. All fixtures
delete themselves. Seventeen assertions, no second machine required.

Limitations, honestly

• Eventual consistency on your chosen cadence (daily by default). This is a
  memory system, not a database; that has been fine in practice.
• hallways.json is derived from drawer co-occurrence and rebuilds itself;
  manual tunnels are not synced in v1.
• Add-only means a drawer edited on one machine propagates only via the deep
  pass, and two machines editing the same drawer resolve last-write-wins.
• The journal repo contains your memories verbatim. Keep it private, and
  understand that "private GitHub repo" is a trust decision you are making.
  Any git remote works (a self-hosted one, a bare repo on a NAS you can
  reach from everywhere), the mechanics do not care.

If the maintainers ever ship native export/import (#452) or an SSE server
mode (#1646), migration is easy precisely because everything here is plain
JSONL with original ids. Until then, this has been robust for me. Happy to
answer questions.

[Ev3lynx727]

I hit the exact same question running across WSL and Windows. Ended up swapping the local ChromaDB backend for Neon PostgreSQL — works for multi-machine sync since both instances hit the same Postgres database. The embedding model runs locally on each machine so only the vector store needs sharing. There is a mempalace-neon migration guide covering the steps.

[Ev3lynx727]

Let me expand with a more concrete setup since you mentioned cross-VM.

The setup I would run:

1. Proxmox LXC running the mempalace Python stack (embedding + store) in a privileged container with enough RAM for sentence-transformers
2. Neon PostgreSQL as the shared vector store — ChromaDB's local DuckDB backend is replaced with asyncpg pointing at Neon. The embedding model stays local to each machine (same all-MiniLM-L6-v2, same vectors). Only the vector index and document store live in Postgres
3. HTTP exposure — run pgBouncer or postgrest inside the LXC, expose on your LAN bridge
4. Tailscale — install on the LXC and each client machine. WireGuard mesh with mTLS means your Postgres connection goes over 100.x.x.x:5432 — no open ports, no cert management
5. Two VM approach — mempalace server on VM1 (writer), VM2 queries via HTTP or direct Postgres read-replica. Both authenticate through Tailscale ACLs

The key insight: ChromaDB's embedding step is the expensive part (GPU/CPU), the vector store is just a Postgres table with pgvector. Keep embeddings local, share the store. Tailscale makes the shared store as safe as localhost.

[et1975]

Doesn't answer life-sync question, but I have backup/restore/export/import skills now, I think sync can be added.