Self-Hosted Memory for AI Agents: What It Takes

Posted on Nov 3 • Originally published at contextforge.dev

Originally published on contextforge.dev.

Self-hosted memory for AI agents sounds like a database problem, and the database turns out to be the easy part.

I know because I went the other way. I build ContextForge, a memory layer for Claude Code, Cursor and Copilot, and I run it as a hosted service. The MCP server you install is open source. The storage behind it is not something you can run on your own machine today. Every few weeks someone asks me, politely, why not. This post is my honest answer, including the cases where you should not use what I built.

Strip away the vendor language and an agent memory does three jobs:

Any option below that does only the first job is a notes folder. That's fine, as long as you call it that.

CLAUDE.md,.cursorrules, a docs/decisions/ folder. Zero infrastructure, versioned with the code, readable by every tool and every teammate who clones the repo.

This is where most people should start, and where I started. It fails in two predictable ways. Nothing recalls by meaning; the agent reads what fits in context and skips the rest. And nothing flags staleness; the file says whatever it said the day someone last edited it. I wrote about cursor rules versus persistent memory if you want the long version.

The Model Context Protocol made this practical. A memory server is a small process your tools talk to over MCP, so Claude Code, Cursor and Copilot can all read and write the same store without custom plugins. The reference memory server from the MCP project keeps a knowledge graph in a JSON file on disk. Open-source projects like Mem0 and Graphiti can run fully local too, with your own vector store underneath.

What you get: one memory across tools, on your machine, with no account anywhere. What you don't get, out of the box: anything on your second laptop, anything for your teammate, backups, or a way to tell a stale note from a fresh one. It is memory for one person on one computer, and for a lot of developers that is exactly the right size.

The serious version. Postgres with pgvector, an embedding model running on Ollama so nothing leaves your network, a thin MCP server in front, and a job that watches git so notes tied to changed files get flagged. Now it works across machines and across people, because it's a service.

That last word is the cost. You now own uptime, auth, backups, migrations, and the Saturday when the embedding model changes and every stored vector needs recomputing. None of it is hard. All of it is time you are not spending on the product you were trying to build. I know this because that service is, roughly, what I ended up building and hosting for other people.

You install an MCP server, point it at an account, and the storage, search, freshness checks and team access are someone else's job. That's ContextForge, and it's also Mem0's platform and a handful of others. The trade is obvious: your decisions live in a database you don't control.

Here's the honest version, since the original draft of this post (written by a model, reviewed by me) claimed you could clone ContextForge and run it on your own server. You can't, and I'd rather correct that in public than let it stand.

Self-hosting is on my list. It isn't next, because the people writing to me are mostly stuck on jobs two and three, not on where the bytes live. If that's wrong for your case, tell me; those emails are how the list gets reordered.

Whatever you pick, the thing that decides whether it works is not the storage. It's whether anyone writes to it. A memory nobody saves to is empty in every architecture.

Is a vector database the same as agent memory? No. It's the index. Memory also needs a write path the agent actually uses, metadata that ties notes to files and commits, and some way to detect staleness. Most self-hosted setups stop after the index.

Can I self-host ContextForge? Not today. The MCP server is open source; the storage and search are hosted. If that rules it out for you, a local MCP memory server or Postgres with pgvector will do the job with more work on your side.

Does self-hosting make the memory more accurate? Not by itself. Accuracy comes from what gets saved and whether stale notes get caught. Hosting changes who operates the system, not what it remembers.

One command, in the repo you're working on:

npx contextforge-mcp init Enter fullscreen mode Exit fullscreen mode It links the folder to a project so every agent in that repo shares the same memory, and adds the hooks that reload context after Claude Code compacts. Then, when something worth keeping happens, say it plainly: "Save to ContextForge: no automatic retries on the payment webhook, they double-charged customers." The next agent that touches that webhook, in whichever tool, will hear about it.

And if your answer to the data question is "it has to stay here", go build option 3. It's a good weekend. Just budget for the Saturdays after it.