Run as a server

Run as a server

Host dm-lite somewhere central, a VPS, a homelab box, or a cloud instance, so your machines, your agents, and your team share one memory. The same binary serves many tenants over HTTP(S), one bearer token per tenant, with TLS built in (no reverse proxy assumed). Once it is running, connect to it from anywhere with the steps in "Run as a client".

Start it

export DM_TOKEN_ACME=<secret>          # this token maps to tenant "acme"

dmem serve --addr 0.0.0.0:8077 --tls-generate                          # self-signed cert (saved under the data dir)
dmem serve --addr 0.0.0.0:8077 --tls-cert cert.pem --tls-key key.pem   # your own cert
dmem serve --addr 127.0.0.1:8077                                       # plain HTTP (local only; warns)

curl -sk https://localhost:8077/healthz
curl -sk -X POST https://localhost:8077/recall \
  -H 'authorization: Bearer <secret>' \
  -H 'content-type: application/json' \
  -d '{"query":"vector store","limit":5}'

Each tenant gets its own database file. Routes mirror the local tools: POST /recall /recent /history /forget /remember /invalidate /log_decision /log_lesson /log_incident /log_runbook /log_convention /add_reminder /import /persona /reminders /latest_save, plus admin routes and an open GET /healthz.

Run it as a managed service

Run dmem as a login service (launchd on macOS, systemd --user on Linux) instead of dmem serve in a terminal. It starts on login; stopping it reclaims the model's RAM.

dmem service install     # write the unit + [server] block, then start it
dmem service status
dmem service stop
dmem service start
dmem service restart
dmem service uninstall

install also points this machine's config at the daemon, so the CLI and agent hooks become thin clients of the running process (server and client on one box).

Multitenant admin (token-only, no passwords)

On first start the server generates a root admin token (no tenant, no memory), prints it once, and writes it to <data>/admin.token (0600). The admin creates tenants and issues one-time tokens; each token isolates one tenant's memory.

dmem login https://server:8077 <admin-token>   # wire the admin token once
dmem admin add acme --label laptop             # creates the silo + prints a one-time member token
dmem admin list
dmem admin revoke <token|tenant>
dmem admin rm <tenant>

The admin hands the member token to the user. There are no passwords: the token is the credential and the isolation key. A lost token is revoked and reissued. DM_TOKEN_<tenant> env vars also work as a quick static fallback.

Per-agent identity tokens

Several agents can share one tenant's memory while each keeps its own identity: a token can carry an agent label.

dmem admin add acme --agent izu       # mint a member token that identifies as agent "izu"

export DM_TOKEN_ACME__IZU=<secret>    # env form; the first double underscore splits tenant from agent

Single underscores stay part of the tenant name, and DM_TOKEN_ACME remains the agent-less form, unchanged. The server fails fast at startup if one secret maps to two identities (different tenant or different agent), since a nondeterministic match would corrupt attribution.

An agent-labeled token changes two things:

• Persona: the caller is served the shared governance records plus its own agents/<agent>/... persona, never another agent's. See "Persona and governance".
• Attribution: every typed write through that token is stamped with an author:<agent> tag. The first attribution wins (a re-save through another path never re-assigns it), and imports are left unstamped on purpose.

Agent-less tokens keep the full legacy behaviour, so an existing setup is unaffected until you opt in.