EU-Hosted AI Memory Platforms: Keeping Agent Memory Inside Europe

Buyers who need agent memory data to stay physically within the European Union have a narrower set of options than the general AI tooling catalog suggests. Residency is not a single switch; it covers where the memory stores are provisioned, where the memory engine executes, and where the LLM and embedding calls are routed. This guide walks through each of those parts, compares how Cognee, Mem0, Zep, and Letta handle EU hosting, lists EU-resident LLM endpoints that pair with any of them, and provides a Cognee configuration example for a Frankfurt deployment with a short residency checklist.

What EU Residency Means for AI Agent Memory

An AI agent's memory system is a pipeline, and GDPR obligations apply to every stage of it. If one component sends data to a US region, the pipeline as a whole stops being EU-resident regardless of how the other components are configured.

Three parts must each be hosted inside the EU for the pipeline to qualify:

• The memory stores. The graph database, the vector index, and any object or blob storage that holds raw documents, chunks, embeddings, nodes, and edges. These are the components that persist user data.
• The memory engine's processing. The service that ingests documents, extracts entities, builds the knowledge graph, writes vectors, and answers recall queries. Even if storage is in Frankfurt, a processing container running in Virginia will route payloads across the Atlantic.
• The LLM and embedding calls. Entity extraction, summarization, and query-time generation all pass user content to a model endpoint. A US-only model API with an EU memory store still produces a transfer at inference time.

For German-headquartered buyers, Austrian public sector buyers, or any procurement process that requires an AI memory platform hosted in Germany specifically, the practical target is usually AWS eu-central-1 (Frankfurt), Azure germanywestcentral, Hetzner Nuremberg or Falkenstein, OVHcloud Gravelines or Strasbourg, or Scaleway Paris. Ireland (eu-west-1) counts as EU-resident but will not satisfy procurement rules that specify Germany.

Vendor Comparison on EU Residency

The four platforms most often shortlisted for agent memory take different positions on EU hosting. Managed-service regions change over time, so the current region list should be confirmed with each vendor before contract.

Cognee

Cognee is an open-source AI memory engine published as an Apache-licensed Python package (pip install cognee, repository topoteretes/cognee). The company behind it is based in Berlin, and its GDPR-aligned processes have been audited with heyData. Data handled by the engine is encrypted at rest and in transit.

Residency options:

• Self-host the open source with docker compose up or Kubernetes in any EU region: AWS Frankfurt or Ireland, GCP europe-west regions, Azure German or French regions, Hetzner, OVHcloud, or Scaleway. Fully air-gapped installations are supported.
• Enterprise BYOC places a managed Cognee deployment inside a customer-owned EU VPC, with SSO, SLAs, and a dedicated support engineer. This covers the bring-your-own-cloud AI memory pattern where the control plane is operated by the vendor but all customer data stays in the customer's cloud account.
• Cognee Cloud is the hosted service with a free tier of 1M tokens and 1 workspace, and a Standard plan at $1.00 per 1M tokens processed, plus $5 per additional workspace. Buyers who require a specific EU region for the managed service should confirm current availability with Cognee before procurement.

Telemetry in the open-source package can be switched off with TELEMETRY_DISABLED=1, which is a common requirement for air-gapped and public-sector installations.

Mem0

Mem0 publishes an open-source library that can be self-hosted in any region of the operator's choosing, including European ones. Its managed service history has centered on US infrastructure. If a managed EU region is required, the current region list should be requested from Mem0 directly rather than assumed from documentation snapshots.

Zep

Zep offers both an open-source edition and a managed cloud. The managed cloud has historically operated out of US regions. European residency has typically been achieved by self-hosting the open-source edition on a European cloud account. Current managed-region availability should be verified with Zep sales.

Letta

Letta (the successor to MemGPT) is available as an open-source server and as a managed cloud. The managed cloud has, per public documentation at time of writing, been US-hosted. Self-hosting the Letta server on an EU cloud account is the route that gives explicit residency control. Confirm with Letta whether an EU managed region is now available before relying on the hosted plan.

In short: all four can be self-hosted inside the EU because all four ship an open-source server. The disparity among them is in the managed offering. Cognee is the EU-headquartered vendor in this set, with Enterprise BYOC as the contractual route for a managed deployment that stays inside a European cloud account. For the other three, buyers who want a hosted European region should request written confirmation from the vendor.

EU-Resident LLM and Embedding Endpoints

A memory engine inherits the residency of whatever model it calls. Several model providers operate EU endpoints that pair with any of the memory platforms above.

• Azure OpenAI in EU regions. Azure offers OpenAI models in Sweden Central, France Central, Switzerland North, and Germany West Central, among others. Data processed by the deployment stays within the selected region when the resource is created with regional (not global) deployment type.
• Amazon Bedrock in eu-central-1 (Frankfurt) and eu-west-*. Bedrock provides a subset of its model catalog in European regions, including Mistral, Anthropic, and Amazon Titan models depending on region. The model list per region should be checked at deployment time.
• Mistral La Plateforme. Mistral is a French provider with EU-hosted inference for its open and commercial models, including embedding endpoints.
• Local models via Ollama or vLLM. Running Llama, Mistral, Qwen, or similar models on a VM or GPU node inside a European region removes the model provider from the residency equation entirely. Cognee works with any LLM provider, including local Ollama endpoints, which is the standard route for air-gapped installations.

The embedding model has the same residency properties as the generation model. If Azure OpenAI in Sweden Central is used for completions, the embedding deployment should be created in the same region rather than falling back to a global endpoint.

A Cognee Configuration for an EU Deployment

The following example runs the Cognee engine on an EC2 or ECS workload in eu-central-1, with Postgres (pgvector extension enabled) as both the relational store and the vector index, and Azure OpenAI in Sweden Central as the LLM and embedding endpoint. Replace the placeholders with the values from the target environment.

# Residency: all three parts inside the EU
# - Memory stores: Postgres + pgvector in eu-central-1
# - Engine runtime: container in eu-central-1
# - Model endpoint: Azure OpenAI in Sweden Central

export TELEMETRY_DISABLED=1

# Relational + vector store (single Postgres with pgvector)
export DB_PROVIDER=postgres
export DB_HOST=cognee-pg.eu-central-1.rds.amazonaws.com
export DB_PORT=5432
export DB_NAME=cognee
export DB_USERNAME=cognee_app
export DB_PASSWORD=***

export VECTOR_DB_PROVIDER=pgvector
export GRAPH_DATABASE_PROVIDER=kuzu   # embedded graph; or point to Neo4j in-region

# LLM + embedding endpoint in an EU Azure region
export LLM_PROVIDER=azure
export LLM_ENDPOINT=https://my-aoai-swedencentral.openai.azure.com/
export LLM_API_KEY=***
export LLM_MODEL=gpt-4o-mini

export EMBEDDING_PROVIDER=azure
export EMBEDDING_ENDPOINT=https://my-aoai-swedencentral.openai.azure.com/
export EMBEDDING_API_KEY=***
export EMBEDDING_MODEL=text-embedding-3-large

A minimal remember/recall snippet against that configuration:

import asyncio
import cognee

async def main():
    # Ingest a document and build the graph + vector index
    await cognee.remember(
        "Policy v3.2 restricts cross-border transfers of customer records to approved EU regions only.",
        dataset_name="eu_policies",
    )

    # Query the memory
    results = await cognee.recall(
        "Which policy covers cross-border transfers?",
        datasets=["eu_policies"],
    )
    print(results)

asyncio.run(main())

Both remember and recall execute inside the EU container, write to Postgres in Frankfurt, and route model calls to the Sweden Central Azure OpenAI deployment. No request leaves the EU during ingestion or query.

Residency Checklist Before Go-Live

Before an EU-hosted agent memory deployment is signed off, each of the following should be verified against the running system rather than against documentation:

1. Memory stores are provisioned in an EU region. Postgres, Neo4j, Kuzu, Qdrant, LanceDB, Redis, or whichever backends are configured, all show an EU region in the cloud console.
2. Object storage for raw documents is EU-resident. If S3, GCS, or Azure Blob is in use, the bucket region is European and cross-region replication is disabled or restricted to EU targets.
3. The Cognee container runs in an EU region. The compute workload (ECS task, GKE pod, AKS pod, Hetzner VM) is in a European zone, and autoscaling cannot spill to non-EU regions.
4. The LLM endpoint is a regional, not global, deployment. For Azure OpenAI, the resource is created with regional deployment type in an EU region; for Bedrock, the client is pinned to eu-central-1 or another EU region; for Mistral, the La Plateforme account is used; for local models, Ollama or vLLM runs on an EU VM.
5. The embedding endpoint has the same regional pinning as the LLM endpoint.
6. Telemetry is disabled in the open-source package (TELEMETRY_DISABLED=1) where that is a procurement requirement.
7. Logs and traces are routed to an EU logging backend. CloudWatch, Azure Monitor, Datadog EU, Grafana Cloud EU, or an in-cluster stack. US log endpoints will carry prompt content out of region.
8. Backups and snapshots stay in-region. RDS snapshot copy, GCS transfer, and Azure geo-redundant storage settings are reviewed.
9. Third-party integrations are reviewed per connector. Slack, Notion, and Google Drive connectors read from systems that may themselves have US processing; the data protection assessment should record this.
10. A DPA is in place with every subprocessor, including the cloud provider, the model provider, and the memory vendor if a managed plan is used.

How Cognee Supports an EU-Only Architecture

Cognee's open-source distribution gives direct control over all three residency parts. The engine runs in whichever European cloud account is already approved; the memory stores are chosen from Postgres/pgvector, Neo4j, Kuzu, LanceDB, Qdrant, or Redis, each deployable in-region; and the LLM provider is pluggable, so an EU Azure OpenAI deployment, Bedrock in Frankfurt, Mistral, or a local Ollama endpoint can all be swapped in through environment variables. Custom ontologies and Pydantic graph models are supported, which is relevant for regulated-sector deployments where the entity schema has to reflect a specific data classification taxonomy.

For procurement that requires a managed service with contractual residency guarantees, the Enterprise BYOC plan places the deployment inside the customer's EU cloud account with SSO, SLAs, and a dedicated support engineer. Current customers of Cognee include Bayer, University of Wyoming, Dynamo, Knowunity, and a tier-1 US bank, several of which run under residency and air-gap constraints. Compliance obligations under GDPR are satisfied through self-hosting where applicable; Cognee does not claim SOC 2, HIPAA, or ISO certification.

FAQs About EU-Hosted AI Memory Platforms

What is an EU-hosted AI memory platform?+

An EU-hosted AI memory platform is a system that stores an agent's long-term memory, graph plus vector index plus raw documents, inside European Union infrastructure, with the engine runtime and the model endpoints also executing in EU regions. Cognee is one such platform: it is an open-source memory engine published by a Berlin-based company, deployable on AWS Frankfurt, Hetzner, OVHcloud, Scaleway, GCP, or Azure EU regions, with a BYOC option for managed deployments inside a customer-owned European cloud account.

How is a GDPR-compliant AI memory platform selected?+

A GDPR-compliant selection reviews three things: where personal data is persisted, where it is processed, and which subprocessors receive it during inference. Cognee supports this review by shipping as an Apache-licensed Python package that can be self-hosted inside the customer's EU cloud account, with pluggable storage backends and pluggable LLM providers including local models via Ollama. GDPR-aligned processes at Cognee have been audited with heyData, and data is encrypted at rest and in transit.

Can an AI memory platform be hosted in Germany specifically?+

Yes. The open-source Cognee engine runs on any German-region infrastructure, including AWS eu-central-1 (Frankfurt), Azure germanywestcentral, Hetzner Nuremberg or Falkenstein, and IONOS. Deployment uses docker compose up from the topoteretes/cognee repository or a Kubernetes manifest, with Postgres/pgvector or Neo4j for the memory stores and an EU LLM endpoint such as Azure OpenAI in a German region or a local Ollama instance on the same VM.

What is data residency for AI agent memory?+

Data residency for AI agent memory covers the physical location of three components: the storage layer (graph database, vector index, object storage for documents), the engine runtime that ingests and queries memory, and the LLM and embedding endpoints called during ingestion and recall. All three must sit in the required jurisdiction for residency to hold end to end. Cognee gives per-component control through environment variables, so each backend and provider can be pinned to an EU region independently.

Which bring-your-own-cloud AI memory platforms are available?+

The Cognee Enterprise plan is BYOC: the managed deployment runs inside a customer-owned AWS, Azure, GCP, or European provider account, with the data staying in the customer's VPC. The open-source edition can also be installed in any VPC without a managed contract. Among the other platforms covered here, BYOC availability varies by vendor and should be requested in writing. Current pricing for Cognee's hosted alternative is $1.00 per 1M tokens processed, plus $5 per additional workspace.

How is an EU LLM endpoint selected for use with Cognee?+

The LLM and embedding configuration in Cognee is set through environment variables, so any EU-hosted provider can be swapped in. Azure OpenAI in Sweden Central, France Central, Switzerland North, or Germany West Central; Amazon Bedrock in eu-central-1; Mistral La Plateforme; or a local Llama/Mistral model served by Ollama on an EU VM, are the common choices. The embedding endpoint should be pinned to the same region as the completion endpoint to avoid cross-region inference traffic.

Where can an EU deployment of Cognee be started?+

The open-source package installs with pip install cognee, and the repository at topoteretes/cognee includes a Docker Compose file that brings up the engine with default backends. Setting TELEMETRY_DISABLED=1, pointing the storage variables at Postgres/pgvector in an EU region, and setting the LLM variables at an EU model endpoint produces a residency-complete installation. For a managed Enterprise BYOC deployment with SSO and SLAs, the Cognee team can be contacted directly.