MemorySync
Getting Started

Flowise Memory

A MemorySync Memory node for Flowise chatflows with SEPARATE user and session scopes: long-term memory follows the user across every chat while each chat keeps its own transcript — with session-scoped clears, a SystemMessage recall block, and a hard recall budget.

What installs

Flowise scans exactly one directory for nodes — node_modules/flowise-components/dist/nodes (source-verified; no custom-nodes env var exists). Drop the compiled node in, restart, and MemorySync Memory appears under the Memory category:

# from the flowise-memorysync package
npm run build
cp -r dist/nodes/MemorySyncMemory <flowise>/node_modules/flowise-components/dist/nodes/
cp dist/credentials/MemorySyncApi.credential.js <flowise>/node_modules/flowise-components/dist/credentials/
# restart Flowise

Flowise Cloud requires the node upstream — the PR to FlowiseAI/Flowise is prepared (same file, path-swapped imports) and pending.

Mem0 node (in-tree)Zep nodes (in-tree)Supermemory / LettaMemorySync
User vs session✗ conflated — the chat-id toggle makes memory silently reset on every new chat✗ session is the ONLY dimension — no cross-chat recall— no node at all✓ both dimensions: required userId + per-chat session
Default partition✗ ships user_id: flowise-default-user — keep the default and every user shares one memoryn/auserId required at design time
"Clear this chat"✗ calls Mem0 clear()wipes the user’s ENTIRE memorysession delete✓ deletes THIS session’s rows only
Recall in context✗ facts cast as any onto an assistant-role message, double-stuffed with raw DB turnssummary only✓ ONE labeled block; a real SystemMessage in the base-message path
Missing output turnboth-or-nothing✗ silently drops the turn✓ every turn persists independently
Latency guard✗ none✗ none✓ 1.2s recall budget, fails open to history-only
Retries✗ duplicate extractionsduplicates✓ deterministic idempotency seeds
Dependenciestheir SDK + params the SDK already removeddeprecated @langchain/classic imports✓ zero runtime deps (built-in fetch)

User vs session — the point

userId (required — wire it from your app’s auth, Flowise variables work: {{$vars.userId}}) carries long-term memory across every chat and every MemorySync surface. The Flowise chat session scopes the transcript automatically — leave Session ID empty and each chat gets its own history while recall still spans all of the user’s memories. A fact learned in Flowise is recallable from LangChain agents, Dify, the CLI, voice agents…

SettingDefaultMeaning
userId— (required)End user the memories belong to
sessionIdauto (Flowise chat)Transcript scope: flowise::<session>
topK5Memories per recall
recallTimeoutMs1200Hard recall budget; fails open to history-only
historyWindow10Verbatim turns replayed per context
searchOnlyfalseRecall without storing new turns

Supported versions

SurfaceRequiresVerified on
flowise-memorysync 1.0.0Flowise 3.x self-hosted (Node 18.15+); Flowise Cloud pending the upstream PR21 CI checks through the node’s real init() with fake INodeData against a live mock MemorySync — required userId, user/session separation, session-scoped clears, the SystemMessage recall block, independent turn persistence, seeds, the 1.2s fail-open budget, quota modes — plus a drift check diffing the vendored memory contract against Flowise main on every push

Where to go next

Was this page helpful?