Self-hosting MemoryFirst: your memory, your infrastructure, your jurisdiction

There's a class of teams for whom the best SaaS in the world is still a no: those handling data that, by contract or by law, can't leave their control. Healthcare, legal, public sector, banking. For them, "send us your data in our cloud" ends the conversation.

MemoryFirst was designed assuming that requirement, not patching it in later.

What self-hosting means here

• Your infrastructure: the components — API, vector database, embedder — run wherever you put them. Our own infrastructure is in the EU (Hetzner); yours, wherever your compliance requires.
• No phone-home: memory doesn't need to call an external service to work. What enters your instance stays in your instance.
• Model-agnostic: you point the LLM at your provider — including a self-hosted or European one — via config. The memory layer doesn't tie you to a specific model.

What doesn't change when you self-host

The same OpenAI-compatible API, the same MCP server, the same verifiable citations, the same contradiction resolution. Self-hosting isn't a cut-down version: it's the same product, on your turf.

A memory layer sees all of your user's context. Where that layer runs isn't a deployment detail: it's a sovereignty decision.

Why it matters more every year

As AI moves into critical workflows, the question "where is my data?" stops being a compliance one and becomes an architectural one. Building on a layer you can self-host gives you an exit a closed cloud API never will: control.

Talk to us or start with the docs.