Self-Hosted Memory for AI Agents: What It Takes

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.

What "memory" has to do before it counts

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

1. Save a decision with its reason. "We use GraphQL for the API layer" is a fact. "Because the mobile screens needed a dozen REST calls each" is the part that stops the next agent from reopening the question.
2. Recall by meaning, at the right moment. Not a keyword grep. The agent working on payments/webhook.ts should get the note about the double-charge bug without knowing it exists.
3. Notice when it goes stale. Someone renames the file the note talks about. If the memory doesn't know, every agent that reads it is working from an old map. Static files have the same problem, just slower.

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

The four ways to self-host it

1. Files in the repo

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.

2. A local MCP memory server

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.

3. Your own Postgres plus embeddings

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.

4. Hosted

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.

Where ContextForge fits, and where it doesn't

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.

What you can do today:

• The MCP server (contextforge-mcp, MIT) is open source. You can read every line of what runs on your machine.
• It gives one memory to Claude Code, Cursor, Copilot, Claude Desktop and Windsurf, with a free tier that's enough to find out whether it changes how you work.
• It does job three. Memories link to files and commits; when the code moves, the agent is told the note may be outdated and can confirm, correct or forget it.
• Git integration pulls commits and PRs in as context, so "why did we do this" has the diff next to it.

What you can't do today:

• Run the backend yourself. Your memories are stored in our database. If your contract or your compliance team says project decisions cannot leave your network, ContextForge is the wrong tool for you right now, and option 2 or 3 above is the right one. I'd rather say that here than have you find out after setup.
• Bring your own embedding model. Search runs on our side.

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.

How to choose

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.

FAQ

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.

If you want to try the hosted path

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

npx contextforge-mcp init

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.