Does Node-RED Remember Between Runs? Context, Restarts, and What Your Scheduled Flows Actually Keep

Short answer: only the values you deliberately put into context, and by default not even those survive a restart. Node-RED gives every flow access to context storage, but the default store is memory only, and the official docs are plain about what that means: its contents are cleared whenever Node-RED restarts. A scheduled flow can run for weeks and still wake up with nothing, because a single restart, deploy, or container update in the middle wipes what it thought it knew.

That surprises people because context feels like memory while everything is running. It is, right up until the runtime stops.

Messages carry no past with them

Node-RED is built around messages passing from node to node. Each message is its own event. A Function node receives a message, does its work, and sends a result onward, and ordinary variables inside that function are created fresh for every message that arrives. Nothing about the message stream itself remembers the previous message, the previous hour, or the previous run of a timed flow.

That design is deliberate and it is good engineering for automation. It also means a flow triggered by an Inject node on a schedule starts each run from the flow definition and the trigger payload alone. If the flow checks a feed every hour and posts what is new, the flow itself has no built-in answer to the question "what did you already post?" That answer has to live somewhere outside the message stream.

Context: the memory Node-RED does offer

Context is that somewhere, in three scopes: node context for a single node, flow context for everything on one flow tab, and global context shared across all flows. A Function node can read and write it with calls like flow.get() and flow.set(), and Change nodes can set it without code. While Node-RED keeps running, context works exactly as expected. A flow can store the last item it processed, increment a counter, or hold a token, and the next run can read it back.

The catch is storage. Out of the box, context lives in the memory of the Node-RED process. Restart the process and it is gone. Redeploy in a container, let a host reboot overnight, or move to a hosted instance that updates its stack, and every stored value disappears with it. Flows do not warn you when this happens. They simply start behaving like first runs: reprocessing items, repeating alerts, and asking the same questions again.

Persistent context fixes the restart, not the model

Since version 0.19, Node-RED has let you change where context is stored. The contextStorage setting in settings.js can point the default store, or an additional named store, at the built-in localfilesystem module instead of memory. With file storage enabled, context is written under ~/.node-red/context/ and survives restarts.

Two details matter before you treat that as solved. First, the file store caches values in memory and only writes them out every 30 seconds by default, so a hard crash can still lose the most recent updates. Second, and more important for AI work, file context is still just a key-value store on one Node-RED instance. It holds exactly the values your flows explicitly set, in exactly the shape they set them. It does not record conversations. It does not capture what an AI node reasoned about, decided, or told a customer, unless a flow was hand-built to save a summary of it. And it cannot be read by anything outside that instance: not by a second Node-RED host, not by an n8n or Make scenario, and not by the AI tools you chat with during the day.

So persistent context answers "does it survive a restart?" It does not answer "does my automation actually remember its work?"

What scheduled AI flows actually need to remember

Put an AI step inside a scheduled Node-RED flow and the gap gets specific. The flow needs to remember at least three kinds of things between runs:

• Completed work. Which items were already processed, posted, enriched, or answered, so the next run skips them instead of repeating them.
• Decisions and outcomes. What the agent concluded last time, what a customer replied, what was escalated, and what was promised.
• Shared context. The facts and preferences that other automations and other AI tools have already learned, so this flow does not start from a narrower picture than the rest of your setup.

Context, even persistent context, can hold the first item if you build and maintain the bookkeeping yourself, one flow at a time. The second and third are where hand-rolled storage breaks down, because nobody builds a flow that transcribes every conversation and decision into context keys, and a file on one instance cannot be shared anyway.

Three ways to give a scheduled Node-RED flow a real memory

1. Turn on persistent context for simple state. If a flow only needs a last-seen ID, a counter, or a small flag to survive restarts, configure the localfilesystem store in settings.js and make sure the flow writes to it. This is the right-sized fix for plain automation state.

2. Keep an external ledger for completed work. For flows that process items, store the record of what was done in a database or table outside Node-RED, read it at the start of every run, and write outcomes back at the end. The read-before-acting step has to be non-optional, or the flow will redo work whenever the ledger is skipped.

3. Give the agent a shared memory layer. The first two fixes are per-flow, per-instance plumbing. Every new flow needs its own storage decisions, and none of them can see what the others learned. A hosted memory layer changes that shape. Vilix AI is a cloud-hosted memory layer your agents reach over MCP, so there is no infrastructure to run and no context files to maintain. The same memory follows the work across Node-RED, n8n, Claude, ChatGPT, and every other tool you connect, and it stores full conversation history, not just extracted facts, so a run can pick up the actual thread of what was said and decided. It is free forever on the free plan, with a 7-day Pro trial that needs no credit card, and you can export or delete everything at any time.

The bottom line

Node-RED remembers what you store in context, only while it keeps running, and across restarts only if you switch context to file storage yourself. Messages carry no past, AI steps record nothing on their own, and a context file on one instance is invisible to every other tool you use.

If your scheduled flow keeps starting from zero, the fix is not a cleverer function node. It is a memory the flow can read before it acts, write to after it acts, and share with everything else you run.