Flowise MongoDB Memory: Persistent Chatbot Conversations

Problem: Your Flowise Chatbot Forgets Everything on Refresh

By default, Flowise stores conversation history in memory — meaning every page refresh or server restart wipes the entire chat context. Users have to re-explain who they are, what they're building, and what was already discussed.

MongoDB Memory solves this by persisting session history to a database. Conversations survive restarts, scale across multiple Flowise instances, and can be queried or audited.

You'll learn:

• How to connect MongoDB (local Docker or Atlas) to a Flowise chatflow
• How to configure the MongoDB Memory node with session IDs
• How to verify persistence by killing and restarting Flowise

Time: 20 min | Difficulty: Intermediate

Why In-Memory Storage Breaks in Production

Flowise's default BufferMemory stores messages in the Node.js process heap. Three things kill it:

• Server restart — deploy, crash, or update wipes the heap
• Horizontal scaling — two Flowise containers don't share memory
• Long sessions — heap grows unbounded; large contexts slow inference

MongoDB Memory externalizes the message store. Each session maps to a document in a chathistory collection. The chatflow fetches it on every turn, appends the new exchange, and writes it back.

Symptoms of the problem:

• Chat replies "I don't have context from our previous conversation"
• After Flowise restart, users start from scratch
• Two browser tabs show different conversation states

Solution

Step 1: Run MongoDB

Option A — Docker (local dev):

# Start MongoDB 7 with a named volume so data survives container restarts
docker run -d \
  --name flowise-mongo \
  -p 27017:27017 \
  -v flowise-mongo-data:/data/db \
  -e MONGO_INITDB_ROOT_USERNAME=flowise \
  -e MONGO_INITDB_ROOT_PASSWORD=changeme \
  mongo:7

Expected output:

<container_id>

Verify it's running:

docker ps --filter name=flowise-mongo

Option B — MongoDB Atlas (cloud):

Create a free M0 cluster at cloud.mongodb.com. Under Database Access, add a user with readWrite on your target database. Under Network Access, whitelist your Flowise server IP (or 0.0.0.0/0 for testing).

Your connection string will look like:

mongodb+srv://flowise:<password>@cluster0.abc12.mongodb.net/flowise?retryWrites=true&w=majority

Step 2: Start Flowise with MongoDB Env Vars

If you're running Flowise via Docker, pass the MongoDB URI as an environment variable so it's available to your chatflow nodes:

docker run -d \
  --name flowise \
  -p 3000:3000 \
  --link flowise-mongo:mongo \
  -e PORT=3000 \
  -e FLOWISE_USERNAME=admin \
  -e FLOWISE_PASSWORD=yourpassword \
  -v flowise-data:/root/.flowise \
  flowiseai/flowise:latest

For Atlas, swap --link for the full URI — you'll paste it directly into the node in Step 4.

If it fails:

• ECONNREFUSED 27017 — MongoDB container isn't running or the --link alias is wrong; run docker ps to confirm both containers are up
• Authentication failed — double-check MONGO_INITDB_ROOT_USERNAME matches your URI credentials

Step 3: Build the Chatflow

Open Flowise at http://localhost:3000 and create a new chatflow. Add these nodes:

1. ChatOpenAI (or any LLM node — Ollama, Anthropic, etc.)
2. ConversationChain — wraps the LLM with memory
3. MongoDB Atlas Chat Message History — the memory node

Connect them: MongoDB Memory → memory port of ConversationChain → ConversationChain → output.

Your canvas should look like:

[MongoDB Memory] ──memory──▶ [ConversationChain] ──▶ output
                                    ▲
                              [ChatOpenAI]

Step 4: Configure the MongoDB Memory Node

Click the MongoDB Atlas Chat Message History node. Fill in:

{{sessionId}} is automatically populated by Flowise from the API request or chat widget. Each unique session ID maps to its own document — so different users don't share history.

If you hardcode a session ID (e.g., test-session-1) every user shares the same history. Only do this for testing.

Step 5: Save and Test

Click Save in the top-right, then open the chat panel (speech bubble icon).

Send a message:

My name is Alex and I'm building a customer support bot for a SaaS app.

Flowise replies. Now kill the Flowise container:

docker restart flowise

Wait for it to come back, reopen the chat with the same session ID, and send:

What was I building again?

Expected: The bot recalls your name and project from the previous session.

Verification

Connect to MongoDB and inspect the stored messages:

docker exec -it flowise-mongo mongosh \
  -u flowise -p changeme \
  --authenticationDatabase admin \
  --eval 'db = db.getSiblingDB("flowise"); printjson(db.chathistory.findOne())'

You should see:

{
  "_id": ObjectId("..."),
  "sessionId": "abc123",
  "messages": [
    { "type": "human", "data": { "content": "My name is Alex..." } },
    { "type": "ai",    "data": { "content": "Nice to meet you, Alex..." } }
  ]
}

If the collection is empty, the node isn't connected correctly — re-check that MongoDB Memory feeds into the memory port (not the model port) of ConversationChain.

What You Learned

• Flowise's default memory is ephemeral — MongoDB Memory is the production-ready alternative
• Session IDs are the key: {{sessionId}} isolates each user's history automatically
• Window Size controls how many past messages are included in each prompt — higher values improve context but increase token cost
• The same pattern works with Redis Memory if you prefer lower-latency lookups over persistence

Limitation: MongoDB Memory stores raw message objects, not embeddings. It's not semantic search — it's a sliding window of recent turns. For long-running sessions (100+ messages), consider summarizing old turns with a SummaryMemory node and only storing the summary.

Tested on Flowise 2.2.x, MongoDB 7.0, Docker 26, Ubuntu 24.04 and macOS Sonoma