Install Mem0 and Cognee

Mem0 and Cognee are installed with the installation wizard of the Navin Manager, like the other services of the catalog (permission services:install on the cluster). Each parameter is detailed in the generated pages mem0 and cognee.

Host prerequisites

The preflight checks of the descriptor block the installation when a threshold is not met.

Check	Mem0	Cognee
Memory	at least 1024 MB (blocking)	at least 4096 MB (blocking), 8192 MB advised (warning)
CPU	at least 1	at least 2
Free disk	at least 2048 MB	at least 10240 MB for /var/lib/navin
Free ports	8720/tcp (API)	8420/tcp (API), 8421/tcp (interface, with ui_enabled), 8422/tcp (MCP, with mcp_enabled)

By default the API listens on the private address of the host only (listen_scope set to network) and the host firewall opens it to the consumers; local limits it to the loopback. It is never published by a gateway. The MCP server of Cognee listens on 127.0.0.1 only.

Reused dependencies, never installed by default

Mem0 and Cognee themselves are part of no default installation. Their dependencies are existing services of the catalog, bound at the Bindings step of the wizard.

Binding	Service	Mem0	Cognee
database	postgresql	required: database mem0 (pgvector collection of the memories and entities)	required: database cognee (users, datasets, permissions, state of the pipelines, one pgvector schema ds_<dataset> per dataset)
app	postgresql	required: database mem0_app (users, API keys, tokens, settings, request log), on the same PostgreSQL server as mem0	-
llm	litellm	required	required
otel	otel-collector	-	optional, traces of the python method only

An optional dependency stays unbound until it is bound. Neo4j is never installed: the graph memory of Mem0 and the lemmatized keyword scoring (spaCy) stay off. Grafana and Loki are not used.

Dedicated PostgreSQL database and role

The provisioning of the postgresql service creates, for each engine, a technical role that owns its own databases only, and the vector extension:

• Mem0: the role mem0, owner of the databases mem0 and mem0_app, no superuser, no CREATEROLE nor CREATEDB (verified by test_mem0_real.py).
• Cognee: the role cognee, owner of the database cognee only, no superuser nor CREATEDB.

On uninstall these databases stay in PostgreSQL: drop them there once the data is no longer kept.

Models through LiteLLM, vLLM or Ollama

Both engines use the OpenAI compatible API of LiteLLM (<url>/v1); the vLLM and Ollama engines of the Manager are reached through it. No model is downloaded at start.

Parameter	Mem0	Cognee
LLM	llm_model, default local-llama (fact extraction, JSON mode)	llm_model, default local-llama (graph extraction, summaries, answers)
Embedding	embedder_model, default bge-m3-vllm	embedding_model, default bge-m3-vllm
Vector size	embedding_dims, default 1024	embedding_dimensions, default 1024
Gateway key	llm_api_key (LiteLLM virtual key); empty, the master key of the bound gateway	llm_api_key, same rule

The vector size sets the vector column at creation: changing it needs a new collection (Mem0) or new datasets (Cognee). The launcher of Cognee refuses to start when the gateway does not list both models.

Methods offered and why

Service	Methods	Reason
Mem0	python only	the sources of server/ of the v2.2.1 archive in a virtual environment (Python 3.12, pinned dependencies). The Docker Hub image mem0/mem0-api-server has no versioned tag (one floating tag of 2025, before v2): no podman method. The Next.js dashboard is not delivered, for lack of a versioned official image
Cognee	python (default) and podman	python: the cognee 1.6.6 package and its dependencies in a virtual environment; podman: the official images cognee/cognee, cognee/cognee-ui and cognee/cognee-mcp pinned by digest. The interface and the MCP server exist with podman only; the OpenTelemetry traces with python only

Both services have one mode, single (see High availability and limits).

Offline installation

The images are pinned by digest, the packages by version; the existing hub and offline bundle of the Manager carry them. When the bundle is imported, the digest of each image is recorded in the mirror of the Manager and every load is checked against it; an image that does not carry it is refused. No latest, main or development tag is used. At run time no outbound connection is made: telemetry off, HF_HUB_OFFLINE and TRANSFORMERS_OFFLINE for Cognee, local cost map of LiteLLM.

Refusals before and during the start

• Preflight checks: memory, CPU, disk and free ports (table above); a failure blocks the plan.
• Mem0 launcher: it exits with code 2 when AUTH_DISABLED is true, when MEM0_TELEMETRY is not false or when ADMIN_API_KEY is shorter than 32 characters (verified by test_mem0_real.py).
• Cognee launcher: it refuses to start without both models on the gateway; the ENV variable is refused by the agents.
• An incompatible version of a dependency is refused with its cause, in French and in English (ADR-0174).

Validation before the healthy state

The healthy state needs the health checks and the real functional test (smoke) of the descriptor.

Service	Health	Readiness	Functional test
Mem0	GET /openapi.json contains Mem0 REST APIs; pruner: last run succeeded recently	GET /auth/setup-status returns "needsSetup":false (administrator created, registration closed)	in the space navin-smoke-<nonce>: call without key refused (401), memory created, LLM call, semantic search, update, read back, deletion, empty space, cleanup whatever happened
Cognee	GET /health contains "status":"ready"; interface: /api/runtime-config; MCP: TCP port	authenticated check of /api/v1/datasets	in the dataset navin-smoke-<nonce>: call without key and public registration refused, two texts added, cognify, semantic search, graph completion, graph read, dataset deleted whatever happened

The functional test is run again from the service page, card Checks, Run the smoke test.