[OpenMemory] Lost all data when docker-compose down & up is used due to wrong volume path in docker-compose.yml

[genesiscz]

---

Bug Report: Data Loss Due to Incorrect Qdrant Volume Mount Path in Installation Script

So I did

curl -sL https://raw.githubusercontent.com/mem0ai/mem0/main/openmemory/run.sh | bash

it ran well, after that I wanted to restart the container and i did docker-compose down by mistake. A stupid mistake, which shouldn't remove the volume/data, right? It did not, but it somehow lost the state.

Summary

The OpenMemory installation script (run.sh) generates a docker-compose.yml file with an incorrect volume mount path for the Qdrant container, causing complete data loss when containers are recreated with docker-compose down and docker-compose up.

Environment

• mem0ai/mem0: Latest version from main branch
• Installation method: curl -sL https://raw.githubusercontent.com/mem0ai/mem0/main/openmemory/run.sh | OPENAI_API_KEY=xxx bash
• Docker version: Docker Compose V2
• Qdrant image: qdrant/qdrant:latest

Issue Description

The installation script creates a docker-compose.yml with the volume mount:

volumes:
  - mem0_storage:/mem0/storage  # ❌ INCORRECT PATH

However, Qdrant stores its data in /qdrant/storage, not /mem0/storage. This mismatch causes the volume to mount to a non-existent directory inside the container, so Qdrant writes data to the container's local filesystem instead of the persistent volume - which gets destroyed when docker-compose down is run.

Steps to Reproduce

1. Run the installation script:

   curl -sL https://raw.githubusercontent.com/mem0ai/mem0/main/openmemory/run.sh | OPENAI_API_KEY=your_key bash
   

2. Add some data/memories through the UI
3. Stop services: docker-compose down
4. Restart services: docker-compose up
5. Check if data persists

Expected Behavior

Data should persist after container recreation, and Qdrant should show:

Loading raft state from ./storage/raft_state.json
Loading collection: mem0migrations
Recovered collection mem0migrations: 1/1 (100%)

Actual Behavior

Data is lost, and Qdrant shows it's initializing fresh storage:

Initializing new raft state at ./storage/raft_state.json

Evidence

With incorrect path (/mem0/storage):

mem0_store-1 | 2025-06-02T18:28:10.471765Z INFO storage::content_manager::consensus::persistent: Initializing new raft state at ./storage/raft_state.json

With correct path in docker-compose.yml (/qdrant/storage):

mem0_store-1 | 2025-06-02T18:23:35.653282Z INFO storage::content_manager::consensus::persistent: Loading raft state from ./storage/raft_state.json
mem0_store-1 | 2025-06-02T18:23:35.657481Z INFO storage::content_manager::toc: Loading collection: mem0migrations
mem0_store-1 | 2025-06-02T18:23:35.675900Z INFO collection::shards::local_shard: Recovered collection mem0migrations: 1/1 (100%)

Fix Required

Update the installation script (run.sh) to generate the correct volume mount path:

services:
  mem0_store:
    image: qdrant/qdrant
    ports:
      - "6333:6333"
    volumes:
      - mem0_storage:/qdrant/storage  # ✅ CORRECT PATH

Workaround

Users can manually edit their docker-compose.yml file after installation to fix the volume mount path from /mem0/storage to /qdrant/storage.

I have no idea what implication will this have for other users, but I guess it should be somehow done because I will for sure not be the only one running docker-compose down accidentally instead of docker-compose stop

[johnwlockwood]

This change works and now persists memory between container down/up.

with:

volumes:
  - mem0_storage:/mem0/storage

/qdrant/storage is not on the volume

with:

volumes:
      - mem0_storage:/qdrant/storage

/qdrant/storage is on the volume

[robotparty]

Thanks! This fixed my issue as well

[parshvadaftari]

Closing as it's fixed with this PR: https://github.com/mem0ai/mem0/pull/3366