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.
How it works
- Drop the compiled node into Flowise’s components directory and restart.
- MemorySync Memory appears under the Memory category — attach it to any Conversation Chain or Agent like a built-in node.
- Each chat keeps its own transcript in conversation history; the user’s messages are sent to fact extraction, and recall spans ALL of the user’s memories, from every chat and every MemorySync surface.
- “Clear this chat” clears exactly this chat — its transcript and the facts extracted from it, never the user’s whole memory.
Before you start
- A MemorySync API key. Create one in the dashboard under Settings → API Keys, inside a project.
- Self-hosted Flowise 3.0+ on Node 18.15+, or any community fork. (Flowise’s official development and hosted cloud were sunset in August 2026 and the FlowiseAI/Flowise repo is archived — but self-hosted deployments and forks keep working, and this node installs into any of them.)
Install (self-hosted, no fork)
Flowise scans exactly one directory for nodes — node_modules/flowise-components/dist/nodes (source-verified; no custom-nodes env var exists). Install the published package and copy two prebuilt artifacts in:
npm install flowise-memorysynccp -r node_modules/flowise-memorysync/dist/nodes/MemorySyncMemory <flowise>/node_modules/flowise-components/dist/nodes/cp node_modules/flowise-memorysync/dist/credentials/MemorySyncApi.credential.js <flowise>/node_modules/flowise-components/dist/credentials/# restart Flowise
The shipped node file is fully self-contained (its icon travels with it), so the copy is the whole install. After the restart, MemorySync Memory shows up in the node palette under Memory, and MemorySync API appears in the credentials list.
Wire a chatflow
Step 1 — attach the node
- 01
Chat Input
The end user sends a message in your Flowise chatflow.
- 02
Conversation Chain / Agent
The chain orchestrates the turn — with the Chat Model and MemorySync Memory attached as nodes.
- 03
MemorySync Memory node
Credential: MemorySync API · User ID:
{{$vars.userId}}· Session: leave empty for auto-per-chat. Recalls the user’s memories into a SystemMessage, keeps this chat’s transcript in conversation history, and sends the user’s messages to fact extraction. - 04
Chat Model
Generates the reply with the recall block and this chat’s transcript in context.
Step 2 — wire the user id
userId is required at design time — wire it from your app’s auth via Flowise variables ({{$vars.userId}}). It carries long-term memory across every chat. Leave Session ID empty and each chat automatically gets its own transcript 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… and vice versa.
What gets stored
- Transcript — each chat’s messages (user and assistant) are kept in MemorySync’s conversation history for that session and replayed into the flow, up to History Window turns. The transcript is not part of the user’s memories: it does not appear in memory lists, search or recall.
- Long-term memory — user messages are also sent to fact extraction, so durable facts (“I’m allergic to peanuts”) become memories of the User ID and are recalled in every chat. Assistant replies stay in the transcript.
- Clearing a chat — removes that session’s transcript and the facts extracted from it. Other chats, and memories from other MemorySync surfaces, are untouched.
Node settings
| Setting | Default | Meaning |
|---|---|---|
userId | — (required) | End user the memories belong to |
sessionId | auto (Flowise chat) | Transcript scope: flowise::<session> |
topK | 5 | Memories per recall |
recallTimeoutMs | 1200 | Hard recall budget; fails open to history-only |
historyWindow | 10 | Transcript turns replayed per context |
searchOnly | false | Recall without storing new turns |
Quotas and plan limits
Hitting a monthly plan limit never breaks a chatflow. Over-limit writes are accepted without storing and recalls return empty — the chain keeps answering from the live transcript. Evaluation keys instead surface a truthful 429, so limits show up in testing, not production.
Billing counts requests, not results. The node saves the user’s message and the reply as two separate turns, so one exchange is two adds. Reading the transcript is one retrieval, and the recall is one more (two when it returns nothing and the semantic fallback runs). A retried turn is not counted again, and clearing a chat is free.
Troubleshooting
- Node missing from the palette — the copy landed outside
node_modules/flowise-components/dist/nodes, or Flowise wasn’t restarted. Re-check the path; there is no custom-nodes env var. - Node lost after upgrading Flowise — upgrades replace
node_modules; re-run the two copy commands. - Save fails on `userId` — required by design: without it every end user would share one memory partition.
- A reply came without memories — the 1.2s recall budget fails open to history-only rather than stalling the chat.
- “Clear this chat” didn’t wipe the user’s memory — correct: clears are session-scoped. Long-term memories are managed from the MemorySync dashboard or API.
Supported versions
| Surface | Requires | Verified on |
|---|---|---|
flowise-memorysync 1.1.0 | Flowise 3.0+ self-hosted (Node 18.15+) and community forks — Flowise’s hosted cloud was sunset in August 2026 | 31 CI checks through the node’s real init() with fake INodeData against a live mock MemorySync serving production response shapes — required userId, user/session separation, the transcript kept in conversation history (never in memory lists), user messages sent to fact extraction, session-scoped clears that delete the transcript and its facts, 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 the final Flowise release, and a full real-host verification: the published package installed into a live Flowise 3.1.4 server, wired into a real ChatOpenAI chatflow, and driven through real conversations — teach in one chat, recall in a brand-new chat |
How it compares
| Mem0 node (in-tree) | Zep nodes (in-tree) | Supermemory / Letta | MemorySync | |
|---|---|---|---|---|
| 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 memory | n/a | — | ✓ userId required at design time |
| "Clear this chat" | ✗ calls Mem0 clear() — wipes the user’s ENTIRE memory | session delete | — | ✓ deletes THIS chat’s transcript and the facts extracted from it, nothing else |
| Recall in context | ✗ facts cast as any onto an assistant-role message, double-stuffed with raw DB turns | summary only | — | ✓ ONE labeled block; a real SystemMessage in the base-message path |
| Missing output turn | both-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 extractions | duplicates | — | ✓ deterministic idempotency keys — a retried turn is stored and extracted once |
| Dependencies | their SDK + params the SDK already removed | deprecated @langchain/classic imports | — | ✓ zero runtime deps (built-in fetch) |