ద్వారా Matt Connor 2026-08-03 · అప్‌డేట్ చేయబడింది 2026-08-13

VPSలో mem0 self-host చేయడానికి ఎంత RAM అవసరం?

Q: local embedding model కు మారిన తర్వాత mem0 ఎలాంటి results ఎందుకు ఇవ్వదు?

pgvector table fixed width తో సృష్టించబడింది. embedding_model_dims default గా 1536ను ఉపయోగిస్తుంది. nomic-embed-text 768ను తిరిగి ఇస్తుంది. అందువల్ల Postgres insert ను expected 1536 dimensions, not 768 తో తిరస్కరిస్తుంది. mem0 table ను CREATE TABLE IF NOT EXISTS తో సృష్టిస్తుంది. కాబట్టి ఇప్పటికే ఉన్న collection కోసం సంఖ్యను మాత్రమే మార్చడం వల్ల ప్రయోజనం ఉండదు. embedding_model_dims ను మీ model యొక్క నిజమైన width కు set చేయండి. /v1/embeddings ను call చేసి అది తిరిగి ఇచ్చే values ను లెక్కించడం ద్వారా ఆ width ను నిర్ధారించండి. అదే సమయంలో vector store కు కొత్త collection_name ఇవ్వండి.

VPSలో mem0 memory serverను నడపడానికి వాస్తవ RAM, localhostకు bind చేసే Compose ఫైల్, API ముందు TLS, మరియు Ollamaతో పూర్తిగా local మార్గాన్ని తెలుసుకోండి.

VPSలో mem0ను self-host చేయడానికి వాస్తవంగా అవసరమయ్యే RAM

mem0ను self-host చేయడం అంటే మూడు containers నడపడం: FastAPI memory server, pgvector extension కలిగిన Postgres, మరియు Next.js dashboard. mem0 agents కోసం memory layerగా పనిచేస్తుంది. మీరు దానికి ఒక conversationను పంపితే, language model ఆ conversation నుంచి దీర్ఘకాలం ఉపయోగపడే factsను వెలికితీస్తుంది. తరువాత queryకి సంబంధిత facts తిరిగి లభించేలా ఆ facts vectorsగా నిల్వ చేయబడతాయి.

మూడు containers కోసం resident memoryగా సుమారు 1 GB కేటాయించండి. Images build అయిన తర్వాత diskలో 3 నుంచి 4 GB అవసరం అవుతుంది. Language model వేరే చోట నడిస్తే, 2 GB VPS దీనిని సౌకర్యంగా నడపగలదు. అదే boxలో Ollama ద్వారా model నడిస్తే, మిగతా అన్నింటికంటే modelకే ఎక్కువ వనరులు అవసరం అవుతాయి: 4 bitsకు quantise చేసిన 8B modelకు మాత్రమే సుమారు 6 GB అవసరం అవుతుంది. అందువల్ల పూర్తిగా local buildకు కనీసం 8 GB అవసరం.

ఈ సంఖ్యలను, ఇందులోని blog post నుంచైనా, నేరుగా స్వీకరించవద్దు. మీరు వాస్తవంగా build చేసిన stackను కొలవండి.

docker compose ps
docker stats --no-stream
docker system df -v

docker stats ప్రతి containerకు సంబంధించిన resident memoryను చూపుతుంది. docker system df -v ప్రతి image మరియు volume ఉపయోగిస్తున్న disk స్థలాన్ని చూపుతుంది.

Steady state peak కాదు. docker compose up -d --build Next.js dashboardను compile చేస్తుంది. మొత్తం installationలో Node build సమయంలోనే అత్యధిక memory అవసరం అవుతుంది. 1 GB VPSలో kernel out-of-memory killer దాన్ని ఆపేస్తుంది. Build exit code 137తో ముగుస్తుంది. Docker bug కోసం వెతకడానికి ముందు కారణాన్ని నిర్ధారించండి:

dmesg -T | grep -i "killed process"

మీ అవసరాలకు server చాలా పెద్ద వ్యవస్థలా అనిపిస్తే, చిన్న ప్రత్యామ్నాయాలు అందుబాటులో ఉన్నాయి. server లేకుండా local agent memory store మరియు Claude Codeలోనే ఉండే memory రెండూ databaseను అవసరం లేకుండా చేస్తాయి. అనేక agents లేదా అనేక machines ఒకే memoriesను చదవాల్సినప్పుడు ఈ విధానానికి తిరిగి రండి.

mem0 graph memory కోసం Neo4j అవసరమా?

లేదు. Neo4j container జోడించమని ఏదైనా guide చెబితే, ఆ guide ప్రస్తుత code కంటే పాతది.

mem0లో graph memory అంటే గతంలో external graph database అని అర్థం. దీనిని graph_store key కింద configure చేసి, enable_graph ను trueగా సెట్ చేసేవారు. April 2026లో విడుదలైన కొత్త memory algorithm open source SDK నుంచి ఈ రెండు keysనూ తొలగించింది. ఇప్పుడు entity extraction సాధారణ add pathలోనే జరుగుతుంది. ఆ entitiesను ప్రధాన collection పేరుకు _entities జోడించిన పేరుతో రూపొందే రెండో pgvector collectionలో రాస్తుంది. ఎలాంటి migration అమలు చేయాల్సిన అవసరం లేదు. Built-in entity linking తదుపరి add call నుంచే పనిచేయడం ప్రారంభిస్తుంది.

Graph storeను తొలగించడం వల్ల ఒక JVM container, దాని heap, అలాగే కొన్ని వందల megabytes పరిమాణం ఉన్న image అవసరం ఉండదు. 2 GB VPSలో ఇది సేవ సక్రమంగా నడవడానికి మరియు swappingకు వెళ్లడానికి మధ్య ఉండే తేడా.

మీరు కోల్పోయేది ఏమిటో స్పష్టంగా చెప్పాలంటే: search resultsలో గతంలో entities మధ్య edgesను జాబితా చేసే relations field ఉండేది. ఆ field ఇప్పుడు లేదు. ఇప్పుడు entity matches combined scoreలో memory positionను పెంచుతాయి. Traverse చేయగల structure ఏదీ ఉండదు. మీ application ఆ relationshipsను ఉపయోగించి నడిచినట్లయితే, mem0 వాటిని ఇక నిల్వ చేయదు. అందువల్ల mem0 వెలుపల మీ స్వంత graph databaseను నిర్వహించి, మీ code ద్వారా దానికి data అందించాలి.

రెపోలోని compose ఫైల్ development compose ఫైల్.

server/docker-compose.yaml లో name: mem0-dev నిర్వచించబడింది. అది నిజంగానే అమలవుతుంది. దాన్ని run చేయడానికి ముందు చదవండి, ఎందుకంటే అందులో server కోసం తప్పుగా ఉన్న ఐదు విషయాలు ఉన్నాయి.

ఇది server/dev.Dockerfile నుంచి build అవుతుంది. అలాగే .:/app ద్వారా మీ checkout ను image పై mount చేస్తుంది. అందువల్ల container మీరు build చేసినదాన్ని కాకుండా ఆ directory లో ఉన్నదాన్ని run చేస్తుంది.
దీని command rm -rf /app/packages && pip install -q --force-reinstall --no-deps mem0ai && alembic upgrade head && uvicorn main:app --reload. ఇది ప్రతి start సమయంలో PyPI నుంచి mem0ai ను మళ్లీ install చేస్తుంది. అందువల్ల upgrade చేయాలని ఉద్దేశించని restart సమయంలో కూడా server run చేసే version మారవచ్చు.
అదే pip దశ కారణంగా outbound network లేకుండా చేసే restart, uvicorn run కావడానికి ముందే విఫలమవుతుంది. PyPI చేరుకోలేకపోవడం వల్ల మీ memory server down అవుతుంది.
--reload uvicorn file watcher ను start చేస్తుంది. మీరు code edit చేసినప్పుడు process ను restart చేయడానికి ఇది ఉద్దేశించబడింది. Production లో ఉపయోగం లేకపోయినా memory మరియు రెండవ process ఖర్చవుతాయి. Production Dockerfile లోని CMD లో కూడా --reload ఉంటుంది. కాబట్టి ఏ సందర్భంలోనైనా మీరు command ను override చేయాలి.
Published ports "8888:8000", "8432:5432" మరియు "3000:3000". ముందుగా address ఇవ్వని published port 0.0.0.0 కు bind అవుతుంది. అందువల్ల stack start అయిన వెంటనే Postgres 8432 port పై public internet కు అందుబాటులోకి వస్తుంది.

చివరి విషయం కోసం ప్రత్యేక హెచ్చరిక అవసరం. Docker, ufw నిర్వహించే chain కు ముందుగా తన స్వంత rules ను ఉంచడం ద్వారా port ను publish చేస్తుంది. అందువల్ల ufw deny 8432 published container port ను మూసివేయదు. Docker ports ను ufw ను దాటించి నేరుగా publish చేయడం లో సంబంధిత rules వివరించబడ్డాయి.

నిజమైన సర్వర్ కోసం compose file

server/ లో పని చేయండి. init-db.sh ఉన్న స్థానంలోనే ఉంచండి. దాని స్థానంలో దీనిని ఉంచడానికి docker-compose.yaml ను మార్చండి.

name: mem0

services:
  mem0:
    build:
      context: .
      dockerfile: Dockerfile
    restart: unless-stopped
    env_file: .env
    ports:
      - "127.0.0.1:8888:8000"
    networks: [mem0_network]
    volumes:
      - mem0_history:/app/history
    depends_on:
      postgres:
        condition: service_healthy
    command: >
      sh -c "alembic upgrade head &&
             uvicorn main:app --host 0.0.0.0 --port 8000"
    environment:
      - PYTHONUNBUFFERED=1
      - DASHBOARD_URL=https://mem0.example.com
      - APP_DB_NAME=mem0_app
      - AUTH_DISABLED=false
      - MEM0_TELEMETRY=false

  postgres:
    image: pgvector/pgvector:pg17
    restart: unless-stopped
    shm_size: "128mb"
    networks: [mem0_network]
    environment:
      - POSTGRES_USER=${POSTGRES_USER:-postgres}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in .env}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -q -U ${POSTGRES_USER:-postgres}"]
      interval: 5s
      timeout: 5s
      retries: 5
    volumes:
      - postgres_db:/var/lib/postgresql/data
      - ./init-db.sh:/docker-entrypoint-initdb.d/init-db.sh

  mem0-dashboard:
    build: ./dashboard
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    networks: [mem0_network]
    environment:
      - NEXT_PUBLIC_API_URL=https://mem0.example.com
      - API_INTERNAL_URL=http://mem0:8000
    depends_on:
      mem0:
        condition: service_started

volumes:
  postgres_db:
  mem0_history:

networks:
  mem0_network:
    driver: bridge

ఇక్కడ ఐదు మార్పులు ముఖ్యమైనవి. ప్రతి మార్పుకు ఒక కారణం ఉంది.

ప్రతి ports entry 127.0.0.1 తో ప్రారంభమవుతుంది. అందువల్ల kernel ఆ connections ను ఈ host నుంచే స్వీకరిస్తుంది. బయట నుంచి వచ్చే ప్రతిదీ reverse proxy ద్వారా వస్తుంది. certificate కలిగి ఉన్నది అదొక్కటే.

Postgres కు ports block ఏదీ లేదు. mem0 container service name ద్వారా mem0_network లో దాన్ని చేరుకుంటుంది. కాబట్టి 8432 ను publish చేయడం వల్ల ప్రయోజనం లేదు; బదులుగా ఒక open port అందుబాటులోకి వస్తుంది. Shell అవసరమైనప్పుడు docker compose exec postgres psql -U postgres ఉపయోగించండి.

చరిత్ర ./history bind mount నుంచి named volume కు మారుతుంది. Bind mount డేటాను ఈ host లోని ఒక path మరియు ఒక uid కు కట్టిపడేస్తుంది. Named volume ను Docker snapshot తీసి తరలించగల object గా నిర్వహిస్తుంది. ప్రతి దాన్ని ఎప్పుడు ఉపయోగించాలో Named volumes మరియు bind mounts లో వివరించబడింది.

Command --reload ను తొలగించి alembic upgrade head ను ఉంచుతుంది. ఈ migration దశను ఉంచండి. అది లేకపోతే app tables లేని database పై ప్రారంభమవుతుంది. అప్పుడు ప్రతి request మొదటి query వద్ద విఫలమవుతుంది.

NEXT_PUBLIC_API_URL అనేది మీ browser call చేసే URL. కాబట్టి అది http://mem0:8000 కాకుండా public HTTPS address అయి ఉండాలి. Next.js ప్రతి NEXT_PUBLIC_ value ను build time లోనే JavaScript లోకి చేర్చుతుంది. అందువల్ల దాన్ని మార్చాలంటే docker compose up -d --build mem0-dashboard అవసరం. సాధారణ restart చేస్తే JavaScript లో పాత value అలాగే ఉంటుంది. అప్పుడు dashboard తప్పు host కు calls చేస్తుంది.

Secrets `.env` లో ఉంటాయి, `.env` ఇంటర్నెట్‌కు అందుబాటులో ఉండదు

cd server
cp .env.example .env
openssl rand -hex 32    # paste into JWT_SECRET
openssl rand -hex 32    # paste into ADMIN_API_KEY
chmod 600 .env

POSTGRES_PASSWORD, JWT_SECRET మరియు ADMIN_API_KEY సెట్ చేయండి. AUTH_DISABLED=false ను అలాగే ఉంచండి. ఆ flag ఏమి చేస్తుందో దాని పేరు స్పష్టంగా చెబుతుంది: దీన్ని enable చేస్తే, port కు చేరగల ఎవరైనా server వద్ద ఉన్న మొత్తం memory ను పొందగలరు. onboarding event ను upstream కు పంపకూడదనుకుంటే MEM0_TELEMETRY=false సెట్ చేయండి.

ADMIN_API_KEY ను X-API-Key header తో secrets.compare_digest ద్వారా పోల్చుతారు. విలువ సరిపోతే అన్ని database lookup లు దాటవేయబడతాయి. ఇది మొత్తం API కు root credential. అందువల్ల దీన్ని కూడా root credential లాగానే రక్షించండి: shell history లో ఉంచకండి, git లో commit చేయకండి, prompt లో paste చేయకండి. Compose env files మరియు వాటి నుంచి secrets ఎలా బయటకు లీక్ అవుతాయి మరియు API keys ను agent context కు దూరంగా ఉంచడం రెండూ ఇక్కడ నేరుగా వర్తిస్తాయి, ఎందుకంటే ఈ server ను పిలిచేవి agents.

env_file నుంచి load చేసిన values container environment లో ఉంటాయి. docker inspect వాటిని పూర్తిగా ప్రింట్ చేస్తుంది. docker group లో ఉన్న ఎవరైనా వాటిని చదవగలరు. docker group లో ఉన్న ఎవరైనా host పై వాస్తవంగా root అధికారాలను కలిగి ఉంటారు.

API కోసం 8888 port ను తెరవకుండా దాని ముందు TLS ఉంచండి

API 127.0.0.1:8888 పై, dashboard 127.0.0.1:3000 పై స్పందిస్తాయి. nginx 443 పై TLS (transport layer security) ను terminate చేసి, అభ్యర్థనలను రెండింటికీ forward చేస్తుంది.

server {
    listen 443 ssl;
    server_name mem0.example.com;

    ssl_certificate     /etc/letsencrypt/live/mem0.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mem0.example.com/privkey.pem;

    location ~ ^/(memories|search|configure|auth|api-keys|docs|openapi.json) {
        proxy_pass http://127.0.0.1:8888;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 180s;
    }

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

proxy_read_timeout కనిపించేదానికంటే ఎక్కువ ప్రాధాన్యం కలిగి ఉంది. Language model conversation ను చదివి facts ను వెలికితీసే సమయంలో add call block అవుతుంది. CPUపై నడిచే local 8B model కు nginx యొక్క 60 second default సమయం కంటే ఎక్కువ సమయం తరచుగా పడుతుంది. అప్పుడు model ఇంకా పని చేస్తున్నప్పటికీ, memory మాత్రం వ్రాయబడుతూనే ఉంటుంది; caller కు 504 Gateway Time-out కనిపిస్తుంది. విఫలమైందని మీకు తెలియజేసిన memory చివరకు సృష్టించబడుతుంది.

మిగిలిన traffic ను default deny ufw policy తో నిరోధించండి. 22 మరియు 443 ports ను మాత్రమే open గా ఉంచండి. nginx వెనుక Ubuntu 24.04లో certbotతో certificate జారీ చేయండి. ఈ server ఇప్పటికే అనేక Compose apps కు Traefik routing ద్వారా ఇతర apps ను ముందుకు పంపిస్తుంటే, రెండవ proxy ను install చేయకుండా అదే router కు mem0 ను జోడించండి.

ఒక memory జోడించి, దాన్ని తిరిగి చదివే Smoke test

export MEM0_KEY='<the ADMIN_API_KEY from .env>'

curl -sS -X POST http://127.0.0.1:8888/memories \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $MEM0_KEY" \
  -d '{"messages":[{"role":"user","content":"I deploy with Docker Compose and I run Postgres 17."}],"user_id":"smoke"}'

సరైన response అనేది results list కలిగిన JSON object అయి ఉంటుంది. ప్రతి entry లో id, సేకరించిన memory text, మరియు "event": "ADD" ఉంటాయి. ప్రస్తుత algorithm ADD events ను మాత్రమే తిరిగి ఇస్తుంది. UPDATE మరియు DELETE events తొలగించబడ్డాయి. అందువల్ల అవి లేకపోవడం bug కాదు.

curl -sS -X POST http://127.0.0.1:8888/search \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $MEM0_KEY" \
  -d '{"query":"which database do I run?","filters":{"user_id":"smoke"},"top_k":5}'

Postgres 17 గురించిన fact score తో తిరిగి రావాలి. చూపించిన విధంగా identifier ను filters లో పంపండి. Top-level user_id ఇప్పటికీ పనిచేస్తుంది. మీరు దాన్ని ఉపయోగించిన ప్రతిసారీ server Top-level user_id in /search is deprecated. Use filters={...} instead. ను logs లో నమోదు చేస్తుంది.

Test data వాస్తవ searches ను ప్రభావితం చేయకుండా, పని పూర్తయ్యాక దాన్ని తొలగించండి:

curl -sS -X DELETE "http://127.0.0.1:8888/memories?user_id=smoke" \
  -H "X-API-Key: $MEM0_KEY"

మీరు ఆశించిన దానికంటే search తక్కువ rows ను తిరిగి ఇస్తే, retrieval ను నిందించే ముందు defaults ను పరిశీలించండి. ప్రస్తుత release లో top_k default గా 20 గా ఉంది; ఇది మునుపటి 100 నుండి తగ్గింది. అలాగే threshold default గా none కాకుండా 0.1 గా ఉంది. అందువల్ల బలహీనమైన matches ఇప్పుడు మీ కోసం filter అవుతాయి. ఇది curl ద్వారా పనిచేసిన తర్వాత, అదే endpoints ను agent కు wire చేయవచ్చు. దీన్ని నేరుగా చేయవచ్చు లేదా అదే VPS పై నడుస్తున్న MCP server ద్వారా చేయవచ్చు.

OpenAI key లేకుండా mem0 ను అమలు చేయడం

మొదట అడ్డంకిని పరిష్కరించండి, ఎందుకంటే మొదటి ఐదు నిమిషాల్లోనే ఇది ఎదురవుతుంది. Server image లో provider libraries యొక్క స్థిరమైన సమితి ఉంటుంది. /configure ఆ సమితికి వెలుపల ఉన్న వాటిని తిరస్కరిస్తుంది:

LLM provider 'ollama' is not bundled in this image. Bundled providers: openai, anthropic, gemini. To use another provider, install its Python package, rebuild the container, and extend BUNDLED_LLM_PROVIDERS in server/main.py.

మీరు ఏదీ మళ్లీ build చేయాల్సిన అవసరం లేదు. Ollama /v1 వద్ద OpenAI-compatible API అందిస్తుంది. ఇది /v1/chat/completions మరియు /v1/embeddings ను కవర్ చేస్తుంది. mem0 యొక్క openai provider ఒక openai_base_url ను అంగీకరిస్తుంది. ఆ key ను Ollama వైపు చూపించండి. అప్పుడు bundled check విజయవంతమవుతుంది, ఎందుకంటే provider వాస్తవంగా openai. మారేది address మాత్రమే.

అదే Compose project కు Ollama ను జోడించండి:

  ollama:
    image: ollama/ollama
    restart: unless-stopped
    networks: [mem0_network]
    ports:
      - "127.0.0.1:11434:11434"
    volumes:
      - ollama_models:/root/.ollama

Top-level volumes: key కింద ollama_models: ను జోడించండి. తరువాత ఒక chat model మరియు ఒక embedding model ను pull చేయండి:

docker compose up -d ollama
docker compose exec ollama ollama pull llama3.1:8b
docker compose exec ollama ollama pull nomic-embed-text

VPS పై Ollama ను నేరుగా నడిపిస్తున్నట్లు Ollama ఇప్పటికే host పై systemd unit గా నడుస్తుంటే, container ను 127.0.0.1:11434 వైపు చూపించవద్దు. mem0 container లో 127.0.0.1 అనేది mem0 container నే సూచిస్తుంది. mem0 service కు extra_hosts: ["host.docker.internal:host-gateway"] ఇవ్వండి. Ollama bridge చేరగల address పై listen చేసేలా systemd drop-in లో Environment="OLLAMA_HOST=0.0.0.0:11434" ను సెట్ చేయండి. Firewall లో 11434 port ను మూసి ఉంచండి.

ఏదైనా configure చేయడానికి ముందు model యొక్క embedding dimension ను అడగండి

Retrieval అసలు పనిచేస్తుందా లేదా అనేది ఈ ఒక్క దశ నిర్ణయిస్తుంది.

mem0 యొక్క pgvector store ఒక fixed vector width తో తన table ను సృష్టిస్తుంది: vector vector(1536). ఎందుకంటే embedding_model_dims కు default విలువ 1536, ఇది OpenAI యొక్క text-embedding-3-small width. nomic-embed-text 768 values ను తిరిగి ఇస్తుంది. mem0 లో ఈ రెండు సంఖ్యలను పోల్చే logic లేదు. అందువల్ల మొదటి insert సమయంలో Postgres నుండి mismatch error వస్తుంది:

expected 1536 dimensions, not 768

ఈ paragraph లోని సంఖ్యను కూడా నమ్మవద్దు. Model ను అడగండి:

curl -sS http://127.0.0.1:11434/v1/embeddings \
  -H "Content-Type: application/json" \
  -d '{"model":"nomic-embed-text","input":"dimension check"}' \
  | python3 -c "import json,sys; print(len(json.load(sys.stdin)['data'][0]['embedding']))"

మీ collection ఉపయోగించాల్సిన width ను ఇది ముద్రిస్తుంది. Configuration ను ఒక file లో రాయండి. Shell quoting ద్వారా Postgres password ను paste చేయడం వల్ల production లో typos చేరుతాయి.

{
  "vector_store": {
    "provider": "pgvector",
    "config": {
      "host": "postgres",
      "port": 5432,
      "dbname": "postgres",
      "user": "postgres",
      "password": "<POSTGRES_PASSWORD from .env>",
      "collection_name": "memories_local_768",
      "embedding_model_dims": 768
    }
  },
  "llm": {
    "provider": "openai",
    "config": {
      "model": "llama3.1:8b",
      "api_key": "ollama",
      "openai_base_url": "http://ollama:11434/v1",
      "temperature": 0.2
    }
  },
  "embedder": {
    "provider": "openai",
    "config": {
      "model": "nomic-embed-text",
      "api_key": "ollama",
      "openai_base_url": "http://ollama:11434/v1"
    }
  }
}

curl -sS -X POST http://127.0.0.1:8888/configure \
  -H "Content-Type: application/json" \
  -H "X-API-Key: $MEM0_KEY" \
  -d @config.json

curl -sS http://127.0.0.1:8888/configure -H "X-API-Key: $MEM0_KEY"

రెండవ call configuration ను తిరిగి చదువుతుంది. Write సరిగ్గా జరిగిందా లేదా నిర్ధారించడానికి ఇదే check. తరువాత పై smoke test ను మళ్లీ అమలు చేయండి.

ఆ JSON లో నాలుగు వివరాలు స్పష్టంగా కనిపించవు. వాటిలో ప్రతి ఒక్కదాన్ని తప్పుగా సెట్ చేస్తే ఏదో ఒకటి విఫలమవుతుంది.

api_key అనేది ollama string. Ollama దాని value ను పట్టించుకోదు. ఇది ఖాళీగా ఉండకూడదు. Key సెట్ చేయకపోతే ఏ request process నుంచి బయటకు వెళ్లకముందే OpenAI client library error ఇస్తుంది. ఖాళీ కాని ఏ string అయినా పనిచేస్తుంది.

embedding_model_dims ను vector store పై ఉంచాలి. Embedder పై embedding_dims ఉద్దేశపూర్వకంగా ఉండదు. embedding_dims ను సెట్ చేసినప్పుడు మాత్రమే mem0 OpenAI dimensions parameter ను పంపుతుంది. Matryoshka truncation ను అమలు చేయని backends ఆ parameter ను నేరుగా తిరస్కరిస్తాయి. Table సృష్టించే చోట width ను సెట్ చేయండి. Embedder ను అలాగే ఉంచండి.

collection_name కొత్తది. mem0 తన table ను CREATE TABLE IF NOT EXISTS తో సృష్టిస్తుంది. అందువల్ల వేరే width ను ఇప్పటికే ఉన్న collection కు చూపించడం వల్ల ఎలాంటి మార్పూ జరగదు. పాత vector(1536) column అలాగే ఉంటుంది. ప్రతి insert విఫలమవుతుంది. Width మార్చాలంటే కొత్త collection name అవసరం. లేకపోతే పాత table ను మాన్యువల్‌గా drop చేయాలి.

openai_base_url లోని host Compose service name ollama. అది localhost కాదు. Shared network లో containers ఒకదానినొకటి service name ద్వారా resolve చేసుకుంటాయి.

పూర్తిగా local మార్గానికి అయ్యే ఖర్చు

Quality గురించి వాస్తవికంగా అంచనా వేయండి. mem0 ప్రచురించిన benchmark scores extraction చేసే frontier models తో కొలిచినవి. అందువల్ల వాటిని VPS పై నడిచే 8B model కోసం forecast గా కాకుండా ceiling గా పరిగణించండి. చిన్న model మరింత అస్పష్టమైన facts రాస్తుంది. కొన్నిసార్లు JSON కోరినప్పుడు prose ను తిరిగి ఇస్తుంది. దీని ఫలితంగా error లేకుండానే add call ఖాళీ results list ను తిరిగి ఇవ్వవచ్చు.

Speed మరో ఖర్చు. CPU మాత్రమే ఉపయోగించి చేసే extraction కు ప్రతి add call పై కొన్ని seconds పడుతుంది. మీరు store చేసే ప్రతి message కు ఈ ఖర్చు ఉంటుంది. ఆ latency ముఖ్యమైతే, GPU అనుసంధానించిన VPS సరైన పరిష్కారం. 8B model కు మరిన్ని CPU cores ఇవ్వడం వల్ల ప్రజలు ఆశించేంతగా పనితీరు మెరుగుపడదు.

మీరు ఏదిని ఎంచుకున్నా ఒక నియమం మారదు: ఒకే collection లో embedding models ను ఎప్పుడూ కలపవద్దు. ఒకే width కలిగి ఉన్నా, రెండు వేర్వేరు models ఉత్పత్తి చేసే vectors పరస్పరం పోల్చదగినవి కావు. Insert విజయవంతమవుతుంది. Search rows ను తిరిగి ఇస్తుంది. కానీ ఆ rows తప్పుగా ఉంటాయి. ఎక్కడా error report కాదు.

Backups: ఒకటి కాదు, రెండు databases

mem0 backup లో అత్యంత సాధారణమైన తప్పు ఒకే database ను dump చేయడం. init-db.sh, default postgres database తో పాటు mem0_app ను కూడా సృష్టిస్తుంది. ఈ రెండింటిలో వేర్వేరు data ఉంటుంది. postgres database లో memories అయిన pgvector collections ఉంటాయి. mem0_app లో users, sessions, API keys, request logs ఉంటాయి.

postgres ను మాత్రమే restore చేస్తే memories తిరిగి వస్తాయి. కానీ ప్రతి account మరియు API key తొలగిపోతాయి. అందువల్ల వాటిని చదవడానికి ఏదీ authenticate కాలేదు. ఒకే command తో రెండు databases తో పాటు roles ను కూడా dump చేయండి:

docker compose exec -T postgres pg_dumpall -U postgres --clean \
  | gzip > "mem0-$(date +%F).sql.gz"

history volume Postgres కు వేరుగా ఉంటుంది. దానికి ప్రత్యేక copy అవసరం:

docker run --rm -v mem0_mem0_history:/data -v "$PWD:/backup" \
  alpine tar czf /backup/mem0-history.tgz -C /data .

Docker volume పేర్లకు project name ను prefix గా జతచేస్తుంది. కాబట్టి mem0_mem0_history ను ఊహించేముందు docker volume ls తో మీ volume పేరును నిర్ధారించండి.

డేటా అంతా సరిగ్గా ఉందని నమ్మే ముందు, దాన్ని ఒక scratch container లో restore చేసి row counts ను పరిశీలించండి:

gunzip -c mem0-2026-08-03.sql.gz \
  | docker compose exec -T postgres psql -U postgres -d postgres

మీరు ఎప్పుడూ restore చేయని backup కేవలం ఒక అంచనా మాత్రమే. Dumps సరిగ్గా ఉన్నాయని నిర్ధారించిన తర్వాత, వాటిని off-site storage కు restic snapshots తో server వెలుపలికి పంపండి. ఎందుకంటే రక్షించాల్సిన అదే server పై ఉన్న backup ఏదీ రక్షించదు.

వైఫల్య పరిస్థితులు మరియు మీరు ఖచ్చితంగా చూసే strings

{"detail":"Authentication required. Provide a Bearer token or X-API-Key header."} అంటే header లేదు లేదా తప్పుగా రాశారు. పేరు X-API-Key, మరియు curl header పేర్లను యథాతథంగా పంపుతుంది.

Add సమయంలో {"detail":"At least one identifier (user_id, agent_id, run_id) is required."} కనిపిస్తే, ఆ request లో వాటిలో ఏదీ లేదు. Memory ను ఏదో ఒక పరిధికి కట్టాలి, ఎందుకంటే search సరిగ్గా ఆ fields ఆధారంగానే filter చేస్తుంది.

HTTP 400 తో LLM provider 'ollama' is not bundled in this image కనిపిస్తే, మీరు "provider": "ollama" పంపారు. Ollama ను లక్ష్యంగా చూపించే openai_base_url తో "provider": "openai" ఉపయోగించండి.

Postgres నుంచి expected 1536 dimensions, not 768 వస్తే, collection ఒక width తో సృష్టించబడింది, కానీ embedder వేరే width ను అందిస్తోంది. Vector store పై embedding_model_dims సెట్ చేసి, కొత్త collection_name ఉపయోగించండి.

Model మార్చిన తర్వాత, ఎక్కడా error లేకుండానే అర్థం లేని rows ను search తిరిగి ఇస్తుంది. Width సరిపోతూనే ఉంటుంది కాబట్టి database కు సమస్య కనిపించదు. కానీ రెండు models ఒకే sentence ను వేర్వేరు స్థానాల్లో ఉంచుతాయి. కొత్త collection ప్రారంభించి, entries ను మళ్లీ add చేయండి.

Ollama ను చేరుకునే సమయంలో mem0 logs లో Connection refused కనిపిస్తే, సాధారణంగా openai_base_url లోని 127.0.0.1 అని అర్థం. Container లోపల ఆ address container నే సూచిస్తుంది. Service name ను ఉపయోగించండి. Ollama host పై నడుస్తుంటే host gateway ను ఉపయోగించండి.

Add సమయంలో nginx నుంచి 504 Gateway Time-out వస్తే, model కు proxy_read_timeout కంటే ఎక్కువ సమయం పట్టింది. దాని విలువను పెంచండి. Retry చేయడానికి ముందు memory రాయబడిందో లేదో పరిశీలించండి.

docker compose up --build సమయంలో exit code 137 కనిపిస్తే, dashboard build ను out-of-memory killer ఆపుతోంది. Swap జోడించండి. లేదా పెద్ద machine పై image ను build చేసి registry కు push చేయండి.

error: port 3000 is already in use repo లోని make up target నుంచి వస్తుంది. 3000 లేదా 8888 ఇప్పటికే ఉపయోగంలో ఉన్నప్పుడు అది start కావడానికి నిరాకరిస్తుంది. యజమానిని lsof -iTCP:3000 -sTCP:LISTEN తో కనుగొనండి.

FAQ

mem0 ను graph memory తో నడపడానికి ఇంకా Neo4j అవసరమా?

లేదు. April 2026లో విడుదలైన కొత్త memory algorithm open source SDK నుంచి graph_store మరియు enable_graph configuration keys ను తొలగించింది. ఇప్పుడు సాధారణ add సమయంలోనే entity extraction జరుగుతుంది. ఇది <collection_name>_entities పేరుతో ఉన్న రెండో pgvector collection లో రాస్తుంది. అందువల్ల external graph database, అదనపు container లేదా migration step అవసరం లేదు. అయితే search results లోని relations field ఇక ఉండదు. ఇప్పుడు entities memory ranking ను పెంచుతాయి; traverse చేయడానికి edges ఇవ్వవు. కాబట్టి ఆ relationships ను traverse చేసిన application కు mem0 వెలుపల స్వంత graph store అవసరం.

self-hosted mem0 server ను నడపగల అతి చిన్న VPS ఏది?

language model ను వేరే చోట host చేస్తే, API container, Postgres మరియు dashboard కోసం 2 GB RAM, సుమారు 4 GB ఖాళీ disk సరిపోతాయి. మొదటి build సమయంలో వనరుల కొరత ఎక్కువగా ఉంటుంది. కారణం, Next.js dashboard ను compile చేయడానికి దాన్ని run చేయడం కంటే ఎక్కువ memory అవసరం. 1 GB box లో build exit code 137 తో kill అవుతుంది. Ollama అదే server పై నడిస్తే, model ఆధారంగా పరిమాణాన్ని నిర్ణయించండి. 4-bit quantisation ఉన్న 8B model కు దానికోసమే సుమారు 6 GB అవసరం. అందువల్ల 8 GB కోసం ప్రణాళిక చేయండి.

OpenAI API key లేకుండా mem0 ను నడపవచ్చా?

అవును. Ollama యొక్క OpenAI compatible endpoint ద్వారా నడపవచ్చు. "provider": "ollama" ను set చేస్తే విఫలమవుతుంది. కారణం, server image లో openai, anthropic మరియు gemini libraries మాత్రమే bundled గా ఉంటాయి. అది HTTP 400 ను తిరిగి ఇస్తుంది. బదులుగా "provider": "openai" ను అలాగే ఉంచి, llm మరియు embedder రెండింటికీ ఏదైనా non empty api_key తో "openai_base_url": "http://ollama:11434/v1" ను set చేయండి. Ollama key ను పట్టించుకోదు. Provider నిజంగా openai కావడంతో bundled provider check విజయవంతమవుతుంది.

local embedding model కు మారిన తర్వాత mem0 ఎలాంటి results ఎందుకు ఇవ్వదు?

pgvector table fixed width తో సృష్టించబడింది. embedding_model_dims default గా 1536ను ఉపయోగిస్తుంది. nomic-embed-text 768ను తిరిగి ఇస్తుంది. అందువల్ల Postgres insert ను expected 1536 dimensions, not 768 తో తిరస్కరిస్తుంది. mem0 table ను CREATE TABLE IF NOT EXISTS తో సృష్టిస్తుంది. కాబట్టి ఇప్పటికే ఉన్న collection కోసం సంఖ్యను మాత్రమే మార్చడం వల్ల ప్రయోజనం ఉండదు. embedding_model_dims ను మీ model యొక్క నిజమైన width కు set చేయండి. /v1/embeddings ను call చేసి అది తిరిగి ఇచ్చే values ను లెక్కించడం ద్వారా ఆ width ను నిర్ధారించండి. అదే సమయంలో vector store కు కొత్త collection_name ఇవ్వండి.

#mem0 #agent-memory #docker #self-hosting #ollama

VPSలో mem0ను self-host చేయడానికి వాస్తవంగా అవసరమయ్యే RAM

mem0 graph memory కోసం Neo4j అవసరమా?

రెపోలోని compose ఫైల్ development compose ఫైల్.

నిజమైన సర్వర్ కోసం compose file

Secrets .env లో ఉంటాయి, .env ఇంటర్నెట్‌కు అందుబాటులో ఉండదు

API కోసం 8888 port ను తెరవకుండా దాని ముందు TLS ఉంచండి

ఒక memory జోడించి, దాన్ని తిరిగి చదివే Smoke test

OpenAI key లేకుండా mem0 ను అమలు చేయడం

ఏదైనా configure చేయడానికి ముందు model యొక్క embedding dimension ను అడగండి

పూర్తిగా local మార్గానికి అయ్యే ఖర్చు

Backups: ఒకటి కాదు, రెండు databases

వైఫల్య పరిస్థితులు మరియు మీరు ఖచ్చితంగా చూసే strings

FAQ

mem0 ను graph memory తో నడపడానికి ఇంకా Neo4j అవసరమా?

self-hosted mem0 server ను నడపగల అతి చిన్న VPS ఏది?

OpenAI API key లేకుండా mem0 ను నడపవచ్చా?

local embedding model కు మారిన తర్వాత mem0 ఎలాంటి results ఎందుకు ఇవ్వదు?

Secrets `.env` లో ఉంటాయి, `.env` ఇంటర్నెట్‌కు అందుబాటులో ఉండదు