{ "version": "https://jsonfeed.org/version/1", "title": "Mem0 on LLBBL Blog", "icon": "https://avatars.micro.blog/avatars/2023/40/125738.jpg", "home_page_url": "https://llbbl.blog/", "feed_url": "https://llbbl.blog/feed.json", "items": [ { "id": "http://llbbl.micro.blog/2026/07/09/running-mems-memory-backend-as.html", "title": "Running Mem0's Memory Backend as Real Infrastructure with Ansible", "content_html": "

Mem0 works best when you treat its memory backend as infrastructure, not as some throwaway process you start by hand and forget about. There are two pieces worth automating early: the vector store and the graph store. Qdrant holds the embeddings for semantic lookup. Neo4j holds the relationship-oriented graph memory.

\n

Quick note before we go further, because this can be confusing. When folks talk about Mem0’s “graph” support, that is not GraphQL. GraphQL is an API query layer you’d put in front of your app. Mem0’s graph memory is an actual graph database, usually Neo4j, that the client talks to over Bolt. Different thing entirely.

\n

This post walks through a practical Ansible shape for running those backing services with Docker Compose. I’m not going to hand you a complete role. The point is to show the decisions that make the setup repeatable, because those are the parts people usually get wrong.

\n

What the deployment actually does

\n

Three responsibilities, that’s it:

\n
    \n
  1. Get the Mem0 compose project onto the server.
    2. \n
  2. Write a server-local .env file with the runtime config.
    3. \n
  3. Start the Compose stack with Qdrant and Neo4j.
    4. \n
\n

In a small setup, the Python client runs on your laptop while the services run on a LAN host or a small VPS. The server exposes these ports, but only to trusted networks:

\n\n

If you’re on a public internet host, bind these to localhost or hide them behind a VPN, firewall, or private network. Do not casually publish database ports to the internet. I shouldn’t have to say remind you…

\n

Role inputs

\n

A generalized role only needs a handful of variables:

\n
mem0_home: /opt/mem0\nmem0_repo: git@github.com:your-org/your-mem0-project.git\nmem0_branch: main\n\nmem0_qdrant_collection: default\nmem0_neo4j_enabled: true\n\nmem0_embedder_base_url: https://api.example.com/v1\nmem0_embedder_model: your-embedding-model\nmem0_embedder_dimensions: 1024\n

The collection name matters more than it looks. Qdrant collections have a fixed vector size. If you switch embedding models and the dimensions change, create a new collection. Don’t try to reuse the old one. This is a common way people break a working Mem0 setup, so treat the collection name as part of the embedding config, not an afterthought.

\n

Secrets

\n

Keep API keys and database passwords out of your regular vars files. Ansible Vault, a secrets manager, whatever your deployment system gives you. Then template a .env file with tight permissions:

\n
- name: Write Mem0 environment file\n  ansible.builtin.template:\n    src: mem0.env.j2\n    dest: "{{ mem0_home }}/.env"\n    mode: "0600"\n  no_log: true\n

That no_log: true is not optional. Template diffs will happily leak plaintext API keys and graph passwords into CI logs, terminal scrollback, and ticket attachments. Once a secret lands in a CI log, you’re rotating it, not deleting it.

\n

The template itself stays small:

\n
EMBEDDER_API_KEY={{ vault_embedder_api_key }}\nEMBEDDER_MODEL={{ mem0_embedder_model }}\nEMBEDDER_DIMENSIONS={{ mem0_embedder_dimensions }}\n\nQDRANT_HOST=qdrant\nQDRANT_PORT=6333\nQDRANT_COLLECTION={{ mem0_qdrant_collection }}\n\nNEO4J_URL=bolt://neo4j:7687\nNEO4J_USERNAME=neo4j\nNEO4J_PASSWORD={{ vault_neo4j_password }}\n

Notice QDRANT_HOST=qdrant, not an IP. When the Mem0 container talks to sibling Compose services, use the service names. Save hostnames and LAN DNS for clients that live outside the Compose network. More on that in a second, because it’s a real gotcha.

\n

Compose shape

\n

Just what you need to run Mem0’s memory backend in Docker.

\n
services:\n  qdrant:\n    image: qdrant/qdrant:v1.12.6\n    ports:\n      - "6333:6333"\n      - "6334:6334"\n    volumes:\n      - qdrant_storage:/qdrant/storage\n\n  neo4j:\n    image: neo4j:5.26\n    environment:\n      NEO4J_AUTH: "neo4j/${NEO4J_PASSWORD}"\n    ports:\n      - "7474:7474"\n      - "7687:7687"\n    volumes:\n      - neo4j_data:/data\n      - neo4j_logs:/logs\n\nvolumes:\n  qdrant_storage:\n  neo4j_data:\n  neo4j_logs:\n

Pin your image versions. Floating tags make it impossible to tell whether a later failure came from your playbook, your app, or an upstream image that changed under you at 2am. Pinning turns a mystery into a diff.

\n

The two Ansible flags that matter

\n

Most of the role can stay boring. Ensure the directory exists, clone the repo, template the .env, start the stack with community.docker.docker_compose_v2. The two details I want you to actually read are force: false on the git task and remove_orphans: true on the compose task.

\n

force: false protects local edits in the checkout. If the role needs to patch a generated file, make that explicit and safe instead of letting Git clobber the tree.

\n

remove_orphans: true keeps Compose honest. Say you rip out an old local embedding service and switch to a managed embedding API. Without this, the old container just keeps running forever, quietly, and you’ll swear the new config isn’t taking effect.

\n

And for restarts, use handlers. Notify a restart handler when the checkout changes or when .env changes. Don’t bounce the stack on every single playbook run. The steady-state run should be quiet.

\n

Service names vs. hostnames

\n

From a client running outside the Compose network, point Mem0 at the server’s reachable hostname:

\n
QDRANT_HOST=mem0.example.test\nNEO4J_URL=bolt://mem0.example.test:7687\n

From a container inside the same Compose project, use service names:

\n
QDRANT_HOST=qdrant\nNEO4J_URL=bolt://neo4j:7687\n

Get this backwards and you burn an afternoon on it…

\n

Check your work

\n

After the playbook runs, verify the pieces independently:

\n
docker compose ps\ncurl http://localhost:6333/healthz\ndocker compose logs --tail=100 neo4j\n

For Neo4j, actually test Bolt from the network where your client lives. The browser port on 7474 being reachable does not prove the Bolt endpoint on 7687 is usable. Different port, different assumption, don’t confuse a green browser page for a working client.

\n

The whole pattern

\n

Strip away the YAML and it’s simple. Docker Compose owns Qdrant and Neo4j. Ansible owns the checkout, the .env, and the Compose lifecycle. Vault owns the credentials. The client picks service names or external hostnames depending on where it runs.

\n

That gets you a repeatable Mem0 backend without turning your Ansible role into a second copy of the entire app. Pin your images, guard your secrets with no_log, and never reuse a collection after the vector size changes. Do those three and the rest is boring, which is exactly what you want from infrastructure.

\n
\n

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @logan@llbbl.blog.

\n
\n", "date_published": "2026-07-09T10:00:00-05:00", "url": "https://llbbl.blog/2026/07/09/running-mems-memory-backend-as.html", "tags": ["DevOps","docker","Ansible","Mem0","Qdrant","Neo4j"] } ] }