ஆல் Matt Connor 2026-08-03 · புதுப்பிக்கப்பட்டது 2026-08-13

VPS-ல் mem0-வை self-host செய்வது எப்படி?

VPS-ல் mem0-வை இயக்கத் தேவையான 1GB RAM அளவு, Docker Compose கட்டமைப்பு, TLS பாதுகாப்பு மற்றும் Ollama மூலம் உள்ளூர் LLM-ஐ இணைக்கும் முறையை இந்த வழிகாட்டியில் விரிவாகக் காண்போம்.

VPS-ல் mem0-வை self-host செய்வதற்குத் தேவையான RAM அளவு

mem0-வை self-host செய்வது என்பது மூன்று containers-ஐ இயக்குவதாகும்: FastAPI memory server, pgvector extension கொண்ட Postgres, மற்றும் ஒரு Next.js dashboard. mem0 என்பது agents-க்கான ஒரு memory layer ஆகும். நீங்கள் ஒரு உரையாடலை அதற்கு அனுப்பும்போது, ஒரு language model அந்த உரையாடலில் உள்ள நீடித்த உண்மைகளை (durable facts) பிரித்தெடுக்கும்; அந்த உண்மைகள் vectors-ஆகச் சேமிக்கப்படும், இதனால் பிற்காலத்தில் தேவைப்படும்போது தொடர்புடைய தகவல்களை மீட்டெடுக்க முடியும்.

இந்த மூன்று containers-க்கும் தோராயமாக 1 GB resident memory-ஐயும், images build செய்யப்பட்ட பிறகு 3 முதல் 4 GB disk இடத்தையும் ஒதுக்கீடு செய்யவும். language model வேறொரு இடத்தில் இயங்கும்போது, 2 GB VPS-ல் இதைச் சிறப்பாக இயக்க முடியும். Ollama மூலம் அதே server-ல் model இயங்கினால், அதுவே அதிக வளங்களை எடுத்துக்கொள்ளும்: 4 bits-க்கு quantise செய்யப்பட்ட ஒரு 8B model-க்கு மட்டும் சுமார் 6 GB தேவைப்படும், எனவே முழுமையான local build-க்கு 8 GB-லிருந்து தொடங்க வேண்டும்.

இந்தக் கட்டுரை உட்பட எந்தவொரு blog post-ல் உள்ள புள்ளிவிவரங்களையும் அப்படியே நம்ப வேண்டாம். நீங்கள் உருவாக்கிய 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 என்பது உச்சகட்ட பயன்பாடு அல்ல. docker compose up -d --build கட்டளையானது Next.js dashboard-ஐ compile செய்யும், அந்த Node build நேரமே முழு நிறுவலின் மிக அதிக வளங்களை நுகரும் தருணமாகும். 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 ஒரே memory-ஐப் பகிர வேண்டிய சூழல் வரும்போது மீண்டும் இங்கே வரவும்.

mem0 graph memory-க்கு எனக்கு Neo4j தேவையா?

இல்லை. ஒரு வழிகாட்டி Neo4j container-ஐ சேர்க்கச் சொன்னால், அந்த வழிகாட்டி தற்போதைய code-ஐ விட பழையது என்று அர்த்தம்.

mem0-ல் graph memory என்பது முன்பு ஒரு external graph database-ஐக் குறித்தது; இது graph_store key-ன் கீழ் enable_graph-ஐ true என அமைப்பதன் மூலம் செயல்பட்டது. ஏப்ரல் 2026-ல் வெளியிடப்பட்ட புதிய memory algorithm, இந்த இரண்டு key-களையும் open source SDK-லிருந்து நீக்கிவிட்டது. Entity extraction இப்போது சாதாரண add path-க்குள்ளேயே இயங்குகிறது. Entities உங்கள் முதன்மை pgvector collection-ன் பெயருடன் _entities சேர்க்கப்பட்டு, இரண்டாவது collection-ல் எழுதப்படுகின்றன. நீங்கள் எந்த migration-ம் செய்ய வேண்டியதில்லை. அடுத்த add call-லிருந்து உள்ளமைக்கப்பட்ட entity linking தானாகவே செயல்படத் தொடங்கும்.

Graph store-ஐ நீக்குவது ஒரு JVM container, அதன் heap மற்றும் பல நூறு megabytes அளவுள்ள image-ஐச் சேமிக்கிறது. 2 GB VPS-ல் இதுவே service இயங்குவதற்கும், swapping நடப்பதற்கும் உள்ள வித்தியாசமாகும்.

இதன் மூலம் நீங்கள் எதை இழக்கிறீர்கள் என்பதைத் தெளிவாகக் கீழே காணலாம். முன்பு search results-ல் entities-க்கு இடையிலான edges-ஐக் காட்டும் relations field இருந்தது. அந்த field இப்போது இல்லை. Entity matches இப்போது memory-ன் நிலையை combined score-ல் உயர்த்துகின்றன, ஆனால் நீங்கள் traverse செய்யக்கூடிய கட்டமைப்பு எதுவும் இல்லை. உங்கள் application அந்த உறவுகளைப் பயன்படுத்தியிருந்தால், mem0-ல் அவை இனி இருக்காது. நீங்கள் mem0-க்கு வெளியே உங்கள் சொந்த code மூலம் இயங்கும் ஒரு graph database-ஐ வைத்திருக்க வேண்டும்.

களஞ்சியத்தில் உள்ள compose கோப்பு ஒரு மேம்பாட்டு (development) compose ஆகும்

server/docker-compose.yaml, name: mem0-dev-ஐ அறிவிக்கிறது, இது அதன் பொருளை உணர்த்துகிறது. நீங்கள் அதை இயக்குவதற்கு முன் படியுங்கள், ஏனெனில் அதில் உள்ள ஐந்து விஷயங்கள் ஒரு server-க்கு தவறானவை.

இது server/dev.Dockerfile-லிருந்து build செய்கிறது மற்றும் .:/app மூலம் உங்கள் checkout-ஐ image-ன் மேல் mount செய்கிறது. எனவே, நீங்கள் build செய்ததை விட அந்த directory-ல் என்ன இருக்கிறதோ அதையே container இயக்குகிறது.
அதன் கட்டளை rm -rf /app/packages && pip install -q --force-reinstall --no-deps mem0ai && alembic upgrade head && uvicorn main:app --reload ஆகும். இது ஒவ்வொரு தொடக்கத்திலும் PyPI-லிருந்து mem0ai-ஐ மீண்டும் நிறுவுகிறது. எனவே, நீங்கள் upgrade என்று நினைக்காத ஒரு restart-ன் போது உங்கள் server இயக்கும் பதிப்பு மாறக்கூடும்.
அதே pip படிநிலை, வெளிச்செல்லும் network இல்லாத ஒரு restart, uvicorn இயங்குவதற்கு முன்பே தோல்வியடையும் என்று அர்த்தம். PyPI-ஐ அணுக முடியாததால் உங்கள் memory server செயலிழந்துவிடும்.
--reload, uvicorn-ன் file watcher-ஐத் தொடங்குகிறது. நீங்கள் code-ஐ மாற்றும்போது process-ஐ restart செய்ய இது உள்ளது. production-ல் இது எந்தப் பயனும் தராமல் memory-ஐயும், கூடுதல் process-ஐயும் செலவழிக்கிறது. production Dockerfile-ம் அதன் CMD-ல் --reload-ஐக் கொண்டுள்ளது, எனவே நீங்கள் எப்படியும் கட்டளையை override செய்கிறீர்கள்.
வெளியிடப்பட்ட ports "8888:8000", "8432:5432" மற்றும் "3000:3000" ஆகும். முன்னால் முகவரி இல்லாத ஒரு வெளியிடப்பட்ட port, 0.0.0.0-ஐ பிணைக்கிறது (bind). எனவே, stack தொடங்கியவுடன் Postgres 8432 port-ல் பொது இணையத்திற்குப் பதிலளிக்கும்.

அந்த கடைசி புள்ளி தனி எச்சரிக்கைக்கு உரியது. Docker ஒரு port-ஐ வெளியிடும்போது, ufw நிர்வகிக்கும் chain-க்கு முன்னால் அதன் சொந்த விதிகளை எழுதுகிறது. எனவே, ufw deny 8432 ஒரு வெளியிடப்பட்ட container port-ஐ மூடாது. Docker publishing ports straight past ufw இதில் உள்ள விதிகளை விளக்குகிறது.

உண்மையான server-க்கான 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 உள்ளீடும் 127.0.0.1-ல் தொடங்குகிறது, எனவே kernel அந்த இணைப்புகளை அந்த server-லிருந்து மட்டுமே ஏற்கும். வெளியிலிருந்து வரும் அனைத்தும் reverse proxy வழியாகவே வரும், அது மட்டுமே certificate-ஐக் கொண்டிருக்கும்.

Postgres-ல் ports பகுதி எதுவும் இல்லை. mem0 container அதை mem0_network வழியாக service பெயர் மூலம் அணுகுகிறது, எனவே 8432 port-ஐ வெளியிடுவதால் எந்தப் பயனும் இல்லை, மாறாக ஒரு open port மட்டுமே மிஞ்சும். shell தேவைப்படும்போது docker compose exec postgres psql -U postgres-ஐப் பயன்படுத்தவும்.

History தரவு ./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 படியைத் தக்கவைக்கவும். அது இல்லையென்றால், tables இல்லாத database-உடன் app தொடங்கும், மேலும் ஒவ்வொரு request-ம் முதல் query-லேயே தோல்வியடையும்.

NEXT_PUBLIC_API_URL என்பது உங்கள் browser அழைக்கும் URL ஆகும், எனவே அது http://mem0:8000 ஆக இல்லாமல், public HTTPS முகவரியாக இருக்க வேண்டும். Next.js ஒவ்வொரு NEXT_PUBLIC_ மதிப்பையும் build நேரத்திலேயே உள்ளிணைத்துவிடும் (inline), எனவே அதை மாற்ற docker compose up -d --build mem0-dashboard தேவை. சாதாரண restart செய்தால் பழைய மதிப்பு JavaScript-ல் அப்படியே இருக்கும், dashboard தவறான host-ஐ அழைக்கும்.

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 என்ன செய்கிறது என்பதை அதன் பெயரே தெளிவாகக் கூறுகிறது: அதை இயக்கும்போது, அந்த port-ஐ அணுகக்கூடிய எவருக்கும் server தனது நினைவகத்தில் (memory) உள்ள அனைத்தையும் வழங்கிவிடும். onboarding நிகழ்வு upstream-க்கு அனுப்பப்படக்கூடாது எனில் MEM0_TELEMETRY=false-ஐ அமைக்கவும்.

ADMIN_API_KEY என்பது secrets.compare_digest உடன் X-API-Key header-ஐ ஒப்பிடுகிறது, இதில் பொருத்தம் இருந்தால் database தேடல் தவிர்க்கப்படும். இது முழு API-க்கும் ஒரு root credential ஆகும். இதை அவ்வாறே கையாளவும்: shell history-ல் சேர்க்க வேண்டாம், git-ல் பதிவேற்ற வேண்டாம், prompt-ல் எங்கும் நகலெடுத்து ஒட்ட வேண்டாம். Compose env கோப்புகள் மற்றும் அவற்றிலிருந்து ரகசியங்கள் கசியும் இடங்கள் மற்றும் API keys-ஐ agent-ன் சூழலுக்கு வெளியே வைத்திருத்தல் ஆகிய இரண்டும் இதற்கு நேரடியாகப் பொருந்தும், ஏனெனில் இந்த server-ஐ அழைப்பவை அனைத்தும் agents ஆகும்.

env_file-லிருந்து ஏற்றப்படும் மதிப்புகள் container சூழலில் இருக்கும், மேலும் docker inspect அவற்றை முழுமையாக அச்சிடும். docker குழுவில் உள்ள எவரும் அவற்றை வாசிக்க முடியும், மேலும் docker குழுவில் உள்ள எவரும் host-ல் root-க்கு இணையான அதிகாரத்தைப் பெற்றிருப்பார்கள்.

8888-ஐத் திறப்பதற்குப் பதிலாக API-க்கு முன்னால் TLS-ஐ அமைக்கவும்

API ஆனது 127.0.0.1:8888-லும், dashboard ஆனது 127.0.0.1:3000-லும் பதிலளிக்கின்றன. nginx ஆனது 443 port-ல் TLS (transport layer security)-ஐ முடிவுக்குக் கொண்டுவந்து (terminate), இரண்டிற்கும் traffic-ஐ அனுப்புகிறது.

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 என்பது பார்ப்பதை விட முக்கியமானது. ஒரு add அழைப்பு நிகழும்போது, language model உரையாடலைப் படித்து தகவல்களைப் பிரித்தெடுக்கும் வரை அது காத்திருக்கும் (blocks). CPU-வில் இயங்கும் ஒரு local 8B model, nginx-ன் இயல்பான 60 வினாடி காலக்கெடுவை விட அதிக நேரம் எடுத்துக்கொள்ளும். அப்போது model தொடர்ந்து இயங்கிக்கொண்டிருக்கும்போதும், memory-ல் தகவல்கள் எழுதப்படும்போதும், அழைப்பவர் 504 Gateway Time-out பிழையைக் காண்பார். இறுதியில், தோல்வியடைந்ததாகக் கூறப்பட்ட ஒரு memory உங்களுக்குக் கிடைக்கும்.

இயல்பான deny ufw policy மூலம் மற்ற ports-ஐ மூடிவிடவும், 22 மற்றும் 443-ஐ மட்டும் திறந்து வைக்கவும். nginx-க்கு பின்னால் Ubuntu 24.04-ல் certbot மூலம் certificate-ஐப் பெறவும். ஏற்கனவே இந்த server பல Compose apps-ஐ வழிநடத்தும் Traefik மூலம் இயங்கிக்கொண்டிருந்தால், இரண்டாவது proxy-ஐ நிறுவுவதற்குப் பதிலாக அந்த router-லேயே mem0-ஐச் சேர்க்கவும்.

Smoke test: ஒரு memory-ஐச் சேர்த்து மீண்டும் வாசித்தல்

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"}'

சரியான பதில் ஒரு JSON object ஆக இருக்கும். அதில் results பட்டியல் இருக்கும். ஒவ்வொரு பதிவிலும் ஒரு id, பிரித்தெடுக்கப்பட்ட memory உரை மற்றும் "event": "ADD" ஆகியவை இருக்கும். தற்போதைய algorithm ADD நிகழ்வுகளை மட்டுமே வழங்குகிறது. UPDATE மற்றும் DELETE நிகழ்வுகள் நீக்கப்பட்டுவிட்டன, எனவே அவை இல்லாதது ஒரு பிழை அல்ல.

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 பற்றிய தகவல் ஒரு score-உடன் திரும்ப வர வேண்டும். காட்டப்பட்டுள்ளபடி, filters-க்குள் identifier-ஐ அனுப்பவும். ஒரு top level user_id இன்னும் வேலை செய்யும், மேலும் நீங்கள் அதைப் பயன்படுத்தும் ஒவ்வொரு முறையும் server Top-level user_id in /search is deprecated. Use filters={...} instead.-ஐ log செய்யும்.

சோதனைத் தரவுகள் உண்மையான தேடல்களைப் பாதிக்காதவாறு, சோதனையை முடித்த பிறகு அவற்றை நீக்கிவிடவும்:

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

தேடல் முடிவுகள் நீங்கள் எதிர்பார்த்ததை விடக் குறைவாக இருந்தால், retrieval-ஐக் குறை கூறுவதற்கு முன் defaults-ஐச் சரிபார்க்கவும். தற்போதைய release-ல் top_k-ன் default மதிப்பு 100-லிருந்து 20-ஆகக் குறைக்கப்பட்டுள்ளது. மேலும் threshold-ன் default மதிப்பு none என்பதற்குப் பதிலாக 0.1 என உள்ளது, எனவே பலவீனமான பொருத்தங்கள் இப்போது உங்களுக்காக வடிகட்டப்படுகின்றன. இது curl மூலம் வேலை செய்தவுடன், அதே endpoints-ஐ நீங்கள் ஒரு agent-ல் இணைக்கலாம்; அதை நேரடியாகவோ அல்லது ஒரே VPS-ல் இயங்கும் MCP server மூலமாகவோ செய்யலாம்.

OpenAI key இல்லாமலேயே mem0-ஐ இயக்குதல்

முதல் ஐந்து நிமிடங்களிலேயே நீங்கள் சந்திக்கும் தடையிலிருந்து தொடங்குவோம். சர்வர் இமேஜ் ஒரு குறிப்பிட்ட 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.

நீங்கள் எதையும் மீண்டும் உருவாக்க (rebuild) வேண்டியதில்லை. Ollama, /v1-ல் OpenAI இணக்கமான API-ஐ வழங்குகிறது, இது /v1/chat/completions மற்றும் /v1/embeddings ஆகியவற்றை உள்ளடக்கியது. mem0-ன் openai provider ஒரு openai_base_url-ஐ ஏற்கும். அந்த key-ஐ Ollama-வை நோக்கிச் சுட்டிக்காட்டினால், bundled check வெற்றி பெறும், ஏனெனில் அந்த provider உண்மையில் openai தான். முகவரி மட்டுமே மாறுகிறது.

Ollama-வை அதே Compose project-ல் சேர்க்கவும்:

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

மேல்நிலை 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

Ollama ஏற்கனவே host-ல் systemd unit-ஆக இயங்கிக்கொண்டிருந்தால், Ollama-வை நேரடியாக VPS-ல் இயக்குதல் பகுதியில் உள்ளது போல, 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 network-ல் அணுகக்கூடிய முகவரியில் இயங்கும்படி systemd drop-in-ல் Environment="OLLAMA_HOST=0.0.0.0:11434"-ஐ அமைக்கவும், மேலும் firewall-ல் 11434 port-ஐ மூடி வைக்கவும்.

எதையும் configure செய்வதற்கு முன் model-ன் embedding dimension-ஐக் கேட்கவும்

இந்த ஒரு படிதான் retrieval சரியாக வேலை செய்யுமா என்பதைத் தீர்மானிக்கிறது.

mem0-ன் pgvector store அதன் அட்டவணையை ஒரு நிலையான vector width-ல், அதாவது vector vector(1536)-ல் உருவாக்குகிறது. ஏனெனில் embedding_model_dims இயல்பாகவே 1536-ஐக் கொண்டுள்ளது, இது OpenAI-ன் text-embedding-3-small-ன் அகலமாகும். nomic-embed-text 768 மதிப்புகளைத் தருகிறது. mem0-க்குள் இந்த இரண்டு எண்களையும் ஒப்பிட்டுப் பார்க்க எதுவுமில்லை, எனவே முதல் insert-ன் போது Postgres-லிருந்து பிழை வரும்:

expected 1536 dimensions, not 768

இந்த பத்தியில் உள்ள எண்ணையும் நம்ப வேண்டாம். 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 பயன்படுத்த வேண்டிய அகலத்தை அச்சிடும். இந்த configuration-ஐ ஒரு கோப்பில் எழுதவும், ஏனெனில் shell quoting மூலம் Postgres கடவுச்சொல்லை உள்ளிடும்போதுதான் பிழைகள் (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"

இரண்டாவது அழைப்பு configuration-ஐ மீண்டும் வாசிக்கும், இது தரவு சரியாகப் பதிவாகிவிட்டதா என்பதை உறுதிப்படுத்தும். பிறகு மேலே உள்ள smoke test-ஐ மீண்டும் செய்யவும்.

அந்த JSON-ல் உள்ள நான்கு விவரங்கள் வெளிப்படையானவை அல்ல, ஒவ்வொன்றையும் தவறாகச் செய்தால் ஏதோ ஒன்று வேலை செய்யாது.

api_key என்பது ollama என்ற string ஆகும், Ollama இதன் மதிப்பை அலட்சியப்படுத்தும். இது காலியாக இருக்கக்கூடாது, ஏனெனில் எந்த key-யும் இல்லாதபோது, கோரிக்கை செயல்முறைக்கு வெளியே செல்வதற்கு முன்பே OpenAI client library பிழையை எழுப்பும். காலியாக இல்லாத எந்த string-ம் வேலை செய்யும்.

embedding_model_dims என்பது vector store-க்கு உரியது, embedder-ல் வேண்டுமென்றே embedding_dims இல்லை. நீங்கள் embedding_dims-ஐ அமைக்கும்போது மட்டுமே mem0 OpenAI dimensions parameter-ஐ அனுப்பும். Matryoshka truncation-ஐ செயல்படுத்தாத backends அந்த parameter-ஐ நேரடியாக நிராகரிக்கும். அட்டவணை உருவாக்கப்படும் இடத்தில் அகலத்தை அமைக்கவும், embedder-ஐ மாற்ற வேண்டாம்.

collection_name புதியது. mem0 அதன் அட்டவணையை CREATE TABLE IF NOT EXISTS-ல் உருவாக்குகிறது, எனவே ஏற்கனவே உள்ள collection-க்கு வேறு அகலத்தைச் சுட்டிக்காட்டினால் எந்த மாற்றமும் இருக்காது: பழைய vector(1536) column அப்படியே இருக்கும், ஒவ்வொரு insert-ம் தோல்வியடையும். அகலத்தை மாற்ற வேண்டுமென்றால் புதிய collection பெயர் தேவை, அல்லது பழைய அட்டவணையை நீங்களே நீக்க வேண்டும்.

openai_base_url-ல் உள்ள host என்பது Compose service பெயர் ollama, localhost அல்ல. Containers அவற்றின் பகிரப்பட்ட network-ல் service பெயர் மூலம் ஒன்றையொன்று கண்டறியும்.

முழுமையான local path-ன் விளைவுகள்

தரம் குறித்து உண்மையாக இருங்கள். mem0-ன் வெளியிடப்பட்ட benchmark மதிப்பெண்கள், extraction-க்கு frontier models-ஐப் பயன்படுத்தி அளவிடப்பட்டவை. எனவே, உங்கள் VPS-ல் உள்ள 8B model-க்கு இதை ஒரு இலக்காகக் கருதாமல், ஒரு உச்சவரம்பாகக் கருதுங்கள். ஒரு சிறிய model தெளிவற்ற உண்மைகளை எழுதும், சில நேரங்களில் JSON கேட்டால் உரைநடையைத் தரும். இது add அழைப்பு பிழை இல்லாமல் காலியான results பட்டியலைத் தருவதாகக் காட்டும்.

வேகம் மற்றொரு சிக்கல். CPU-மட்டும் பயன்படுத்தும் extraction ஒவ்வொரு add அழைப்பிற்கும் சில நொடிகளை எடுக்கும், நீங்கள் சேமிக்கும் ஒவ்வொரு செய்தியும் இதற்குச் செலவாகும். இந்த latency முக்கியமென்றால், GPU இணைக்கப்பட்ட VPS தான் சரியான தீர்வு. 8B model-க்கு அதிக CPU cores-ஐக் கொடுப்பது மக்கள் எதிர்பார்ப்பதை விடக் குறைவான பலனையே தரும்.

நீங்கள் எதைத் தேர்ந்தெடுத்தாலும் ஒரு விதி பொருந்தும்: ஒரே collection-க்குள் வெவ்வேறு embedding models-ஐ ஒருபோதும் கலக்க வேண்டாம். தற்செயலாக ஒரே அகலத்தைக் கொண்ட இரண்டு வெவ்வேறு models உருவாக்கும் vectors-ஐ ஒப்பிட முடியாது. Insert வெற்றி பெறும், தேடல் முடிவுகளைத் தரும், ஆனால் அந்த முடிவுகள் தவறானவை. எங்கும் பிழை காட்டப்படாது.

காப்புப்பிரதிகள் (Backups): இரண்டு தரவுத்தளங்கள் உள்ளன, ஒன்று அல்ல

mem0 காப்புப்பிரதி எடுக்கும்போது செய்யப்படும் பொதுவான தவறு, ஒரே ஒரு தரவுத்தளத்தை மட்டும் dump செய்வதுதான். init-db.sh இயல்புநிலை postgres தரவுத்தளத்துடன் சேர்த்து mem0_app-ஐயும் உருவாக்குகிறது; இவை இரண்டும் வெவ்வேறு தகவல்களைக் கொண்டுள்ளன. postgres தரவுத்தளம் pgvector தொகுப்புகளைக் கொண்டுள்ளது, இவைதான் நினைவகங்கள் (memories). mem0_app பயனர்கள், அமர்வுகள் (sessions), API keys மற்றும் கோரிக்கை பதிவுகளை (request logs) கொண்டுள்ளது.

postgres-ஐ மட்டும் restore செய்தால், நினைவகங்கள் திரும்ப வரும், ஆனால் அனைத்து கணக்குகளும் API keys-ம் அழிந்துவிடும். எனவே, எதையும் அங்கீகரிக்க (authenticate) முடியாது. இரண்டையும், மற்றும் roles-களையும் ஒரே கட்டளையில் dump செய்யவும்:

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

வரலாற்றுத் தொகுதி (history volume) Postgres-லிருந்து தனிப்பட்டது, அதற்குத் தனிப்பட்ட நகல் தேவை:

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

Docker தொகுதிப் பெயர்களுக்கு முன்னால் project பெயரைச் சேர்க்கும். எனவே, mem0_mem0_history என்று கருதுவதற்கு முன் docker volume ls மூலம் உங்கள் தொகுதிப் பெயரை உறுதிப்படுத்தவும்.

ஒரு scratch container-ல் restore செய்து, வரிசைகளின் எண்ணிக்கையை (row counts) சரிபார்த்த பின்னரே அதை நம்பவும்:

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

நீங்கள் ஒருபோதும் restore செய்து பார்க்காத காப்புப்பிரதி என்பது வெறும் ஊகம் மட்டுமே. dumps சரியாக இருப்பதை உறுதி செய்த பிறகு, அவற்றை off-site சேமிப்பகத்திற்கு restic snapshots மூலம் server-லிருந்து வெளியேற்றவும். ஏனெனில், எந்த server-ஐப் பாதுகாக்கிறதோ, அதே server-ல் இருக்கும் காப்புப்பிரதி எதையும் பாதுகாக்காது.

தோல்வி முறைகள் மற்றும் நீங்கள் காணும் துல்லியமான சரங்கள் (strings)

{"detail":"Authentication required. Provide a Bearer token or X-API-Key header."} என்பது தலைப்பு (header) விடுபட்டுள்ளது அல்லது தவறாக எழுதப்பட்டுள்ளது என்று பொருள். அதன் பெயர் X-API-Key ஆகும், மேலும் curl தலைப்புப் பெயர்களை அப்படியே அனுப்புகிறது.

ஒரு சேர்ப்பின் (add) போது {"detail":"At least one identifier (user_id, agent_id, run_id) is required."} என்பது, கோரிக்கையில் அவை எதுவும் இல்லை என்று பொருள். ஒரு நினைவகம் (memory) ஏதோ ஒன்றின் எல்லைக்குள் இருக்க வேண்டும், ஏனெனில் தேடல் வடிப்பான்கள் (search filters) அந்த குறிப்பிட்ட புலங்களில் மட்டுமே செயல்படுகின்றன.

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) ஒரு அகலத்தில் உருவாக்கப்பட்டது, ஆனால் உட்பொதிப்பான் (embedder) வேறொரு அகலத்தைத் தருகிறது என்று பொருள். வெக்டர் ஸ்டோரில் embedding_model_dims-ஐ அமைத்து, புதிய collection_name-ஐப் பயன்படுத்தவும்.

மாதிரி மாற்றத்திற்குப் பிறகு தேடல் அர்த்தமற்ற வரிசைகளைத் தருகிறது, ஆனால் எந்தப் பிழையும் காட்டப்படவில்லை. அகலம் சரியாக இருப்பதால் தரவுத்தளம் சரியாகச் செயல்படுகிறது, ஆனால் இரண்டு மாதிரிகள் ஒரே வாக்கியத்தை வெவ்வேறு இடங்களில் வைக்கின்றன. புதிய தொகுப்பைத் தொடங்கி மீண்டும் சேர்க்கவும்.

Ollama-வை அடையும் போது mem0 பதிவுகளில் (logs) வரும் Connection refused என்பது, பொதுவாக openai_base_url-ல் 127.0.0.1 என்று பொருள். கொள்கலனுக்குள் (container) அந்த முகவரி என்பது கொள்கலனையே குறிக்கும். சேவைப் பெயரைப் பயன்படுத்தவும், அல்லது Ollama ஹோஸ்டில் இயங்கும்போது host gateway-ஐப் பயன்படுத்தவும்.

சேர்ப்பின் போது nginx-லிருந்து வரும் 504 Gateway Time-out என்பது, மாதிரி (model) proxy_read_timeout-ஐ விட அதிக நேரம் எடுத்துக்கொண்டது என்று பொருள். அதை அதிகரிக்கவும், கோரிக்கையை மீண்டும் முயற்சிக்கும் முன் நினைவகம் ஏற்கனவே எழுதப்பட்டுள்ளதா என்று சரிபார்க்கவும்.

docker compose up --build-ன் போது வரும் exit code 137 என்பது, dashboard உருவாக்கத்தை நிறுத்தும் out-of-memory killer ஆகும். swap-ஐச் சேர்க்கவும், அல்லது பெரிய இயந்திரத்தில் image-ஐ உருவாக்கி அதை registry-க்கு அனுப்பவும்.

error: port 3000 is already in use என்பது களஞ்சியத்தின் (repo) make up இலக்கிலிருந்து வருகிறது, இது 3000 அல்லது 8888 ஆகிய ports பயன்பாட்டில் இருக்கும்போது தொடங்க மறுக்கிறது. lsof -iTCP:3000 -sTCP:LISTEN மூலம் அதைப் பயன்படுத்தும் process-ஐக் கண்டறியவும்.

FAQ

graph memory-உடன் mem0-ஐ இயக்க எனக்கு இன்னும் Neo4j தேவையா?

இல்லை. ஏப்ரல் 2026-ல் வெளியிடப்பட்ட புதிய memory algorithm, open source SDK-விலிருந்து graph_store மற்றும் enable_graph ஆகிய configuration keys-ஐ நீக்கிவிட்டது. Entity extraction இப்போது சாதாரண add செயல்பாட்டின்போதே நடக்கும்; இது <collection_name>_entities என்று பெயரிடப்பட்ட இரண்டாவது pgvector collection-ல் எழுதப்படும். எனவே, வெளிப்புற graph database, கூடுதல் container அல்லது migration படிநிலைகள் எதுவும் தேவையில்லை. இதன் விளைவாக, search results-ல் இருந்த relations field இப்போது இல்லை. Entities இப்போது ஒரு memory-ன் ranking-ஐ மட்டுமே உயர்த்துகின்றன; நீங்கள் கடந்து செல்வதற்கு (traverse) edges-ஐ வழங்குவதில்லை. எனவே, அந்த உறவுகளை (relationships) பயன்படுத்தும் ஒரு application-க்கு mem0-க்கு வெளியே சொந்தமான graph store தேவைப்படும்.

self-hosted mem0 server-ஐ இயக்கக்கூடிய மிகச்சிறிய VPS எது?

Language model வேறொரு இடத்தில் hosted செய்யப்பட்டிருந்தால், API container, Postgres மற்றும் dashboard-க்கு 2 GB RAM மற்றும் சுமார் 4 GB free disk போதுமானது. முதல் build-ன் போதுதான் அதிக நினைவகம் தேவைப்படும், ஏனெனில் Next.js dashboard-ஐ compile செய்வது அதை இயக்குவதை விட அதிக நினைவகத்தை எடுக்கும். 1 GB அளவுள்ள server-ல் build செயல்முறை exit code 137 பிழையுடன் நின்றுவிடும். Ollama அதே server-ல் இயங்கினால், model-ன் அளவையும் கணக்கில் கொள்ள வேண்டும்: 8B model-க்கு 4-bit quantisation முறையில் சுமார் 6 GB தேவைப்படும், எனவே 8 GB RAM-ஐ திட்டமிடுங்கள்.

OpenAI API key இல்லாமல் என்னால் mem0-ஐ இயக்க முடியுமா?

ஆம், Ollama-வின் OpenAI compatible endpoint மூலம் இயக்கலாம். "provider": "ollama"-ஐ அமைத்தால் அது தோல்வியடையும், ஏனெனில் server image-ல் openai, anthropic மற்றும் gemini libraries மட்டுமே உள்ளன, அது HTTP 400 பிழையைத் தரும். அதற்கு பதிலாக "provider": "openai"-ஐ அப்படியே வைத்துக்கொண்டு, llm மற்றும் embedder ஆகிய இரண்டிற்கும் "openai_base_url": "http://ollama:11434/v1"-ல் ஏதேனும் ஒரு non-empty api_key-ஐ அமைக்கவும். Ollama அந்த key-ஐப் புறக்கணிக்கும், மேலும் provider உண்மையில் openai என்பதால் bundled provider check வெற்றிகரமாக முடிந்துவிடும்.

local embedding model-க்கு மாறிய பிறகு mem0 ஏன் முடிவுகளைத் தருவதில்லை?

ஏனெனில் pgvector table ஒரு நிலையான அகலத்தில் (fixed width) உருவாக்கப்பட்டது. embedding_model_dims இயல்பாக 1536-ஐக் கொண்டிருக்கும், nomic-embed-text 768-ஐத் தரும், எனவே Postgres expected 1536 dimensions, not 768 பிழையுடன் insert-ஐ நிராகரிக்கும். mem0 ஆனது CREATE TABLE IF NOT EXISTS கொண்டு table-ஐ உருவாக்குகிறது, எனவே அந்த எண்ணை மட்டும் மாற்றுவது ஏற்கனவே உள்ள collection-ல் எந்த மாற்றத்தையும் ஏற்படுத்தாது. embedding_model_dims-ஐ உங்கள் model-ன் உண்மையான அகலத்திற்கு அமைக்கவும், /v1/embeddings-ஐ அழைத்து அது தரும் மதிப்புகளை எண்ணி அந்த அகலத்தை உறுதிப்படுத்தவும், அதே நேரத்தில் vector store-க்கு புதிய collection_name-ஐ வழங்கவும்.

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

Built for exactly this: a fresh Ubuntu 24.04 KVM VPS with root.

SSD Nodes-ன் 15 ஆண்டுகள், அனைத்திற்கும் 15% தள்ளுபடி: எந்தத் திட்டமும், எந்தக் கட்டணச் சுழற்சியும், புதிய மற்றும் ஏற்கனவே உள்ள வாடிக்கையாளர்களும். முழு root access, 4TB தரவு பரிமாற்றம், 14 நாள் பணம் திரும்பப் பெறும் உத்தரவாதம்.

செலுத்தும் பக்கத்தில் LEARN15 குறியீடு உங்களுக்காகப் பயன்படுத்தப்படும்.

எனது 15% தள்ளுபடியைப் பெறுக →