VPS पर Memmy local memory hub कैसे सेटअप करें

Memmy क्या है और यह क्या स्टोर करता है

Memmy AI agents के लिए एक local memory hub है जो आपके अपने VPS (virtual private server) पर चलता है। यह agents द्वारा सीखी गई बातों का एक SQLite database रखता है, और सर्वर पर मौजूद हर agent उसी store से read और write करता है। यह प्रोजेक्ट MemTensor से memmy-agent है, MIT licensed है, और 1 November 2026 तक इसका version 1.2.401 है; Memory का version स्वतंत्र रूप से 2.1.7 है।

सर्वर पर इसका केवल एक हिस्सा मायने रखता है। Memmy एक memory service के साथ आता है जो http://127.0.0.1:18960 पर listen करती है, एक memmy-memory command line interface (CLI) जो उस service से बात करता है, और एक desktop workbench। Workbench केवल macOS और Windows के लिए packaged है, इसलिए Linux VPS पर आप केवल service और CLI चलाते हैं। Claude Code, Codex और Cursor को shared memory देने के लिए इतना काफी है।

Memmy अपने द्वारा स्टोर की गई जानकारी को चार layers में व्यवस्थित करता है। Capture सबसे पहले एक अलग Raw Turn स्टोर करता है, फिर प्रत्येक captured step के लिए एक L1 Trace item लिखता है, जिसमें requests, responses, tool calls और results शामिल होते हैं। L2 Policy उन traces से निकाली गई प्रक्रिया है जो उपयोगी साबित हुई हैं। L3 World Model किसी प्रोजेक्ट या environment के बारे में स्थिर ज्ञान है। Skill एक callable प्रक्रिया है जो policy से तैयार की जाती है। Capture L1 traces बनाता है, background jobs उच्च layers को विकसित करती हैं, और explicit writes किसी layer का चयन कर सकते हैं। यदि ये अंतर अमूर्त लगते हैं, तो memory agents बनाने के सीखने के चरणबद्ध मार्ग के बाद के चरणों में से एक है, और जब आप स्वयं एक साधारण agent loop लिख लेते हैं और उसे runs के बीच सब कुछ भूलते हुए देख लेते हैं, तो ये layers अधिक समझ में आने लगती हैं।

Shared memory hub, per-tool memory की तुलना में क्या बदलता है

आज हर agent की अपनी अलग memory होती है। Claude Code निर्देश फाइलों को repository में रखता है। Cursor नियमों को अपने workspace database में रखता है। Codex session logs को ~/.codex के अंतर्गत रखता है। प्रत्येक store एक ही tool का होता है, इसलिए सोमवार को आपने जो तथ्य एक tool में सिखाया, वह मंगलवार को दूसरे tool को पता नहीं होता। आप इसकी कीमत दो बार चुकाते हैं: एक बार उसी project को दोबारा समझाने में खर्च हुए tokens के रूप में, और दूसरी बार गलत काम के रूप में जब कोई agent ऐसी धारणा पर काम करता है जिसे आप कहीं और पहले ही सुधार चुके होते हैं।

एक hub इस store को tool से बाहर निकाल देता है। Memmy मौजूदा stores को भी पढ़ता है, इसलिए आप खाली database से शुरुआत नहीं करते। इसका scanner दस built-in sources को जानता है: ~/.claude/projects/**/*.jsonl पर Claude Code, ~/.codex/sessions/<YYYY>/<MM>/<DD>/rollout-*.jsonl पर Codex, ~/.local/share/opencode/opencode.db पर OpenCode, Cursor की state.vscdb फाइलें, ~/.openclaw के अंतर्गत OpenClaw की SQLite databases, ~/.hermes पर Hermes, ~/.dsh/sessions पर DeepSeek Harness, ~/.workbuddy/projects पर WorkBuddy, ~/.pi/agent/sessions पर Pi और ~/.qwenworkcn/projects पर QwenWork। Desktop workbench नाम से एक और agent जोड़ सकता है, और यह history path केवल तब मांगता है जब उसे agent स्वयं नहीं मिलता। Server-side scanner में कोई custom source नहीं होता, इसलिए headless VPS पर आपको केवल built-in sources ही मिलते हैं।

Import counters मेल नहीं खाएंगे, और यह अपेक्षित है। Scanner संदेशों को source और conversation के आधार पर समूहबद्ध करता है, फिर प्रत्येक पूर्ण turn के लिए एक L1 memory लिखता है। एक turn तब पूर्ण मानी जाती है जब उसमें non-empty user content हो और वह एक non-empty assistant message के साथ समाप्त हो, इसलिए एक अधूरी turn तब तक कुछ योगदान नहीं देती जब तक कि बाद का sync उसे पूरा न कर दे। संदेशों को conversation checkpoints और stable turn IDs के साथ deduplicate किया जाता है। एक ही run पर scanned count, imported message count और new memory count सभी अलग-अलग होते हैं।

यह वह हिस्सा है जो Claude Code एक session के भीतर context को कैसे manage करता है के साथ जुड़ता है। Context management यह तय करता है कि एक single window में क्या फिट बैठता है। एक memory hub यह तय करता है कि उस window के बंद होने के बाद क्या सुरक्षित रहता है।

VPS पर आपको क्या चाहिए

• Node.js 22 या उससे नया वर्ज़न। Memmy के दस्तावेज़ों के लिए यह आवश्यक है, और Ubuntu 24.04 में Node 18 मिलता है।
• git और एक build toolchain, क्योंकि better-sqlite3 एक native module है जिसे install के दौरान compile होने की आवश्यकता हो सकती है।
• root workspace install और इसके frontend build chain के लिए पर्याप्त RAM।
• node_modules और database के लिए खाली disk space।

sudo apt update
sudo apt install -y git build-essential python3 curl ca-certificates sqlite3
curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node --version

node --version को documented source build के लिए v22 या उससे अधिक output देना चाहिए। यहाँ v18 का मतलब है कि NodeSource वाला चरण सफल नहीं हुआ। npm का engine-strict डिफ़ॉल्ट रूप से false होता है, इसलिए एक incompatible engine declaration आमतौर पर install को स्वचालित रूप से विफल करने के बजाय केवल एक warning देता है।

Ubuntu 24.04 पर source से Memmy install करना

git clone https://github.com/MemTensor/memmy-agent.git
cd memmy-agent
cp .env.example .env
npm install
npm run memory:build

npm run memory:build, @memmy/memory workspace को Memory/dist में compile करता है। यह AgentSourceCore, memory viewer और उस workspace के लिए आवश्यक integration assets को भी build करता है। जाँचें कि native module load हुआ है या नहीं:

node -e "const Database = require('better-sqlite3'); const db = new Database(':memory:'); db.close(); console.log('better-sqlite3 loads')"

यदि वह line print करने के बजाय error देती है, तो load होने या database initialization की विफलता को पहचानने के लिए error को पढ़ें। Native module mismatch के लिए, npm rebuild better-sqlite3 चलाएँ, जो कि project की अपनी start script किसी भी चीज़ को launch करने से पहले ठीक यही करती है।

README में bash scripts/dev-start.sh को एक-कमांड start के रूप में document किया गया है। इसे headless VPS पर न चलाएँ। यह memory service के साथ port 19000 पर Electron desktop shell और Vite dev server शुरू करता है, और Electron को display की आवश्यकता होती है, इसलिए बिना graphical session वाले सर्वर पर script रुक जाती है या exit हो जाती है।

हाल के releases में Linux x64 और arm64 के लिए memmy-agent-linux-cli.tar.gz और एक install.sh भी attach होते हैं। Installer को 22.x के भीतर Node.js 22.23.4+, 24.x के भीतर 24.22.1+, या 26.x के भीतर 26.12.1+ की आवश्यकता होती है, साथ ही एक systemd user session भी चाहिए; यह अन्य major versions को अस्वीकार कर देता है। यह memmy और memmy-memory launchers को ~/.local/bin में डालता है, और memory service को 127.0.0.1:18960 पर user unit के रूप में शुरू करता है। यह guide source build का उपयोग करती है क्योंकि यह वह रास्ता है जहाँ आप चलने से पहले हर script को पढ़ सकते हैं।

Memory service को start करें और जाँचें कि क्या यह response दे रहा है

npm run memory:serve:dev

यह source से memory service को चलाने का दस्तावेजीकृत (documented) तरीका है। यह 127.0.0.1:18960 पर bind होता है, database को ~/.memmy/memory-service/memory.sqlite पर रखता है, और ~/.memmy/config.yaml से config पढ़ता है। जब आप values को स्पष्ट रूप से देना चाहते हैं, तो server उन्हें flags के रूप में भी स्वीकार करता है:

npm run memory:serve:dev -- \
  --host 127.0.0.1 --port 18960 \
  --db ~/.memmy/memory-service/memory.sqlite \
  --config ~/.memmy/config.yaml

एक दूसरे shell से, service से पूछें कि क्या वह active है:

curl -sS http://127.0.0.1:18960/api/v1/health

Health check के लिए token की आवश्यकता नहीं होती है, इसीलिए यह एक सही probe है। यदि curl कोड 7 और Failed to connect to 127.0.0.1 port 18960 संदेश के साथ exit होता है, तो connection विफल हो गया है; केवल इससे यह पता नहीं चलता कि listener मौजूद है या नहीं। address, port और local firewall की जाँच करें, और startup errors के लिए उस terminal को पढ़ें जहाँ service चल रही है। service के up होने पर ss -lntp | grep 18960 socket की पुष्टि करता है।

बाकी HTTP API (application programming interface) /api/v1 के अंतर्गत स्थित है।

• POST /api/v1/memory/add एक memory लिखता है और POST /api/v1/memory/search query करता है।
• GET /api/v1/memory/:id और DELETE /api/v1/memory/:id एक entry को पढ़ते और हटाते हैं।
• POST /api/v1/sessions/open और POST /api/v1/sessions/:sessionId/close एक agent session को शुरू और समाप्त करते हैं।
• POST /api/v1/turns/start और POST /api/v1/turns/:turnId/complete एक turn को record करते हैं।
• GET /api/v1/panel/overview, /api/v1/panel/analysis और /api/v1/panel/items dashboard को data प्रदान करते हैं।

Memmy ports का एक block reserve करता है, और headless mode में आप केवल पहले का उपयोग करते हैं: memory के लिए 18960, gateway health के लिए 18970, web UI और admin HTTP के लिए 18980, OpenAI-compatible API के लिए 18990 जिसे memmy serve start करता है, फिर desktop frontend के Vite dev server के लिए 19000 और इसके hot reload socket के लिए 19001। project का ports page अभी भी hot reload के लिए 19010 सूचीबद्ध करता है, लेकिन Vite config 19001 set करता है। यदि आपके box पर कोई अन्य service इनमें से किसी port का उपयोग कर रही है, तो उस सूची में देखें।

memmy-memory कमांड वास्तव में कहाँ से आती है

यह वह जगह है जहाँ पहला इंस्टॉलेशन अक्सर गलत हो जाता है, इसलिए अनुमान लगाने के बजाय इसे पैकेज से पढ़ें। कमांड का नाम रिपॉजिटरी के नाम से संबंधित नहीं है। यह वर्कस्पेस के bin फील्ड से आता है जो इसे परिभाषित करता है:

node -p "JSON.stringify(require('./Memory/package.json').bin)"

यह {"memmy-memory":"./dist/src/cli/index.js"} प्रिंट करता है। इसलिए बिल्ट एंट्री पॉइंट Memory/dist/src/cli/index.js है, और यह केवल npm run memory:build के बाद मौजूद होता है, क्योंकि बिल्ड ही dist को बनाता है और फाइल को एक्जीक्यूटेबल के रूप में मार्क करता है। इसे सीधे चलाएँ:

node Memory/dist/src/cli/index.js health

यदि आप अपने PATH पर छोटा नाम चाहते हैं, तो उसी फाइल को लिंक करें:

sudo ln -s "$PWD/Memory/dist/src/cli/index.js" /usr/local/bin/memmy-memory
memmy-memory health

CLI डिफ़ॉल्ट रूप से http://127.0.0.1:18960 पर सेट होता है और --url, --token, --config, --source और --user-id को स्वीकार करता है। इसके सब-कमांड init, health, search, add, get और delete हैं, साथ ही session और turn कॉल हैं जिनका उपयोग लोग नहीं बल्कि एजेंट्स करते हैं, और सर्विस को मैनेज करने के लिए install, upgrade, service और stop हैं। memmy-memory search "deploy steps" और memmy-memory add "staging migrates on deploy" वे दो कमांड हैं जिन्हें एक एजेंट सबसे अधिक चलाता है।

Claude Code को Memmy से कैसे कनेक्ट करें?

Memmy खुद को Claude Code के अंदर एक सर्वर के रूप में रजिस्टर नहीं करता है। यह उन फाइलों के माध्यम से कनेक्ट होता है जिन्हें Claude Code पहले से ही पढ़ता है, और यह किस हद तक काम करेगा यह इस पर निर्भर करता है कि आप कौन सा memmy-memory चलाते हैं। सोर्स चेकआउट से, memmy-memory init --agent claude एक memmy-memory Skill को ~/.claude/skills/ में और एक चिह्नित मेमोरी ब्लॉक को ~/.claude/CLAUDE.md में लिखता है, और जब निर्देश ऐसा करने के लिए कहते हैं तो Claude Code memmy-memory को एक सामान्य शेल कमांड के रूप में चलाता है। Linux इंस्टॉलर द्वारा ~/.local/bin में रखा गया लॉन्चर और आगे जाता है: वही कमांड ~/.claude/settings.json में SessionStart, UserPromptSubmit, Stop, PostCompact और SessionEnd के लिए हुक भी रजिस्टर करता है, जो प्रासंगिक मेमोरी को इंजेक्ट करते हैं और मॉडल को निर्णय लिए बिना ही प्रत्येक पूर्ण टर्न को सेव कर लेते हैं।

निर्देश को एक बार हाथ से लिखें, क्योंकि तब आप जानते हैं कि एजेंट को वास्तव में क्या बताया गया था। Claude Code प्रत्येक सत्र की शुरुआत में प्रोजेक्ट रूट से CLAUDE.md को पढ़ता है, इसलिए इस तरह का एक सेक्शन सोर्स पाथ पर पूरा इंटीग्रेशन है:

## Memory

Before starting a task, run `memmy-memory search "<topic>"` and read what comes back.
When a task is done, run `memmy-memory add "<what you learned>"` for anything that will matter next session.

स्पष्ट रहें कि इससे आपको क्या लाभ मिलता है। हुक के बिना यह इंस्ट्रक्शन-लेवल इंटीग्रेशन है, इसलिए यह तब काम करता है जब मॉडल कमांड चलाने का निर्णय लेता है, अन्यथा नहीं। कॉल करने के लिए कुछ भी बाध्य नहीं करता है। यदि कोई सत्र add के बिना समाप्त होता है, तो निर्देश ने स्वयं कुछ भी सेव नहीं किया; बाद में हिस्ट्री स्कैन अभी भी पूर्ण टर्न को इम्पोर्ट कर सकता है। यह Claude Code की अपनी मेमोरी फाइलों के समान ही ट्रेड-ऑफ है, बस एक अंतर के साथ: स्टोर साझा किया जाता है, इसलिए नोट उसी मशीन पर Codex और Cursor तक भी पहुँच जाता है। हुक विनम्रतापूर्वक पूछने के बजाय अंतर को पाट देते हैं, यही कारण है कि ड्यूरेबल मेमोरी इंस्टॉल करने योग्य DeepSeek Harness प्लगइन्स के बीच बजट कैप और अनुमति नियमों के साथ मौजूद है।

दूसरी दिशा के लिए किसी सेटअप की आवश्यकता नहीं है। Memmy का स्कैनर पहले से ही ~/.claude/projects/**/*.jsonl को पढ़ता है, जहाँ Claude Code अपने सत्र के ट्रांसक्रिप्ट लिखता है। Memmy को उसी सर्वर पर चलाएं जहाँ आप tmux सत्र के अंदर Claude Code चलाते हैं और कल का काम बिना किसी कॉन्फ़िगरेशन के आपकी मेमोरी बन जाता है।

क्या Memmy, Claude Code के लिए एक MCP server के रूप में काम करता है?

नहीं, और इस दिशा की जानकारी होने से आपका समय बचेगा। MCP (model context protocol) में clients और servers होते हैं। Memmy एक client है। यह MCP servers से connect होता है और उनके tools को अपने स्वयं के agent runtime को उपलब्ध कराता है। यह कोई ऐसा MCP endpoint publish नहीं करता है जिसकी ओर claude mcp add point कर सके। repository में एकमात्र MCP bridge desktop local API के अंदर Composio integration का है, और वह API x-memmy-mcp-token header के पीछे 127.0.0.1 पर एक random port bind करता है।

Client side को ~/.memmy/config.yaml में configure किया जाता है, जिसे MEMMY_CONFIG file point करती है, और यह tools.mcpServers के अंतर्गत होता है:

tools:
  mcpServers:
    example:
      type: stdio
      command: npx
      args:
        - "-y"
        - "your-mcp-server"
      toolTimeout: 30
      enabledTools:
        - "*"

type में stdio, sse और streamableHttp स्वीकार किए जाते हैं। एक stdio server, Memmy की child process के रूप में चलता है, जिसका अर्थ है कि इसकी command उसी box पर मौजूद होनी चाहिए और उसी user के रूप में चलनी चाहिए। यदि आप पहले से ही MCP servers को VPS पर चला रहे हैं, तो उन्हें ही यहाँ list करना चाहिए।

Memory store को निजी रखना

Memmy के स्वामित्व वाली हर चीज़ ~/.memmy के अंतर्गत रहती है: config.yaml, वर्कस्पेस, memory-service/memory.sqlite और रनटाइम फाइलें। स्कैनिंग और इनजेशन स्थानीय रूप से होते हैं, और मेमरी उस स्थानीय SQLite फाइल में लिखी जाती हैं, इसलिए डिफ़ॉल्ट स्थिति पूरी तरह से स्थानीय है।

क्लाउड कनेक्शन एक ऐसा मार्ग है जिस पर नज़र रखनी चाहिए। MEMMY_CLOUD_SERVICE क्लाउड ऑरिजिन का नाम बताता है। कोड इसके लिए कोई डिफ़ॉल्ट सेट नहीं करता है, लेकिन .env.example, जिसे इंस्टॉलेशन चरण .env में कॉपी करते हैं, इसे https://api.memmy.cn पर सेट करता है। यह अपने ट्रायल टोकन के साथ अकाउंट मोड को सपोर्ट करता है, और जब भी यह सेट होता है, Memmy का एनालिटिक्स कोड API की मोड में भी इसे उपयोग इवेंट पोस्ट करता है: इवेंट और कमांड के नाम, वर्शन और एक इंस्टॉलेशन ID। CLI केवल निश्चित कमांड शब्दों की रिपोर्ट करता है, कभी भी सर्च क्वेरी या मेमरी टेक्स्ट की नहीं, और जब वैल्यू अनसेट होती है तो एनालिटिक्स कोड कुछ भी नहीं भेजता है, इसलिए ऐसे सर्वर पर जो केवल API की का उपयोग करता है, कुछ भी शुरू करने से पहले .env में उस लाइन को खाली कर दें। मेमरी सुधार प्रोग्राम प्राइवेसी सेटिंग्स में एक अलग टॉगल है।

मॉडल कॉल एक और मार्ग है। यदि आप एक होस्टेड एम्बेडिंग प्रदाता को कॉन्फ़िगर करते हैं, तो एम्बेड की जा रही मेमरी का टेक्स्ट उस प्रदाता को भेजा जाता है ताकि उसे वेक्टर में बदला जा सके। स्थानीय स्टोरेज वहां मदद नहीं करता है। उस मार्ग को बंद करने के लिए इन-बिल्ट लोकल एम्बेडिंग प्रदाता या अपने द्वारा होस्ट किए गए एम्बेडिंग एंडपॉइंट का उपयोग करें। होस्टेड समरी, इवोल्यूशन और रिलेवेंस-फिल्टर मॉडल भी मेमरी कंटेंट प्राप्त करते हैं जब वे जॉब्स चलती हैं, इसलिए उन मॉडल सेटिंग्स की भी जाँच करें।

पोर्ट 18960 को लूपबैक एड्रेस पर रखें। इसके लिए किसी फायरवॉल नियम की आवश्यकता नहीं है, क्योंकि 127.0.0.1 से बाइंड की गई सर्विस बॉक्स के बाहर से बिल्कुल भी एक्सेस नहीं की जा सकती है। इसके बजाय अपने लैपटॉप से SSH के माध्यम से इसे एक्सेस करें:

ssh -N -L 18960:127.0.0.1:18960 you@your-vps

वर्तमान मेमरी सर्विस नॉन-लूपबैक बाइंड एड्रेस को अस्वीकार कर देती है। कॉन्फ़िगरेशन में storage.token सेट करना, या MEMMY_MEMORY_TOKEN या MEMORY_SERVICE_TOKEN एनवायरनमेंट वेरिएबल, सामान्य मेमरी API कॉल को एक बेयरर टोकन के साथ सुरक्षित करता है; हेल्थ चेक अनऑथेंटिकेटेड रहता है, और ब्राउज़र व्यूअर स्थानीय अनुरोधों के लिए अलग चेक का उपयोग करता है। कॉन्फ़िगरेशन वैल्यू ${ENV_NAME} रेफरेंस को सपोर्ट करती हैं, इसलिए टोकन और आपकी मॉडल API की फाइल से बाहर रहती हैं। यह हर जगह AI एजेंटों से सीक्रेट्स को दूर रखने जैसी ही आदत है, और यदि भविष्य का वर्शन अपना डिफ़ॉल्ट बाइंड एड्रेस बदलता है, तो डिफ़ॉल्ट डिनाई ufw पॉलिसी आपका बैकस्टॉप है।

भरोसा करने से पहले ~/.memmy का बैकअप लें

memory.sqlite पूरा डेटा स्टोर है। वेक्टर्स उसी फाइल में sqlite-vec एक्सटेंशन के माध्यम से रहते हैं, इसलिए एक ही फाइल बैकअप के लिए पर्याप्त है। जब सर्विस डेटा लिख रही हो, उस समय cp के साथ इसे कॉपी करने से डेटाबेस करप्ट (torn) हो सकता है। SQLite के अपने बैकअप कमांड का उपयोग करें:

mkdir -p ~/memmy-backup
sqlite3 ~/.memmy/memory-service/memory.sqlite ".backup '$HOME/memmy-backup/memory.sqlite'"

यह सर्विस के चलते रहने के दौरान एक कंसिस्टेंट कॉपी तैयार करता है। इसे एक शेड्यूल के अनुसार सर्वर से बाहर भेजें, जिसके लिए restic to off-site storage का उपयोग किया जाता है। config.yaml खोने पर आपको केवल प्रोवाइडर सेटिंग्स दोबारा टाइप करनी होंगी। memory.sqlite खोने का मतलब है कि आपके अंतिम उपयोगी बैकअप के बाद रिकॉर्ड की गई यादें (memories) नष्ट हो जाएंगी; सर्विस स्कीमा माइग्रेशन से पहले एक लोकल बैकअप भी बनाती है, लेकिन वह वर्तमान ऑफ-साइट कॉपी नहीं है।

systemd के अंतर्गत memory service को चलाना

npm run memory:serve:dev को shell में चलाने पर shell बंद होते ही वह भी बंद हो जाता है। एक unit file service को reboot के बाद भी चालू रखती है। यह memmy user के रूप में, /opt/memmy में स्थित checkout से, और उस user की home directory में मौजूद config के साथ चलती है। अपने shell में चल रही copy को रोकें, फिर checkout और config को स्थानांतरित करें और memmy-memory link को पुनः point करें:

sudo useradd -m -s /bin/bash memmy
sudo mkdir -p /opt/memmy
sudo mv ~/memmy-agent /opt/memmy/memmy-agent
sudo chown -R memmy:memmy /opt/memmy
sudo ln -sfn /opt/memmy/memmy-agent/Memory/dist/src/cli/index.js /usr/local/bin/memmy-memory
sudo install -d -o memmy -g memmy -m 700 /home/memmy/.memmy
sudo install -o memmy -g memmy -m 600 ~/.memmy/config.yaml /home/memmy/.memmy/config.yaml
sudo install -d -m 755 /etc/memmy

Service अपना database /home/memmy/.memmy के अंतर्गत रखती है, इसलिए यह एक खाली store के साथ शुरू होती है।

[Unit]
Description=Memmy memory service
After=network-online.target

[Service]
Type=simple
User=memmy
WorkingDirectory=/opt/memmy/memmy-agent
EnvironmentFile=/etc/memmy/memory.env
ExecStart=/usr/bin/npm run memory:serve:dev
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Token को unit file से बाहर रखें। इसे /etc/memmy/memory.env में रखें, जिसका owner root हो और mode 600 हो:

MEMMY_CONFIG=/home/memmy/.memmy/config.yaml
MEMMY_MEMORY_TOKEN=replace-this-with-a-long-random-string

sudo systemctl daemon-reload
sudo systemctl enable --now memmy-memory
systemctl status memmy-memory --no-pager
curl -sS http://127.0.0.1:18960/api/v1/health

Status output में status=203/EXEC का अर्थ है कि systemd ExecStart को बिल्कुल भी run नहीं कर सका, इसलिए which npm की जाँच करें: NodeSource install पर यह /usr/bin/npm होता है और nvm पर user की home directory के अंतर्गत कुछ और, जिसे systemd नहीं ढूँढ पाएगा। जो unit शुरू होकर तुरंत बंद हो जाती है, उसके exit status और journal की जाँच करना आवश्यक है: code 0 एक clean exit है, जबकि अन्य परिणामों में non-zero exits, signals और timeouts शामिल हैं। Service के output के लिए journalctl -u memmy-memory -n 50 चलाएँ। इसकी कार्यप्रणाली VPS पर किसी भी अन्य systemd service के समान ही है।

यह project अब दो user-level विकल्प प्रदान करता है। Source build के लिए README का मार्ग memmy-memory install --service-only है, जो pinned Memory runtime को download करता है और एक user service को register करता है, और Linux installer memmy-memory.service को एक systemd --user unit के रूप में set up करता है। इनमें से कोई भी linger को enable नहीं करता है, इसलिए logout के बाद उस user के service manager को चालू रखने और उसे boot पर start करने के लिए sudo loginctl enable-linger <user> चलाएँ।

Memmy जो अभी नहीं करता है

• इसमें Linux desktop build उपलब्ध नहीं है। पैकेजिंग स्क्रिप्ट्स केवल macOS और Windows को कवर करती हैं, इसलिए workbench और उसका onboarding wizard सर्वर पर उपलब्ध नहीं हैं। memory service में अब http://127.0.0.1:18960/viewer/ पर एक browser viewer शामिल है, जिसे ऊपर दिए गए SSH tunnel के माध्यम से एक्सेस किया जा सकता है। Linux के लिए एक CLI tarball और install.sh प्रदान किया गया है।
• memory:serve:dev, TypeScript entry point को tsx के माध्यम से चलाता है, जो एक development path है। रिपॉजिटरी में compiled output के लिए memory:serve भी शामिल है। यह देखने के लिए कि आपके checkout में कौन सी स्क्रिप्ट्स उपलब्ध हैं, बिना किसी argument के npm run चलाएँ।
• Retrieval अपनी search window को नवीनतम 2,000 vector rows से बनाता है, और फिर उस window के भीतर Top-K selection लागू करता है। बहुत बड़े store में, एक पुरानी memory इससे बाहर रह सकती है।
• Embedding, capture के बाद होती है, और विफलता होने पर यह agent के कार्य को रोकने के बजाय एक retry queue में चली जाती है। अभी-अभी जोड़ी गई memory शायद vector search द्वारा तुरंत न मिल सके।
• एक दूसरा सर्वर जिसका अपना स्थानीय SQLite database है, उसकी memory अलग होती है।

1 नवंबर 2026 तक Version 1.2.401 अभी भी एक शुरुआती प्रोजेक्ट को दर्शाता है जिसमें तेजी से बदलाव हो रहे हैं। Flags, paths और script names releases के बीच बदलते रहते हैं। कहीं से भी कॉपी किए गए कमांड पर भरोसा करने के बजाय, अपने स्वयं के checkout में bin field और npm run के आउटपुट को पढ़ें।

FAQ

Health check 'connection refused' क्यों दिखाता है?

Failed to connect to 127.0.0.1 port 18960 के साथ curl का exit code 7 यह दर्शाता है कि कनेक्शन विफल रहा है, न कि यह कि Memmy बंद है, क्रैश हो गया है, कहीं और listen कर रहा है या दुर्गम है। पता और पोर्ट की जाँच करें, ss -lntp | grep 18960 चलाएँ, और उस टर्मिनल या जर्नल को पढ़ें जहाँ service शुरू हुई थी। यदि लॉग में native SQLite module mismatch की रिपोर्ट मिलती है, तो npm rebuild better-sqlite3 चलाएँ। अपने Node version की भी जाँच करें: source docs के लिए Node 22 या उससे नया वर्ज़न आवश्यक है, जबकि Linux installer केवल 22.x के भीतर Node.js 22.23.4+, 24.x के भीतर 24.22.1+, या 26.x के भीतर 26.12.1+ को स्वीकार करता है।

Source से build करने के बाद memmy-memory कमांड कहाँ से आती है?

यह repository के नाम से नहीं, बल्कि @memmy/memory workspace package के bin field से आती है। checkout के भीतर node -p "JSON.stringify(require('./Memory/package.json').bin)" चलाएँ और यह {"memmy-memory":"./dist/src/cli/index.js"} प्रिंट करेगा। वह फ़ाइल केवल npm run memory:build के बाद मौजूद होती है, क्योंकि build प्रक्रिया dist बनाती है और फ़ाइल को executable के रूप में चिह्नित करती है। इसे node Memory/dist/src/cli/index.js health के रूप में चलाएँ, या छोटे नाम के लिए इसे /usr/local/bin में symlink करें।

क्या मैं claude mcp add के साथ Memmy को Claude Code में जोड़ सकता हूँ?

नहीं। Memmy एक MCP client है, MCP server नहीं। यह ~/.memmy/config.yaml में tools.mcpServers के तहत सूचीबद्ध servers से जुड़ता है और उनके tools को अपने runtime में उपलब्ध कराता है। Claude Code, Memmy तक विपरीत दिशा से पहुँचता है, यानी memmy-memory CLI को shell command के रूप में चलाकर। memmy-memory init --agent claude एक Skill और एक CLAUDE.md ब्लॉक लिखता है जो इसे बताता है कि कब क्या करना है, और Linux installer का launcher Claude Code hooks भी जोड़ता है जो turns को स्वचालित रूप से save करते हैं।

क्या Memmy चलाने से मेरी यादें (memories) क्लाउड सर्विस पर चली जाती हैं?

Scanning और ingestion स्थानीय रूप से चलते हैं, और यादें आपके अपने डिस्क पर ~/.memmy/memory-service/memory.sqlite में लिखी जाती हैं। .env.example में https://api.memmy.cn पर सेट MEMMY_CLOUD_SERVICE, account mode और trial tokens को serve करता है और उपयोग के analytics प्राप्त करता है (बिना memory text के), इसलिए यदि आप केवल API keys का उपयोग करते हैं तो इसे खाली रखें। memory improvement program के लिए एक अलग privacy toggle है। एक hosted embedding model उस memory text को प्राप्त करता है जिसे वह vector में बदलता है; उस प्रोसेसिंग को स्थानीय रखने के लिए built-in local provider या अपने द्वारा चलाए जाने वाले endpoint का उपयोग करें। जब hosted summary, evolution और relevance-filter models के कार्य चलते हैं, तो वे भी memory content प्राप्त करते हैं।