August 15, 2026 · 6 min read

Why Self-Hosting Your AI Context Matters for Privacy

Self-hosting your AI context means the tool that stores your chat history, preferences, and memory runs on infrastructure you control — your own laptop, your own Docker container, your own file on disk — instead of a vendor's cloud. It matters because cloud AI providers set the rules for what happens to your conversations by default, including whether they're used for model training and how long they're retained after you try to delete them. A self-hosted tool like open-context sidesteps that entirely: your context never leaves your machine unless you explicitly send it somewhere.

Key takeaways

Cloud AI providers can use free and Plus-tier conversations to train models unless you manually opt out in account settings, and may still retain data for a period afterward for abuse review.
Self-hosting means your AI memory lives on infrastructure you control from the start — there's no vendor retention policy to read or opt-out toggle to remember.
open-context's MCP context store is a plain JSON file at ~/.opencontext/contexts.json, with zero outbound network calls unless you explicitly enable Ollama.
GDPR's Article 20 data portability right exists precisely because most AI data lives on someone else's servers — self-hosting is a structural way to avoid ever needing to invoke it.
Self-hosting trades vendor-managed convenience — backups, sync, uptime — for full control. You take on the responsibility that a cloud provider would otherwise carry.

What "self-hosting your AI context" actually means

Most AI assistants store your history, preferences, and memory on the vendor's servers by default — that's what makes them work across your devices without you thinking about it. Self-hosting flips that: the storage layer runs on hardware you control instead. Concretely, for open-context that means running the CLI, the Docker image, or the local dev server on your own machine, with everything written to ~/.opencontext/ — a directory on your filesystem, not a database in someone else's data center.

This applies to two different kinds of AI context: the one-time import of history from a provider like ChatGPT, and the ongoing memory an MCP server gives Claude across future conversations. Both can be self-hosted the same way.

The privacy problem with cloud-hosted AI memory

When your context lives on a vendor's servers, the vendor's policies — not yours — decide what happens to it. As of 2026, OpenAI's own data controls describe this clearly for ChatGPT: on Free and Plus plans, conversations can be used to improve the model unless you turn off "Improve the model for everyone" in Settings, and even with that setting off, messages can still be retained for a period (OpenAI cites roughly 30 days) for abuse monitoring and legal compliance before deletion. Team, Enterprise, and API usage are excluded from training by default, but that's a plan-level distinction you have to know to select.

None of this makes any one vendor unusually bad — it's structural. Any time your chat history sits on infrastructure you don't operate, you're relying on a policy toggle and a retention window that can change, rather than on the simple fact that the data was never sent off your machine.

Why local-first architecture changes the risk model

Self-hosted tools remove the policy question by removing the transfer. open-context is built local by default: conversion, preference storage, and the MCP context store all run as a process on your machine, writing to files you own. The MCP server that gives Claude persistent memory stores every save_context entry in ~/.opencontext/contexts.json — a plain JSON file, not a hosted database — and the only network call the whole system can make is to an Ollama instance you point it at, and only if you turn on AI-powered preference analysis.

Skip that flag with --skip-preferences, and the entire pipeline, from ChatGPT export to Claude-ready markdown, never touches the network at all. There's no training opt-out to configure because there's no training happening on your data in the first place.

What self-hosting looks like in practice

The official Docker image is the fastest path — it bundles the web UI, REST API, and MCP server into one container:

docker run -p 3000:3000 \
  -v opencontext-data:/root/.opencontext \
  adityakarnam/open-context:latest

Everything the app reads and writes lives in that mounted volume, not in browser storage and not on a remote server. If you'd rather run persistent memory for Claude specifically, the same image runs in MCP stdio mode — see the MCP persistent memory setup guide for the full walkthrough of connecting it to Claude Code or Claude Desktop.

The trade-offs: what you give up by self-hosting

Self-hosting isn't free of cost, it just moves the cost. A cloud provider's infrastructure team handles backups, uptime, and cross-device sync so you don't have to think about them. When you self-host, those responsibilities move to you:

Backups — contexts.json and your preferences files are only as safe as your own backup habits. Nothing automatically copies them elsewhere.
Cross-device sync — running open-context on two machines gives you two separate context stores unless you deliberately share the volume or sync the file yourself.
Hardware for AI analysis — the optional AI-generated preferences and memory summaries run through Ollama locally, and larger models (13–40GB) need real RAM or a GPU to run at reasonable speed. Skipping AI analysis avoids this entirely and still produces a full markdown conversion.

For most people evaluating whether to self-host their AI context, this is the actual trade: less convenience, more certainty about where the data sits.

Self-hosting and your legal right to your own data

Regulations like the GDPR's Article 20 give EU users a right to data portability — to receive their personal data from a service in a structured, machine-readable format, and to move it elsewhere. That right exists because, by default, most of your data lives with a controller who isn't you, and getting it back requires a formal request. Self-hosting doesn't replace that right, but it sidesteps the need to exercise it for AI context specifically: if the data was written to your own disk from the start, there's no request to make and no month-long response window to wait on.

Keep your AI context on your own machine, from import to memory.

Get started with open-context →

FAQ

Does self-hosting my AI context mean I stop using Claude or ChatGPT in the cloud?

No. Self-hosting your context and using a cloud AI assistant aren't mutually exclusive. open-context stores and prepares your preferences, memory, and conversation history locally, then you paste or connect that context into whichever cloud assistant you're using — the assistant itself can still run in the cloud.

Do I need a powerful machine to self-host open-context?

No. The core conversion, storage, and MCP server run comfortably on a laptop with no GPU. A capable machine only matters if you enable optional AI-powered preference analysis via Ollama, which benefits from more RAM and a GPU for larger models.

Is self-hosted AI context the same as running a local LLM?

No. open-context itself is not a language model — it's a converter and a local memory store. It only talks to a language model (Ollama, running locally) if you opt into AI-generated preference and memory summaries; skip that flag and no model is involved at all.

Can self-hosted context sync across multiple devices?

Not automatically. Self-hosting trades vendor-managed sync for full control — if you want your context.json store available on more than one machine, you're responsible for that, for example by mounting the same Docker volume on a home server or syncing the file yourself.

Is open-context affiliated with Anthropic or OpenAI?

No. open-context is an independent, community-built, open source tool. It is not affiliated with, endorsed by, or built by Anthropic or OpenAI.