Flowise + MemorySync

Overview

Drop the MemorySync Memory node into any Flowise chatflow and long-term memory finally works the way visual builders need it to: userId (required) carries memories across every chat and every MemorySync surface, while each Flowise chat session keeps its own transcript in MemorySync conversation history, apart from the user’s memories, and the durable facts in user messages are extracted into memories. The in-tree Mem0 node conflates the two — its "Use Flowise Chat ID" toggle makes memory silently reset on every new chat, it ships a shared flowise-default-user default partition, its recall blob is force-cast onto an assistant-role message, and its "clear this chat" calls Mem0’s clear(), wiping the user’s ENTIRE memory. The Zep nodes have no user dimension at all and silently drop turns unless both sides are present. Here: recall arrives as ONE labeled block (a real SystemMessage in the base-message path) under a hard 1.2s budget that fails open to history-only context, the transcript is replayed up to the History Window, every turn is appended independently with a deterministic idempotency key, and clearing a chat deletes that session’s transcript and the facts extracted from it, nothing else. Zero runtime dependencies — the node uses built-in fetch and can never version-conflict with Flowise’s tree.

Setup status and requirements

Supported version

flowise-memorysync 1.1.0 (drop-in node)

Last setup review

2026-10-01

Permissions

A MemorySync API key with read and write scopes.

Limits

Self-hosted Flowise 3.0+ or community forks: build the package (npm run build), then copy the compiled node and credential into flowise-components/dist/nodes and dist/credentials (no custom-nodes env var exists). Flowise’s hosted cloud and official development were sunset in August 2026; self-hosted deployments keep working.

Capabilities

• Separate user + session scopes — memory follows the user, transcripts stay per-chat
• userId REQUIRED — no shared default partition
• "Clear this chat" deletes that chat’s transcript and its facts — never the account
• Recall as ONE labeled block — a real SystemMessage, not an assistant-role cast
• Every turn persists independently — no both-or-nothing drops
• Hard 1.2s recall budget, fails open to history-only
• Deterministic idempotency keys — a retried turn is stored and extracted once
• Zero runtime dependencies (built-in fetch)

Quick Start

Chatflow wiring:

[Chat Input]
     │
[Conversation Chain / Agent]
     │            │
[Chat Model]   [MemorySync Memory]   ← Memory category
                    │ credential: MemorySync API
                    │ User ID:  {{$vars.userId}}
                    │ Session:  (empty — auto per chat)

Use Cases

Explore More