Installing a memory provider (Honcho, mem0, hindsight, ...) from the dashboard Plugins page failed on hosted deployments with a permission error: the setup endpoint shelled out to `uv pip install --python sys.executable`, which targets the sealed read-only venv under /opt/hermes (immutable hosted image, NS-579/#49113). The correct mechanism already exists: tools/lazy_deps.py redirects installs to the writable durable target on the data volume (HERMES_LAZY_INSTALL_TARGET=/opt/data/lazy-packages) when the venv is sealed (HERMES_DISABLE_LAZY_INSTALLS=1), appends the target to the END of sys.path (core venv always wins collisions), and constrains shared deps to core-venv versions. The dashboard installer simply never used it. Fix: - tools/lazy_deps.py: new public install_specs() — installs arbitrary manifest-declared pip specs through the same environment routing as ensure(): venv-scoped by default, durable-target on sealed images, refused with an actionable reason when gated off (config kill switch or sealed venv without a target — never surfaces raw EROFS/EACCES). Specs are validated with _spec_is_safe(); post-install it invalidates import/metadata caches so availability rechecks in the same process see the new packages without a restart. Never raises. - hermes_cli/web_server.py: _install_memory_provider_pip_dependencies now calls install_specs() instead of building its own uv/pip subprocess. Blocked installs surface the gate reason in the setup results; the response's status block reflects post-install availability (stale 'missing deps' state clears immediately). - hermes_cli/memory_setup.py, plugins/memory/honcho/cli.py, plugins/memory/mem0/_setup.py: CLI setup wizards routed through install_specs() too — same sealed-venv failure mode, same fix. No hosted setup path writes to /opt/hermes anymore; provider discovery and installation now use the same environment (sys.path activation is shared with the lazy-install bootstrap in hermes_bootstrap). Tests: - tests/tools/test_lazy_deps.py: TestInstallSpecs — gating matrix (sealed+no-target blocked with immutable-deployment reason, config kill switch, sealed+target proceeds), spec-safety rejection before any subprocess, venv-scoped vs --target command display, failure stderr passthrough, never-raises contract. - tests/hermes_cli/test_web_server.py: setup endpoint routes pip through lazy_deps (regression guard asserts no direct 'pip install' subprocess), blocked-reason surfacing, same-response availability recheck clears stale missing state. Fixes NS-605 (Plain T-1111). |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| _backend.py | ||
| _oss_providers.py | ||
| _setup.py | ||
| plugin.yaml | ||
| README.md | ||
Mem0 Memory Provider
Server-side LLM fact extraction with semantic search and hybrid multi-signal retrieval via the Mem0 Platform v3 API.
Requirements
pip install mem0ai- Mem0 API key from app.mem0.ai
Setup
hermes memory setup # select "mem0"
Or manually:
hermes config set memory.provider mem0
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env
Config
Behavioral settings live in $HERMES_HOME/mem0.json (set them via hermes memory setup). Only the secret MEM0_API_KEY belongs in ~/.hermes/.env.
| Key | Default | Description |
|---|---|---|
mode |
platform |
platform (Mem0 Cloud) or oss (self-managed, in-process) |
host |
— | Self-hosted Mem0 server URL (the Docker dashboard). When set, connects over HTTP with X-API-Key. Don't combine with mode: oss |
user_id |
hermes-user |
User identifier on Mem0 |
agent_id |
hermes |
Agent identifier |
rerank |
false |
Rerank search results for relevance (platform mode only) |
The plugin has three connection modes:
- Platform — Mem0's hosted cloud (
api.mem0.ai). SetMEM0_API_KEY. (default) - Self-hosted dashboard — a Mem0 server you run yourself via Docker. Set
host. See below. - OSS — run Mem0 in-process with your own LLM + vector store. Set
mode: oss. See below.
Self-Hosted Dashboard (Server) Mode
Connect the plugin to a standalone Mem0 server you run yourself — the Docker-shipped Mem0 dashboard/server with its own REST API. Unlike OSS mode (which runs mem0ai in-process with your own vector store), here the plugin just talks HTTP to your server.
- Run the Mem0 server (FastAPI + pgvector) from its Docker image and note its URL and
ADMIN_API_KEY. - Point the plugin at it — via the setup wizard:
or via env vars:hermes memory setup # select "mem0" → "Self-hosted server" # Or non-interactive: hermes memory setup mem0 --mode selfhosted --host http://localhost:8888 --api-key your-admin-api-key
or inecho "MEM0_HOST=http://localhost:8888" >> ~/.hermes/.env echo "MEM0_API_KEY=your-admin-api-key" >> ~/.hermes/.env$HERMES_HOME/mem0.json:{ "host": "http://localhost:8888", "api_key": "your-admin-api-key" } - Start a fresh Hermes session and call
mem0_search— it connects to your server.
The plugin authenticates with X-API-Key and uses the server's /search and /memories routes. api_key is optional — omit it only for servers running with AUTH_DISABLED.
Setting
hostroutes to the self-hosted server automatically. Don't setmode: oss— OSS takes precedence and ignoreshost.
OSS (Self-Hosted) Mode
Run Mem0 locally with your own LLM, embedder, and vector store. This is the in-process SDK mode. To instead connect to a Mem0 server you run via Docker, see Self-Hosted Dashboard (Server) Mode above.
Interactive Setup
hermes memory setup
# Select "mem0" → "Open Source (self-hosted)"
# Follow prompts for LLM, embedder, and vector store
Agent-Driven Setup (Flags)
hermes memory setup mem0 --mode oss \
--oss-llm openai --oss-llm-key sk-... \
--oss-vector qdrant
Supported Providers
| Component | Providers |
|---|---|
| LLM | openai, ollama |
| Embedder | openai, ollama |
| Vector Store | qdrant (local/server), pgvector |
Flags Reference
| Flag | Description |
|---|---|
--mode |
platform or oss |
--oss-llm |
LLM provider (default: openai) |
--oss-llm-key |
LLM API key |
--oss-embedder |
Embedder provider (default: openai) |
--oss-vector |
Vector store (default: qdrant) |
--oss-vector-path |
Qdrant local path |
--user-id |
User identifier |
Switching Modes
Platform to OSS
hermes memory setup mem0 --mode oss --oss-llm-key sk-...
Or edit $HERMES_HOME/mem0.json directly:
{
"mode": "oss",
"oss": {
"llm": {"provider": "openai", "config": {"model": "gpt-5-mini"}},
"embedder": {"provider": "openai", "config": {"model": "text-embedding-3-small"}},
"vector_store": {"provider": "qdrant", "config": {"path": "~/.hermes/mem0_qdrant"}}
}
}
OSS to Platform
hermes memory setup mem0 --mode platform --api-key sk-...
Dry Run (preview without writing)
hermes memory setup mem0 --mode oss --oss-llm-key sk-... --dry-run
Tools
| Tool | Description |
|---|---|
mem0_search |
Semantic search by meaning |
mem0_add |
Store a fact verbatim (no LLM extraction) |
mem0_update |
Update a memory's text by ID |
mem0_delete |
Delete a memory by ID |
Troubleshooting
"Mem0 temporarily unavailable"
Circuit breaker tripped after 5 consecutive failures. Resets after 2 minutes.
- Platform mode: Check API key and internet connectivity.
- OSS mode: Check that your vector store (qdrant/pgvector) is running.
OSS: Qdrant connection refused
# If using local Qdrant, check the storage path is writable:
ls -la ~/.hermes/mem0_qdrant
# If using Qdrant server, check it's reachable:
curl http://localhost:6333/healthz
OSS: PGVector connection refused
# Verify PostgreSQL is running and accepting connections:
pg_isready -h localhost -p 5432
OSS: Ollama not reachable
# Check Ollama is running:
curl http://localhost:11434/api/tags
Memories not appearing
mem0_addstores verbatim (no extraction). Usesync_turnfor LLM extraction.- Search uses semantic matching — try broader queries.
- Check
user_idmatches between sessions ($HERMES_HOME/mem0.json).