Self-Hosted vs. Cloud AI Memory: Where Should Yours Live
Cloud AI memory — like ChatGPT's Memory feature or Claude's Memory — lives on the provider's servers, under their retention schedule and their terms of service. Self-hosted AI memory lives on a machine or database you control, so you decide how long it's kept and who can read it. The right choice depends on whether you value convenience or control more, and the two aren't mutually exclusive — tools like open-context let you run the same memory model either way.
Key takeaways
- ChatGPT's Memory feature stores extracted memories separately from chat history and keeps them until you clear them manually — deleted memories can persist up to 30 days for safety review.
- GDPR's Article 20 data portability right only covers data you directly provided, not what a model inferred about you, and there's no standard format or destination to move it to.
- Self-hosted AI memory puts retention and deletion entirely in your hands, instead of a provider's changing privacy policy.
- open-context's MCP server defaults to a local JSON file but supports 15 database backends (BYODB), so "self-hosted" can mean a laptop file or a company Postgres instance.
- Cloud memory generally wins on zero-setup cross-device sync; self-hosted wins on control, auditability, and no vendor lock-in — and a networked backend gets you sync too.
Two different things called "AI memory"
"Memory" gets used loosely, but Claude and ChatGPT actually separate two concepts: a fixed set of instructions you write once (Claude calls this Preferences, a system-prompt-style block), and a running summary the model writes and updates on its own as you talk (Memory). We covered that split in more depth in Claude Preferences vs Memory. This post is about a different axis entirely: not what memory contains, but where it physically lives — on the provider's infrastructure, or on yours.
How cloud providers handle your memory today
OpenAI's Memory FAQ describes ChatGPT memories as stored separately from your chat history: deleting a conversation does not delete the memories it produced, and you have to clear those separately in settings. Deleted memories can be retained for up to 30 days afterward for safety and debugging purposes before they're purged. In the EU and EEA, Memory has stayed disabled pending compliance review under the EU AI Act — a reminder that cloud memory features ship, and are withheld, on the provider's schedule, not yours.
Data portability law doesn't close the gap much. GDPR's Article 20 gives EU users a right to export data they provided, in a machine-readable format, within a month of asking — but it explicitly does not cover data a model inferred from your conversations, and there's no standard destination format for AI chat memory to move to even when it applies. The right to leave exists; there's rarely anywhere obvious to go.
What self-hosting actually changes
Self-hosted memory flips the default: instead of context living wherever the provider decided to put
it, it lives wherever you point it. open-context's MCP server ships six tools —
save_context, recall_context, list_contexts,
search_contexts, update_context, and delete_context — backed by
a store that defaults to a plain JSON file at ~/.opencontext/contexts.json. Nothing is
sent to a third party; your Claude client talks directly to a process on your own machine.
Deletion is immediate and literal: delete_context removes the entry, full stop, with no
30-day safety-retention window because there's no provider retaining it. Retention policy is whatever
you set it to, because you're the one holding the data.
The actual trade-offs
| Cloud memory (ChatGPT / Claude default) | Self-hosted (open-context) | |
|---|---|---|
| Setup | Enabled by default, zero config | One docker run or npm install |
| Retention | Provider's policy; deleted items may linger up to 30 days | Whatever you configure — deletion is immediate |
| Who can read it | The provider, per their terms of service | Only processes you grant access to |
| Cross-device sync | Built in | Built in, if you point every device at the same networked backend |
| Backup responsibility | Provider's | Yours |
| Vendor lock-in | Data format and export tied to that provider | Plain JSON or a standard database you can query directly |
Self-hosted doesn't mean solo — BYODB
The common objection to self-hosting is that it trades convenience for isolation: one memory file on
one laptop, no sync, no team access. open-context avoids that with BYODB — the context store is an
adapter interface with 15 backends behind it, from the default JSON file and SQLite up through
Postgres, MySQL, SQL Server, MongoDB, Redis, DynamoDB, Firestore, and SurrealDB. Point
OPENCONTEXT_DB_URL at a shared Postgres instance and every machine, container, or
teammate connecting to it shares the same context — cloud-style sync, still on infrastructure you
control. Connection strings are written with owner-only file permissions and redacted from every log
and API response, and opencontext db migrate copies contexts between backends without
deleting the source, so switching from a laptop file to a shared database later doesn't cost you your
history.
A practical way to decide
- Pick cloud memory if you want it working in the next thirty seconds, you're comfortable with the provider's retention terms, and you don't handle regulated or client-confidential data in your conversations.
- Pick self-hosted if you need to guarantee deletion, you work with data that can't leave your own infrastructure, or you just don't want your conversation history to be someone else's product decision.
- Pick a hybrid — self-hosted on a shared database — if you want team-wide sync without handing the data to a third party at all.
Run your own AI memory in about five minutes.
Get started with open-context →FAQ
Is open-context's local memory store encrypted at rest?
Not by default. The default JSON store and SQLite backend rely on your operating system's disk encryption. Database connection strings are saved with owner-only (0600) file permissions and redacted from logs and API responses, but the context data itself is only as encrypted as the backend or disk you choose — Postgres and most managed databases support encryption at rest if you need it.
Can I move from ChatGPT's cloud memory to a self-hosted store?
Yes. Export your ChatGPT data as a ZIP from Settings → Data Controls → Export data, then run it through open-context to generate preferences and memory files, or connect the MCP server so Claude starts saving new context to your own store going forward.
Does self-hosting mean giving up sync across devices?
No. Point open-context at a shared backend — Postgres, MySQL, or another networked database from its BYODB list — via OPENCONTEXT_DB_URL, and every machine that connects to it shares the same context, the same way cloud memory syncs across your devices today.
Do I have to pick one database backend permanently?
opencontext db migrate copies contexts and bubbles from one backend to another without deleting the source, so you can start on the default JSON file and move to SQLite or Postgres later without losing history.
Is open-context affiliated with OpenAI or Anthropic?
No. open-context is an independent, community-built, open source tool. It is not affiliated with, endorsed by, or built by OpenAI or Anthropic.