Dify KB Memory

Cross-session memory tool plugin for self-hosted Dify. User memory is stored in
a regular Dify knowledge base: one document per user ("memory file"), one
chunk per fact. No external services are required: embeddings, indexing, and
retrieval are handled by Dify itself.

Source repository: https://github.com/neyara11/dify-memory

How it works

• Each user gets a document named in the configured
  knowledge base.
• Every memory is a separate chunk (fact, preference, goal, dialog summary)
  with keywords.
• The mapping is kept in the plugin's persistent
  key-value storage; it is restored by document name if lost and reset
  automatically when a document no longer exists. No database of your own is
  needed.
• A metadata field is set on each document, and retrieval uses
  server-side , so all top-K slots belong to the
  requested user instead of being mixed across users. Dify caps retrieval at
  ~10 chunks per request; tops up results with a keyword match
  over the chunk list, and paginates without that cap.
• Identity resolution: the tool parameter (user id or email) falls
  back to the Dify runtime end-user id () and then to
  .

Tools (for the Agent node)

All parameters except / use , so the agent decides what
to save or delete and fills in the content itself.

Installation

1. Knowledge base. Create a knowledge base in Dify to hold memories:
   • configure an embedding model in the knowledge base settings (
     indexing is used);
   • enable API Access and create a knowledge base API key;
   • note the knowledge base ID (visible in the Dify URL).
2. Plugin. Build and install: Install the through Plugins -> Install plugin (Local), or with
   .
3. Tool configuration (in the tool card):
   • — inside docker-compose use
     , otherwise ;
   • — the key from step 1;
   • — the knowledge base ID;
   • — by default.

The plugin contacts only the configured Dify API base URL. No data is sent to
any third-party service.

Agent node setup

Add all four tools to the agent and provide a system prompt such as:

can be left empty: the platform supplies the Dify end-user id. If you
have your own user accounts (email, internal id), have the agent pass that value
in so memory is grouped by it.

Development

Limitations

• Dify retrieval returns at most ~10 chunks per request. That covers the reply
  context; the full memory is available through (paginated).
• A newly created chunk is indexed in a few seconds. The plugin waits for the
  document to finish indexing on the first save for a user.
• Retrieval runs across the configured knowledge base; do not store unrelated
  knowledge in the memory knowledge base.
• The document mapping lives in Dify's plugin KV storage (inside your instance).