Setting up AgentMemory on a remote server as centralized memory service

[Rex57]

@rohitg00 I’m running AgentMemory on a remote server as a centralized
memory service for my team. Multiple clients connect to the same server
through the REST/MCP setup.

I wanted to ask whether there are plans to make this workflow more
native/easier for team use. A few things we are trying to handle:

1. Multiple users/clients working against the same shared AgentMemory
   server.

2. Each user/client having a distinct identity, so memories and sessions
   can still show who created them.

3. Multiple local checkouts of the same repo mapping to the same project
   in AgentMemory.

The main issue is project/session naming. Different team members may
have the same repo in different paths or folder names, so AgentMemory
can treat them as different projects even though they are the same
codebase.

Right now we are solving this by setting a per-repo env var with direnv:

AGENTMEMORY_PROJECT_NAME=our-shared-project-name

This works, but it requires every client to configure the same value
manually for each repo.

Is there any plan or recommended approach for this use case? For
example, something like deriving the project name from the Git remote/
repo name, or a native team/shared-project config so all clients
automatically map to the same AgentMemory project while still keeping
distinct user IDs.

[173787247]

Your AGENTMEMORY_PROJECT_NAME=our-shared-project-name + direnv is the right team workaround today. Path-based project ids will always split the same git repo across laptops.

Recommended approach (without waiting on a new feature)

1. Project key = git identity, not folder name.
   Canonical: git remote get-url origin (normalize: strip .git, lowercase, prefer github.com/org/repo over SSH vs HTTPS variants). Put that string in AGENTMEMORY_PROJECT_NAME (or whatever the client uses for project slug).
2. User identity ≠ project. Keep a per-developer AGENTMEMORY_USER / token so sessions stay attributable. Shared project + distinct user is the correct split.
3. Check in the project name so direnv isn’t tribal knowledge:
   • .envrc with the slug, or
   • a tiny .agentmemory.json ({"project": "org/repo"}) committed at repo root. Then every checkout maps the same way even if the folder is repo, repo-2, or D:\work\repo.
4. Multiple local checkouts: same committed slug → same project. That’s what you want.

Native “team server” extras that are still missing

Authn between MCP clients, ACLs, and “derive project from remote automatically” would be product work. Until then, committed project slug + remote server URL is the whole design; don’t try to make the server guess from cwd.

If the server already has a project-create API, have onboarding docs: “set these two env vars, commit the slug file.” That’s enough for a small team.

[rohitg00]

Hi @Rex57, v0.9.30 covers part of this.

Auth is on by default now: the server generates a secret into ~/.agentmemory/secret, and a remote deployment sets an explicit AGENTMEMORY_SECRET that every client sends as a bearer token. Writes from browsers need an allowed origin (VIEWER_ALLOWED_ORIGINS), and the deploy templates under deploy/ (fly.io, Railway, Render, Coolify) ship with this wiring.

Identity: agentId threads through every save path and the MCP memory_save schema, TEAM_MODE=shared with TEAM_ID and USER_ID scopes records per user, and every record carries its origin channel. For several daemons, state can live in one Redis per instance (AGENTMEMORY_STATE_BACKEND=redis).

Project naming is still AGENTMEMORY_PROJECT_NAME per checkout, as in the earlier reply; deriving the project key from the git remote instead of the path is what #1363 proposes and it is under review.

[rohitg00]

One addition for 0.9.32: hooks send nothing to a remote http:// server. A non-loopback AGENTMEMORY_URL must use HTTPS, and the secret is only sent to loopback or HTTPS addresses. The Claude Code plugin now asks for the server URL and secret in its settings. Each release is also published as ghumarerohit/agentmemory:<version> on Docker Hub for server deployments. Closing as answered.