server-noonien

server-noonien

Shared, serverless, conflict-free memory for AI agents — with peer-to-peer sync.

server-noonien is a drop-in replacement for the official @modelcontextprotocol/server-memory knowledge graph — the same entities, observations and relations — that converges across machines with no central server, no database and no merge conflicts.

Its headline feature is peer-to-peer sync: the nooniend daemon replicates each node's shard directly to the others, so several machines share one memory with no shared folder — only IP reachability over a VPN or a LAN.

Table of contents

• Why server-noonien
• The problem
• How server-noonien solves it
• Comparison
• The three commands
• Share across machines
• Peer to peer — nooniend (recommended)
• The daemon HTTP API
• Shared area — file and s3
• Configuration
• Shared variables
• Server variables
• Daemon variables
• How it works
• Compaction
• Deletion and collection
• Tools
• Drop-in compatibility
• Security
• Development
• Why the name noonien?
• Documentation
• License & Disclaimer
• Support the Project

Why server-noonien

The problem

Agent memory today is local, and the official memory server is a single JSONL file that every mutation reads and rewrites in full. That breaks the moment you have more than one machine:

• It lives on one host. Switch machine and your agent has forgotten everything.
• Sharing it over a synced folder loses writes. The server serializes mutations *in-process only*: two hosts each load the whole graph, mutate their own copy and write it back, so the last write silently discards the other's — and the sync tool forks the file into conflict copies instead of merging it.
• The alternatives want a server, a database or a cloud. The mainstream "shared memory" products are something you have to host, or they ship your memory off your machines.

How server-noonien solves it

server-noonien removes the shared file and the central server at the root, and keeps the drop-in tool surface:

• Every node keeps its own memory. Each machine writes only its own append-only shard ( .jsonl); a shard has a single writer by design, so no two nodes ever write the same file and noonien itself never forks one — a shared area's syncer still can, and a conflict copy is just another shard to fold.
• Shards merge, they do not overwrite. The graph is a CRDT — an LWW-Element-Set ordered by (HLC, node, sequence) — whose merge is idempotent, commutative, associative and convergent. Any two machines that have seen the same operations hold the identical graph, in any order, so there is no "last write wins" data loss.
• No shared area, no central server. The shards travel directly between machines with the nooniend daemon — only IP reachability, over a VPN or a LAN — so several machines share one memory with no shared folder and no service to host. Prefer a folder or a bucket you already have? file and s3 work too: the transport is a choice, not a lock-in.
• Local-first and offline-friendly. Every node reads and writes its own shard on disk and keeps a full local replica, so it keeps working offline; the mesh reconverges when the network returns.
• Drop-in for the official server. The same nine tools, inputs and outputs, so it slots under the memory server name with no agent changes — plus the update_*, merge_entities and read_conflicts extensions, the operations the official nine have no equivalent for.

Comparison

server-noonien vs the official memory server vs hosted memory services:

Hosted is a category, not a product: it covers services that host your memory for you. server-noonien is the local-first opposite — you own the storage and there is no account.

A shared area is required for the file/s3 backends — a folder or an object store every node can reach. nooniend removes that requirement: it replicates the shards directly between nodes.

The three commands

One npm package, `server-noonien`, ships three commands (Node.js ≥ 22). Install it once and all three land on your PATH:

npm install -g server-noonien

The s3 backend's @aws-sdk/client-s3 is an optional dependency, loaded only when NOONIEN_BACKEND=s3 selects it. npm install -g server-noonien --omit=optional skips it when you never use s3.

Only server-noonien matches the package name, so it is the only command npx can run by package name. Run the other two with --package, or from the global install above:

npx -y server-noonien                       # the MCP server (no argument serves over stdio)

npx -y -p server-noonien noonien help # the maintenance CLI npx -y -p server-noonien nooniend # the replication daemon

From a clone — for development, or to run code not yet on npm:

git clone https://github.com/sequico/server-noonien.git

cd server-noonien && npm install && npm run build

node dist/index.js # server-noonien — the MCP server node dist/noonien.js # noonien — the maintenance CLI node dist/gossip.js # nooniend — the replication daemon

server-noonien — the MCP server

The entry every MCP client uses. With no argument (or serve) it speaks MCP over stdio, so you don't run it yourself — the client spawns it and it lives for the session:

npx -y server-noonien                          # the stdio command the client runs

claude mcp add memory -- npx -y server-noonien # register it with Claude Code as the memory server

Point your client at it; it works on one machine out of the box, and sharing across machines is the next step. In OpenCode (V2):

{

"$schema": "https://opencode.ai/config.json", "mcp": { "servers": { "memory": { "type": "local", "command": ["npx", "-y", "server-noonien"], "environment": { "NOONIEN_DIR": "~/.noonien" } } } } }

Other clients wrap the same command and environment in their own envelope; from a clone the command is ["node", "/path/to/server-noonien/dist/index.js"]. Because the nine drop-in tools are identical, you can replace the memory server entry with server-noonien and change nothing else.

noonien — the maintenance CLI

nooniend — the daemon

A long-lived service, one per machine, that replicates the shard directory peer to peer. It takes no arguments and is configured entirely through environment variables — the shared NOONIEN_DIR and NOONIEN_NODE_ID (Shared variables) plus the daemon's NOONIEND_* (Daemon variables). See Peer to peer for the setup.

Share across machines

noonien merges shards; it does not move them by itself. How the shards travel between machines is your choice: peer to peer (a companion daemon — the recommended default) or a shared area (a folder or a bucket that already exists). The MCP server always reads and writes its own local shard; only the transport differs.

Peer to peer — nooniend (recommended)

The recommended way to share one memory across machines with no shared storage. nooniend is a long-lived daemon that replicates the local shard directory peer to peer. It only needs IP reachability, so it runs over any VPN (WireGuard, Tailscale, OpenVPN, Netbird, ZeroTier, …) or a plain LAN.

Give each machine a unique node id and run one nooniend per machine. Every daemon keeps a full replica of the others' shards beside its own, in the same local directory the MCP server uses — no shared folder required:

# on a tailnet

NOONIEN_DIR=~/.noonien \ NOONIEND_TAILSCALE=true \ nooniend

or, with no self-listing underlay, seed one reachable peer

NOONIEN_DIR=~/.noonien \ NOONIEND_PEERS=ai.example:49778 \ nooniend

The peers find each other — you never list the machines. Configure one discovery source: NOONIEND_TAILSCALE (from tailscale status), NOONIEND_DNS_SRV (the _nooniend._tcp SRV records), or NOONIEND_PEERS (a static seed; one is enough, membership then self-propagates). A discovery source returns candidates, not members: a candidate joins only once it answers /info, so a machine on the network that does no