Multi-device memory

Two ways to run Sigil on more than one machine. They solve different problems.

	Shared database	Device pairing
How	Every install points at the same Postgres	One master holds the data; followers dial it over Iroh
Needs	A Postgres reachable from every machine	Only the master needs a database
Access control	None — the connection string is the key	Per-device roles and namespace grants, revocable
Best for	Your own machines, managed Postgres	A device you don’t fully trust, or one that can’t reach your DB

Start with the shared database. Pairing is the answer when you need revocable, scoped access.

Shared database

There is no protocol. Point two installs at the same Postgres and they share one brain.

Managed Postgres

# on every machine
sigil init --url "postgres://user:pass@ep-foo.neon.tech/sigil?sslmode=require"

Self-hosted on your LAN

sigil init
# choose "Local / Docker", host: postgres.your-network.local

From the dashboard

Settings → Change database → paste the connection URL. It tests, migrates, and restarts the daemon for you.

The second machine runs migrations, finds the schema already current, and starts reading. A fact captured on your laptop surfaces in the next prompt on your server. Consistency is whatever Postgres gives you, which is plenty for personal memory.

Not the embedded database

PGlite runs in-process against ~/.sigil/db. It cannot be shared. If you set up with the built-in database and later want multi-device, migrate to a real Postgres first — export, re-init with a URL, and re-ingest. See Backup and restore.

What this unlocks

• Laptop and desktop. One memory, no manual sync.
• Local dev plus a cloud agent. A triage agent on a VPS writes “fixed prod issue X by patching Y”; your morning prompt already knows.
• Multi-agent workflows. Claude Code, Codex, and a custom agent all hitting the same brain, each write attributed to the agent and device that made it.

Namespaces across installs

By default each install reads only its own namespace. When two installs deliberately write under different namespaces but should still see each other:

defaults.searchNamespaces = ["*"]        # or an explicit list

Set it in Settings → General, or per-query with --all-namespaces.

Device pairing

Pairing gives one machine (the master) the database, and lets other devices reach it over an encrypted peer connection — with a role, an expiry, and a revoke button.

On the master

sigil pair create --name laptop-b --role writer --ttl 600

Pairing code created — share this with "laptop-b":

  code:          7Q2K-9FMD-XR41
  master nodeId: k51qzi5uqu5d...
  role:          writer
  namespaces:    (all)
  expires at:    2026-08-14T17:12:00Z

On the joining device, run:
  sigil join k51qzi5uqu5d... 7Q2K-9FMD-XR41 --name laptop-b

The plaintext code is printed once and never stored. Hand it over out of band.

Role	Grants
reader	Read-only — search, status
writer	Read and write — remember, ingest (default)
admin	Full access, including device management

Restrict which namespaces a device can touch with --ns:

sigil pair create --name ci-runner --role reader --ns engineering --ttl 300

On the joining device

sigil join <master-node-id> <pairing-code> --name laptop-b

Iroh resolves the master’s transport details automatically. Override them when you need to:

sigil join <node-id> <code> --addresses 10.0.0.5:4433 --relay https://relay.example
sigil join <node-id> <code> --lite     # lite-follower: proxy everything, store nothing locally

Joining flips this install’s network mode to follower (or lite-follower) and records the master’s node id.

Managing devices

sigil pair list           # outstanding codes
sigil pair revoke <id>    # kill a code, or a paired device

The dashboard’s Devices screen shows the same thing with pending codes, roles, and last-seen times.

Device-scoped facts

Some facts are true on exactly one machine. A local path, a port number, a piece of hardware. Sharing them across devices makes memory actively wrong.

sigil visibility <fact-id> device    # only the machine that wrote it
sigil visibility <fact-id> shared    # everywhere (the default)
sigil visibility <fact-id> agent     # only the agent that wrote it

Sigil’s extractor scopes obvious cases on its own. visibility is the correction. Changes take effect on the next read, on every device.

See Provenance and visibility.

Write attribution

Every fact records which agent and which device wrote it. That’s what makes a shared brain debuggable rather than a soup — the dashboard’s Activity screen filters by agent, and sigil why shows the pods a fact came through.

Choosing a database for multi-device

	Good	Watch out for
Neon	Serverless, generous free tier, pgvector one click	Cold starts on the free plan add latency to the first search
Supabase	pgvector preinstalled, easy	Connection limits on small plans
Self-hosted on a VPS/NAS	No third party, no limits	You operate it, and every device needs to reach it
RDS / Cloud SQL	Boring and reliable	pgvector needs a parameter group change

Whatever you pick: use sslmode=require, and treat the connection string as a credential. It is the only thing standing between someone and your entire memory.