* chore(release): v0.9.29 with project-scope parity across surfaces Version trio + plugin manifests + supportedVersions + ExportData union bumped to 0.9.29; CHANGELOG entry covering everything since v0.9.28 with upgrade notes for the four visible behavior changes. Fixes the endpoint-count drift on main (130 registered routes vs docs saying 129 after #1132 landed in parallel with #1136). Project-scope parity: OpenCode plugin, Hermes plugin, Pi extension, and JSONL replay now resolve project the same way the hooks do (env override, git toplevel basename, cwd basename) instead of sending raw filesystem paths, closing #903 and #1135 and pre-empting the same bug in pi. The filesystem watcher accepts AGENTMEMORY_PROJECT_NAME with the old AGENTMEMORY_PROJECT kept as a deprecated alias, replay handles Windows-recorded paths, and OpenCode file enrichment matches the agent's lowercase tool names (the capitalized set never matched). Tests: opencode fallback expectations updated to basenames per the canonicalization, git-toplevel resolution covered with a fixture repo, new project-scope-parity suite for replay and fs-watcher. * fix(release): review findings, git-toplevel parity, doc counts - skills generator dedupes routes on method plus path, so the REST reference lists all 130 registered routes instead of hiding the second method on ten dual-method paths (header said 119) - fs-watcher trims AGENTMEMORY_PROJECT_NAME and the deprecated alias, treating whitespace as unset, and derives the git toplevel basename when watching a subdirectory - replay resolves the git toplevel basename when the recorded cwd still exists locally (memoized per cwd), keeping the basename fallback for historical or cross-platform paths; no env override here since a bulk import spans many projects - parity tests for replay git-root resolution, watcher git-root and trim behavior - stat-tests badge updated from 1428+ to 1550+ passing * fix(cli): refuse second-instance boot over a live daemon Closes the class behind issue 1140: agentmemory consolidate (or any unrecognized word) fell through the command table into the full server boot, registering a duplicate worker on the running engine; on iii 0.11.2 the second instance's shutdown tears down the daemon's HTTP trigger routing until a full engine restart. Unknown subcommands now error with the supported list, and main() probes livez on the resolved port and refuses to boot over a live daemon, so multi-instance setups on other ports are unaffected. Verified behaviorally against the built CLI: both paths refuse with exit 1. Also from review: the watcher stamps each event with its own root's project via a per-root map (an explicit config.project still overrides for every root), and replay only accepts a non-empty string cwd from parsed JSONL so malformed entries cannot reach the filesystem probe. * test(watcher): two-repository flush events scope to their own project * chore(release): bump packages/mcp, guard it, refresh CONTRIBUTING packages/mcp was still 0.9.28 after the release bump because nothing guarded it; a consistency test now pins it to package.json. CONTRIBUTING release list corrected to the files a bump actually touches (no tracked lockfile, the two extra plugin manifests, the export test derives from VERSION now), and the subsystems table gains src/cli, integrations/pi, and the generated-manifest note. * fix(export): refuse over-frame export instead of dropping the worker Closes the availability bug in issue 1142: GET /agentmemory/export assembles the full store and returns it through sdk.trigger, so a store whose serialized export passes the engine's 16 MiB WebSocket frame (tungstenite max_frame_size, not raisable under the 0.11.2 pin) dies on the worker->engine hop, drops the worker, and 404s every endpoint for ~1s. The session collections page on maxSessions/offset but ~18 others do not, so a large store hits this at any parameter combination. A shared frame-guard measures the serialized size before returning: mem::export returns a small oversized error instead of the giant object, and api::mesh-export returns 413 (same dead-end as #890). Either way the over-frame payload never crosses the boundary, so the daemon stays up and the failure is one clean request with a hint to narrow the range. Full pagination of the non-session collections is a follow-up. Layer 1 of the fix; verified with a synthetic oversized export returning the error object (tiny) rather than the payload. * ci: collapse to a single npm install to fix Node 24/26 CI The two-step install (npm install --package-lock-only then npm ci) failed only on the Node 24/26 matrix rows: their stricter npm rejects rolldown's optional platform bindings (@rolldown/binding-android-arm64) that a --package-lock-only pass does not fully enumerate. Lockfiles are gitignored, so npm ci re-validation buys no reproducibility here. A single lenient npm install resolves and installs in one pass. * fix(mesh): scope exported memories by project like actions api::mesh-export filtered actions by ?project but returned every project's memories. On a mesh instance federating one project to a peer, the peer pulled other projects' memories (cross-project leak), and those extras could push the payload past the 16 MiB transport frame into a 413 even when the requested project's own slice fit. Memories carry the same optional project field as actions, so filter both before the frame-size guard runs. Adds a regression test asserting a project-scoped export excludes other projects' memories and that an oversized memory in another project no longer 413s the scoped request. * chore(release): credit the Antigravity native hooks adapter in 0.9.29 notes * chore(release): sweep stale 0.9.28 refs for 0.9.29 Deploy Dockerfiles/compose/render pins, AGENTS.md stats header, opencode plugin manifest, website meta snapshot, test-count claims (1,428 -> 1,596) in README/AGENTS/stat SVGs, and the missing 0.9.29 CHANGELOG compare link. * chore(release): sync stat-tests badge to 1596+ and commit bridge exec bit * refactor: trim frame-guard comments and drop issue refs from code
Deploy agentmemory on Coolify
Coolify is an open-source, self-hosted Heroku/Render alternative that you run on your own VPS. This template deploys agentmemory as a Coolify Application backed by a Docker Compose stack — Coolify handles TLS termination, persistent volume provisioning, log aggregation, and the deploy webhook for you.
What you get
- A public HTTPS endpoint serving the agentmemory REST API behind
Coolify's built-in Traefik/Caddy proxy. The container port (
3111) is exposed to the proxy network only — never bound to the host — so TLS termination and domain routing stay under proxy control. - A persistent Docker volume backing
/datafor memories, BM25 index, and stream backlog. Coolify auto-prefixes the volume name with the application's UUID so the data survives redeploys. - An HTTP health-check at
/agentmemory/livezdeclared in the Dockerfile (HEALTHCHECKdirective). Coolify reuses it for rolling-deploy decisions.
One-time setup
- Open your Coolify dashboard and click + New → Application.
- Source: pick Public Repository. Paste:
Branch:
https://github.com/rohitg00/agentmemorymain. - Build Pack: select Docker Compose.
- Base Directory:
deploy/coolify - Compose Path:
docker-compose.yml - Click Save, then on the application settings screen set a
Domain in the form
https://<your-fqdn>:3111(the:3111suffix tells Coolify's proxy which container port to forward to; it still serves over 443/80 publicly). - Click Deploy.
That's it. Coolify clones the repo, builds the Dockerfile under
deploy/coolify/, provisions the agentmemory-data named volume on
the host, attaches Traefik (or Caddy) for the public domain, and starts
the service. The container is reachable only through the proxy — there
is no published host port.
Capture the HMAC secret
Once the deploy logs show the service is up, open the application's
Logs tab in Coolify and search for AGENTMEMORY_SECRET=. You will
see exactly one line of the form AGENTMEMORY_SECRET=<64 hex chars>.
Copy it into your client environment (~/.bashrc, Claude Desktop
config, etc.). The secret is never printed again on subsequent boots.
Verify the deployment
curl "https://<your-coolify-domain>/agentmemory/livez"
# {"status":"ok"}
For an authenticated call, your client must send
Authorization: Bearer <secret>.
Viewer access (port 3113 stays internal)
The viewer port is not exposed by the compose file on purpose — it holds the unauthenticated admin surface in older releases and the proxied surface in current ones, neither of which belongs on the open internet. Two paths to reach it:
Option A — SSH tunnel from the Coolify host. Coolify gives you SSH access to the underlying VPS. From your laptop:
ssh -L 3113:127.0.0.1:3113 <user>@<coolify-host>
# inside the SSH session, find the container:
docker ps --filter name=agentmemory --format "{{.Names}}"
# tunnel into the container's port from the host:
docker exec -it <container-name> sh -c "curl http://localhost:3113"
Cleaner version: bind the container's 3113 to the host's loopback by
adding - "127.0.0.1:3113:3113" to the ports: block in
docker-compose.yml, redeploy, then ssh -L 3113:127.0.0.1:3113 <user>@<host> is enough.
Option B — expose 3113 as a second Coolify domain protected by HTTP basic auth. Coolify's per-service routing supports adding a second public endpoint with basic-auth middleware. Useful if you want to share the viewer with a teammate without giving them SSH.
Rotate the HMAC secret
ssh <user>@<coolify-host>
docker exec -it <container-name> sh -c "rm /data/.hmac"
exit
Then click Redeploy in the Coolify dashboard. The next boot prints a fresh secret to the logs.
Back up /data
Coolify exposes the named volume on the host filesystem under
/var/lib/docker/volumes/<project-id>_agentmemory-data/_data. Back it
up with your existing host-level snapshot tooling (Restic, Borg,
rsync, BTRFS snapshots, etc.) or via Coolify's built-in Backups
feature for Docker volumes.
Cost floor and resources
- Hardware: the agentmemory container idles at ~150 MB RSS, climbs to ~400 MB under steady traffic. The bundled iii engine adds another ~80 MB. A 1 vCPU / 1 GB VPS is comfortably enough for a personal install.
- VPS providers commonly paired with Coolify: Hetzner CX22 (~€3.79/month), DigitalOcean Basic Droplet ($6/month), Vultr Cloud Compute ($6/month). Coolify itself is free.
- Volume storage: tied to whatever block storage the VPS provides; typically pennies per GB-month.
Known caveats
- The Dockerfile builds on the Coolify host on every deploy. First
deploy takes ~2 minutes; cached layers shrink subsequent rebuilds to
under 30 seconds. Pin
AGENTMEMORY_VERSIONandIII_VERSIONindocker-compose.yml'sbuild.argsblock to lock a specific release. - Coolify's Persistent Storage tab will show
agentmemory-dataas a managed volume — do not delete it from the dashboard if you want your memories to survive a redeploy. - arm64 hosts work — the iii binary selection in the Dockerfile uses
uname -mand downloads the matching tarball.