Managing State in Node-RED: When to Use Node, Flow, and Global Context
Stop losing data between nodes. Learn how to use Node, Flow, and Global context in Node-RED to manage state, implement toggle logic, and ensure data persists across restarts.
06 Jul 2025, 09:02 UTC

The Stateless Message Problem
\nNode-RED operates on a stateless event-driven model. Every message (the msg object) is a transient packet of data that travels from one node to the next. Once a message leaves a node, that node \"forgets\" everything about it. This creates a challenge when you need to remember something from a previous event—such as whether a light is currently on, the last temperature reading from a sensor, or a counter for how many times a button was pressed.
To solve this, Node-RED provides Context: a way to store data outside the msg object so it can be retrieved later by the same node, other nodes in the same flow, or any node in the entire system.
Choosing Your Scope: Node, Flow, and Global
\nDeciding where to store your state is a critical engineering decision. Using the wrong scope can lead to \"namespace pollution,\" where variables clash, or memory leaks that crash your instance.
\nNode Context
\nNode context is private to a single node. No other node can see or modify this data. Use this for internal calculations or temporary buffers that are irrelevant to the rest of your logic.
\nFlow Context
\nFlow context is shared among all nodes on a single tab (flow). This is the \"sweet spot\" for most business logic. If you are building a specific feature—like a climate control loop—store the state here. It keeps the data accessible to all related nodes without exposing it to unrelated parts of your project.
\nGlobal Context
\nGlobal context is accessible across every single flow in your Node-RED instance. Use this sparingly for configuration settings, system-wide status flags, or shared API tokens. Overusing global state makes debugging difficult because any node in any tab could be changing the value.
\nWorked Example: Implementing a Toggle Switch
\nA common requirement is a toggle: pressing a button should turn a device ON if it is OFF, and OFF if it is ON. Because the button only sends a \"pressed\" signal, the flow must remember the current state.
\nConfiguration: Create a flow with an Inject node (the button) connected to a Function node.
\n// Run this inside a Function Node
// Retrieve the current state from flow context, defaulting to 'off' if it doesn't exist
let state = flow.get('deviceState') || 'off';
// Toggle the state
if (state === 'off') {
state = 'on';
} else {
state = 'off';
}
// Save the new state back to flow context
flow.set('deviceState', state);
// Pass the state to the next node
msg.payload = state;
return msg;\nVerification:
\n- \n
- Deploy the flow. \n
- Click the Inject node multiple times. \n
- Open the Context Data sidebar in the Node-RED editor to visually confirm the
deviceStatevalue flipping between 'on' and 'off'. \n
The Persistence Trap: Memory vs. Disk
\nBy default, Node-RED stores context in memory. This means if you restart your Raspberry Pi or the Node-RED service, all your stored states (like our deviceState) are wiped clean. For production systems, this is often unacceptable.
To make state persist across restarts, you must modify your settings.js file to enable file-based storage. Look for the contextStorage object and configure it to use the localfilesystem module. Without this configuration, your \"remembered\" state is only temporary.
Performance and Risk Trade-offs
\n| Storage Type | \nSpeed | \nPersistence | \nRisk | \n
|---|---|---|---|
| Memory | \nUltra-Fast | \nLost on Restart | \nHeap exhaustion with large objects | \n
| Filesystem | \nSlower (I/O) | \nSurvives Restart | \nDisk wear on SD cards (frequent writes) | \n
Practical Summary
\nWhen implementing state, follow the principle of least privilege: start with Node context, move to Flow context if you need to share data, and only use Global context as a last resort. If your data must survive a reboot, update your settings.js to use filesystem storage, but be mindful of how often you write to disk to avoid wearing out your hardware.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.