SSD Nodes Learn 8GB RAM — $66/taon
Mga Gabay Matt ConnorNi Matt Connor · Na-update 2026-08-02

Memmy: shared memory hub ng AI agents sa VPS

Alamin kung paano i-build ang Memmy 1.0.4 mula sa source sa Ubuntu, patakbuhin ang local memory service sa port 18960, at panatilihing local ang bawat note.

Ano ang Memmy at ano ang iniimbak nito

Ang Memmy ay isang local memory hub para sa mga AI agent na tumatakbo sa sarili mong VPS (virtual private server). Nag-iimbak ito ng isang SQLite database na naglalaman ng natutuhan ng mga agent, at binabasa at sinusulatan ng bawat agent sa server ang parehong store. Ang proyekto ay memmy-agent mula sa MemTensor, lisensyado sa ilalim ng MIT, at nasa version 1.0.4 noong July 2026.

Ilang bahagi lang nito ang kailangan sa isang server. May memory service ang Memmy na nakikinig sa http://127.0.0.1:18960, isang memmy-memory command line interface (CLI) na kumokonekta sa service na iyon, at isang desktop workbench. Para lamang sa macOS at Windows ang workbench, kaya sa Linux VPS pinapatakbo mo ang service at ang CLI. Sapat na ito para mabigyan ang Claude Code, Codex at Cursor ng shared memory.

Inaayos ng Memmy ang iniimbak nito sa apat na layer. Ang L1 Trace ay ang raw turn: ang request, response at mga tool call. Ang L2 Policy ay isang procedure na nabuo mula sa mga trace na napatunayang kapaki-pakinabang. Ang L3 World Model ay matatag na kaalaman tungkol sa isang project o environment. Ang Skill ay isang callable procedure na nabuo mula sa isang policy. Awtomatikong nagtatalaga ng layer ang service kapag nag-i-ingest ito ng turn, kaya hindi mo kailangang gawin ang mga ito nang mano-mano.

Ano ang nagbabago sa shared memory hub kumpara sa memory ng bawat tool

Ang bawat agent ngayon ay may sarili nitong memory. Pinapanatili ng Claude Code ang mga instruction file sa repository. Pinapanatili ng Cursor ang mga rule sa workspace database nito. Pinapanatili ng Codex ang mga session log sa ilalim ng ~/.codex. Nakalaan ang bawat store sa isang tool, kaya hindi alam ng ibang tool sa Martes ang itinuro mo sa isang tool noong Lunes. Dalawang beses mo itong binabayaran: una, sa mga token na ginagamit para ipaliwanag muli ang parehong project; at ikalawa, sa maling trabaho kapag kumilos ang isang agent batay sa palagay na naitama mo na sa ibang lugar.

Inililipat ng hub ang store palabas ng tool. Binabasa rin ng Memmy ang mga kasalukuyang store, kaya hindi ka magsisimula sa walang-laman na database. Alam ng scanner nito ang anim na source: Claude Code sa ~/.claude/projects/**/*.jsonl, Codex sa ~/.codex/sessions/<YYYY>/<MM>/<DD>/rollout-*.jsonl, OpenCode sa ~/.local/share/opencode/opencode.db, mga file ng Cursor sa state.vscdb, mga SQLite database ng OpenClaw sa ilalim ng ~/.openclaw, at Hermes sa ilalim ng ~/.hermes. Maaari kang manu-manong magdagdag ng source gamit ang pangalan at local path nito.

Hindi magtutugma ang mga import counter, at inaasahan ito. Pinapangkat ng scanner ang mga message ayon sa source at conversation, pagkatapos ay nagsusulat ito ng isang L1 memory para sa bawat kumpletong turn. Kumpleto ang isang turn kapag may non-empty na user content ito at nagtatapos sa non-empty na assistant message. Kaya walang naiaambag ang naantalang session. Tinatanggal ang duplicate na message gamit ang conversation checkpoint at stable turn ID. Magkakaiba sa parehong run ang scanned count, imported message count, at new memory count.

Ito ang bahaging kaugnay ng kung paano pinamamahalaan ng Claude Code ang context sa loob ng isang session. Tinutukoy ng context management kung ano ang kasya sa iisang window. Tinutukoy ng memory hub kung ano ang nananatili pagkatapos magsara ang window na iyon.

Mga kailangan sa VPS

  • Node.js 22 o mas bago. Ito ang kinakailangan ng Memmy docs, at Node 18 ang kasama sa Ubuntu 24.04.
  • git at build toolchain, dahil native module ang better-sqlite3 na maaaring i-compile habang ini-install.
  • Humigit-kumulang 2 GB ng RAM. Kumukuha ang root install ng malaking workspace at frontend build chain.
  • Ilang GB ng libreng disk para sa node_modules at database.
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

Dapat mag-print ang node --version ng v22 o mas mataas. Ang v18 rito ay nangangahulugang hindi naisagawa nang tama ang NodeSource step, kaya mabibigo ang installation sa engine check ng project.

I-install ang Memmy mula sa source sa Ubuntu 24.04

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

Kino-compile ng npm run memory:build ang workspace na @memmy/memory at inilalabas ito bilang Memory/dist. Wala nang ibang kailangang i-build sa tree para sa isang headless server. Tiyaking na-load ang native module:

node -e "require('better-sqlite3'); console.log('better-sqlite3 loads')"

Kung nag-throw ang linyang iyon sa halip na mag-print, hindi tugma ang native module sa iyong Node version. Patakbuhin ang npm rebuild better-sqlite3. Ito mismo ang ginagawa ng sariling start script ng proyekto bago ito maglunsad ng anuman.

Idinodokumento ng README ang bash scripts/dev-start.sh bilang isang one-command start. Huwag itong patakbuhin sa isang headless VPS. Sinisimulan nito ang Electron desktop shell at isang Vite dev server sa port 19000 kasabay ng memory service. Kailangan ng Electron ng display, kaya sa server na walang graphical session, maaaring ma-stall o mag-exit ang script.

Simulan ang memory service at tiyaking sumasagot ito

npm run memory:serve:dev

Ito ang dokumentadong paraan para patakbuhin ang memory service mula sa source. Nagbi-bind ito sa 127.0.0.1:18960, pinapanatili ang database sa ~/.memmy/memory-service/memory.sqlite, at nagbabasa ng config mula sa ~/.memmy/config.yaml. Inililista rin ng README ang parehong value kapag gusto mong tahasang tukuyin ang mga ito:

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

Mula sa pangalawang shell, tanungin ang service kung gumagana ito:

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

Ang health ang endpoint na hindi kailanman humihingi ng token, kaya ito ang tamang probe. Kung lalabas ang curl na may code 7 at mensaheng Failed to connect to 127.0.0.1 port 18960, walang nakikinig. Basahin ang terminal na nagpapatakbo ng service, dahil doon lumalabas ang crash sa startup. Karaniwang sanhi nito ang hindi pag-load ng native SQLite module. Kinukumpirma ng ss -lntp | grep 18960 ang socket kapag gumagana na ang service.

Nasa ilalim ng /api/v1 ang natitirang HTTP API (application programming interface).

  • Nagsusulat ang POST /api/v1/memory/add ng memory at nagtatanong ang POST /api/v1/memory/search.
  • Nagbabasa at nag-aalis ang GET /api/v1/memory/:id at DELETE /api/v1/memory/:id ng isang entry.
  • Nagbubukas at nagsasara ang POST /api/v1/sessions/open at POST /api/v1/sessions/:sessionId/close ng agent session.
  • Nagtatala ang POST /api/v1/turns/start at POST /api/v1/turns/:turnId/complete ng isang turn.
  • Nagpapadala ang GET /api/v1/panel/overview, /api/v1/panel/analysis at /api/v1/panel/items ng data sa dashboard.

Nagrereserba ang Memmy ng block ng mga port, at sa headless mode, ang una lamang ang ginagamit mo: 18960 para sa memory, 18970 para sa gateway health, 18980 para sa web UI at admin HTTP, 18990 para sa OpenAI-compatible API na sinisimulan ng memmy serve, at 19000 at 19010 para sa dev server ng desktop frontend. Kung may ibang process sa iyong machine na gumagamit na ng isa sa mga ito, dito dapat tingnan.

Saan talaga nagmumula ang memmy-memory command

Dito karaniwang nagkakamali ang unang installation, kaya basahin ito mula sa package sa halip na manghula. Walang kaugnayan ang pangalan ng command sa pangalan ng repository. Nagmumula ito sa field na bin ng workspace na nagde-define dito:

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

Ipinapakita nito ang {"memmy-memory":"./dist/src/cli/index.js"}. Kaya ang built entry point ay Memory/dist/src/cli/index.js, at umiiral lamang ito pagkatapos ng npm run memory:build, dahil ang build ang lumilikha sa dist at nagmamarka sa file bilang executable. Direktang patakbuhin ito:

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

Kung gusto mo ang maikling pangalan sa iyong PATH, gumawa ng link patungo sa parehong file:

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

Bilang default, ginagamit ng CLI ang http://127.0.0.1:18960 at tinatanggap nito ang --url, --token, --config, --source at --user-id. Ang mga subcommand nito ay init, health, search, add, get at delete, pati ang mga session at turn call na ginagamit ng mga agent sa halip na ng mga user. Ang memmy-memory search "deploy steps" at memmy-memory add "staging migrates on deploy" ang dalawang command na pinakamadalas patakbuhin ng isang agent.

Paano ikonekta ang Claude Code sa Memmy?

Walang memory plugin interface ang Claude Code, kaya hindi ito direktang kinokonekta ng Memmy. Mas simple ang integration. Pinapatakbo ng Claude Code ang memmy-memory bilang ordinaryong shell command, at sinasabi ng isang instruction file kung kailan ito gagawin. Isinusulat ng documented installer ng Memmy ang file na iyon para sa iyo: inilalagay ng memmy-memory init --agent ang isang memory instruction file sa rules directory ng target agent.

Isulat nang manu-mano ang instruction kahit isang beses, para alam mo kung ano mismo ang itinuro sa agent. Binabasa ng Claude Code ang CLAUDE.md mula sa project root sa simula ng bawat session, kaya sapat na ang isang seksyong tulad nito para sa buong integration:

## 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.

Maging malinaw sa pakinabang nito. Instruction-level integration ito, kaya gumagana lamang ito kapag nagpasyang patakbuhin ng model ang command. Walang pumipilit sa pagtawag dito. Kung matatapos ang session nang walang add, walang mase-save, at ang tanging palatandaan ay walang resultang makukuha sa susunod na paghahanap. Kapareho ito ng trade-off sa sariling memory files ng Claude Code, ngunit may isang pagkakaiba: shared ang store, kaya nakakarating din ang note sa Codex at Cursor sa parehong machine.

Hindi nangangailangan ng anumang setup ang kabilang direksiyon. Binabasa na ng scanner ng Memmy ang ~/.claude/projects/**/*.jsonl, kung saan isinusulat ng Claude Code ang mga transcript ng session nito. Patakbuhin ang Memmy sa parehong server kung saan mo pinapatakbo ang Claude Code sa loob ng isang tmux session, at magiging memory ang ginawa mo kahapon nang wala kang kailangang i-configure.

Gumagana ba ang Memmy bilang MCP server para sa Claude Code?

Hindi, at makatutulong na malaman ito agad upang maiwasan ang pag-aaksaya ng oras. May mga client at server ang MCP (model context protocol). Client ang Memmy. Kumokonekta ito sa mga MCP server at inilalagay ang mga tool ng mga ito sa sarili nitong agent runtime. Hindi ito naglalantad ng MCP endpoint na maaaring pag-ugnayan ng claude mcp add. Ang tanging MCP bridge sa repository ay kabilang sa Composio integration sa loob ng desktop local API. Nagbi-bind ang API na iyon sa isang random port sa 127.0.0.1 at gumagamit ng sarili nitong x-memmy-mcp-token header.

Naka-configure ang client side sa ~/.memmy/config.yaml, ang file na tinutukoy ng MEMMY_CONFIG, sa ilalim ng tools.mcpServers:

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

Tumatanggap ang type ng stdio, sse at streamableHttp. Tumatakbo ang stdio server bilang child process ng Memmy. Ibig sabihin, dapat umiiral ang command nito sa parehong machine at tumakbo bilang parehong user. Kung mayroon ka nang mga MCP server na tumatakbo sa isang VPS, iyon ang mga dapat ilista rito.

Pananatiling pribado ng memory store

Lahat ng pagmamay-ari ng Memmy ay nasa ilalim ng ~/.memmy: config.yaml, workspace, memory-service/memory.sqlite, at mga runtime file. Lokal na isinasagawa ang scanning at ingestion, at isinusulat ang mga memory sa lokal na SQLite file na iyon, kaya tunay na lokal ang default na configuration.

May 2 path na kumokonekta sa network. Ang MEMMY_CLOUD_SERVICE ay naka-default sa https://memmy-api.memtensor.cn at ginagamit ng account mode kasama ng trial tokens nito, kaya hindi ito tinatawagan ng API key mode. Hiwalay na toggle ang memory improvement program sa privacy settings at naka-off ito hanggang i-on mo.

Mas madaling hindi mapansin ang ikatlong path. Kung mag-configure ka ng hosted embedding provider, ipinapadala ang text ng bawat memory sa provider na iyon upang ma-convert ito sa vector. Hindi ito napipigilan ng lokal na storage. Ang sariling embedding endpoint na ikaw ang nagho-host ang tanging paraan para isara ang path na ito.

Panatilihin ang port 18960 sa loopback address. Hindi ito nangangailangan ng firewall rule, dahil ang service na naka-bind sa 127.0.0.1 ay hindi talaga maa-access mula sa labas ng machine. Gamitin ang SSH para ma-access ito mula sa iyong laptop:

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

Kung ib-bind mo ito sa mas malawak na address, magtakda muna ng token. Kapag itinakda mo ang storage.token sa config, o ang MEMMY_MEMORY_TOKEN o MEMORY_SERVICE_TOKEN environment variable, mangangailangan ng bearer token ang bawat endpoint maliban sa health endpoint. Sinusuportahan ng config values ang ${ENV_NAME} references, kaya nananatili sa labas ng file mismo ang token at ang iyong model API keys. Pareho itong kasanayan sa pag-iwas na ilagay ang mga secret sa AI agents saanman, at ang default deny na ufw policy ang magsisilbing karagdagang proteksiyon kung babaguhin ng hinaharap na version ang default bind address nito.

I-back up ang ~/.memmy bago ito pagkatiwalaan

memory.sqlite ang buong store. Nasa parehong file ang mga vector sa pamamagitan ng sqlite-vec extension, kaya isang file lang ang kailangan para sa backup. Ang pagkopya nito gamit ang cp habang nagsusulat ang service ay maaaring magdulot ng naputol na database. Gamitin ang sariling backup command ng SQLite:

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

Gagawa ito ng consistent na kopya habang patuloy na tumatakbo ang service. I-push ito palabas ng box ayon sa iskedyul; para rito ang restic para sa off-site storage. Kapag nawala ang config.yaml, mawawala ang provider settings na maaari mong i-type muli. Kapag nawala ang memory.sqlite, mawawala ang lahat ng memory, at walang ibang bahagi ng machine ang may pangalawang kopya.

Patakbuhin ang memory service sa systemd

Ang npm run memory:serve:dev sa shell ay humihinto kapag huminto ang shell. Pinananatiling tumatakbo ng unit file ang service kahit mag-reboot.

[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

Huwag ilagay ang token sa unit. Ilagay ito sa /etc/memmy/memory.env, pagmamay-ari ng root, na may 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

Ang status=203/EXEC sa status output ay nangangahulugang hindi talaga napatakbo ng systemd ang ExecStart, kaya suriin ang which npm: ito ay /usr/bin/npm kapag NodeSource install at nasa loob ng home directory ng user kapag nvm, na hindi mahahanap ng systemd. Kung agad nagsisimula at humihinto ang unit, nagkaroon ng error sa loob mismo ng npm, at ipinapakita ng journalctl -u memmy-memory -n 50 ang dahilan. Pareho ang mga hakbang nito sa iba pang systemd service sa isang VPS.

Mga hindi pa ginagawa ng Memmy

  • Wala pang Linux desktop build. Saklaw ng packaging scripts ang macOS at Windows, kaya hindi available mismo sa server ang workbench, onboarding wizard nito, at memory dashboard.
  • Pinapatakbo ng memory:serve:dev ang TypeScript entry point sa pamamagitan ng tsx, na development path. Kasama rin sa repository ang memory:serve para sa compiled output. Patakbuhin ang npm run nang walang arguments para makita kung aling scripts ang aktuwal na mayroon sa iyong checkout.
  • Binubuo ng retrieval ang search window mula sa pinakabagong 2,000 vector rows, pagkatapos ay inilalapat ang Top-K selection sa loob ng window na iyon. Sa napakalaking store, maaaring nasa labas nito ang lumang memory.
  • Isinasagawa ang embedding pagkatapos ng capture, at napupunta sa retry queue ang anumang failure sa halip na harangan ang turn ng agent. Maaaring hindi pa makita ng vector search ang memory na idinagdag kamakailan.
  • Isang node lamang ang kayang suportahan ng isang SQLite file. Walang clustering, kaya ang pangalawang server ay hiwalay na memory.

Ang Version 1.0.4 at humigit-kumulang 329 stars noong July 2026 ay nagpapakitang bata pa ang project. Nagbabago ang flags, paths at script names sa bawat release. Basahin ang bin field at ang output ng npm run sa sarili mong checkout sa halip na umasa sa command na kinopya mula saanman, kabilang dito.

FAQ

Bakit nagbabalik ang health check ng connection refused?

Walang nakikinig sa port 18960. Ang curl exit code 7 na may Failed to connect to 127.0.0.1 port 18960 ay nangangahulugang hindi tumatakbo ang memory service o namatay ito sa pagsisimula, kaya basahin ang terminal o ang journal kung saan ito nagsimula. Ang dalawang karaniwang sanhi ay isang better-sqlite3 native module na hindi tugma sa iyong Node version, na inaayos gamit ang npm rebuild better-sqlite3, at isang Node version na mas mababa sa 22. Kumpirmahin ang socket gamit ang ss -lntp | grep 18960 kapag gumagana na ang service.

Saan nanggagaling ang memmy-memory command pagkatapos mag-build mula sa source?

Nanggagaling ito sa bin field ng @memmy/memory workspace package, hindi sa pangalan ng repository. Patakbuhin ang node -p "JSON.stringify(require('./Memory/package.json').bin)" sa loob ng checkout at ipi-print nito ang {"memmy-memory":"./dist/src/cli/index.js"}. Umiiral lamang ang file na iyon pagkatapos ng npm run memory:build, dahil lumilikha ang build ng dist at minamarkahan nitong executable ang file. Patakbuhin ito bilang node Memory/dist/src/cli/index.js health, o gumawa ng symlink nito sa /usr/local/bin para sa maikling pangalan.

Maaari ko bang idagdag ang Memmy sa Claude Code gamit ang claude mcp add?

Hindi. MCP client ang Memmy, hindi MCP server. Kumokonekta ito palabas sa mga server na nakalista sa ilalim ng tools.mcpServers sa ~/.memmy/config.yaml at iniaalok ang kanilang mga tool sa sarili nitong runtime. Kumokonekta ang Claude Code sa Memmy sa kabilang paraan, sa pamamagitan ng pagpapatakbo sa memmy-memory CLI bilang shell command, batay sa instruction file na isinusulat ng memmy-memory init --agent sa rules directory ng agent.

Ipinapadala ba ng pagpapatakbo sa Memmy ang aking mga memory sa isang cloud service?

Lokal na tumatakbo ang scanning at ingestion, at isinusulat ang mga memory sa ~/.memmy/memory-service/memory.sqlite sa sarili mong disk. Tinutukoy ng MEMMY_CLOUD_SERVICE ang https://memmy-api.memtensor.cn para sa account mode at trial tokens, at nananatiling naka-off ang memory improvement program hanggang sa paganahin mo ito. Ang dapat mong subaybayan ay ang embedding provider: tumatanggap ang isang hosted embedding model ng text ng bawat memory na ginagawa nitong vector, kaya gumamit ng endpoint na ikaw mismo ang nagpapatakbo kung mahalaga ito.