Persisting State in Node-RED: Choosing Between Memory and Filesystem Context

The Problem: Volatile State Loss

By default, Node-RED stores context variables—data used to track state between messages or across different nodes—in volatile RAM. When you deploy a flow or restart the Node-RED process, this data is wiped. For applications like industrial controllers, home automation, or state machines, losing a "current status" or "last known value" can lead to incorrect system behavior or missed triggers upon reboot.

The solution is to move from the default memory store to a localfilesystem store, allowing Node-RED to serialize context data to disk.

Comparing Context Storage Options

Node-RED allows you to define storage mechanisms in the settings.js file. You can apply these settings globally or specifically to different scopes (node, flow, or global).

Feature	Memory Store (Default)	Local Filesystem Store
Persistence	Lost on restart/deploy	Persists across restarts/deploys
Latency	Extremely Low	Higher (Disk I/O overhead)
Throughput	High frequency updates	Limited by disk write speed
Risk	Data loss	Slow deployments with large datasets

Trade‑offs and Engineering Constraints

Choosing filesystem storage is not a universal upgrade; it introduces specific architectural trade‑offs:

• Deployment Overhead: Node-RED must serialize and deserialize the context store during flow deployments. If you store massive JSON objects or arrays in the filesystem context, your deployment time will increase significantly.
• I/O Bottlenecks: Frequent writes (e.g., updating a timestamp every 100 ms) to the filesystem can cause disk wear on SD cards (common in Raspberry Pi setups) and introduce latency into the event loop.
• Data Integrity: While Node-RED is single-threaded, asynchronous operations can still lead to race conditions if multiple flows attempt to read‑modify‑write the same global key simultaneously.

Decision Matrix

• Use Memory if: You are handling transient data, high-frequency telemetry, or data that can be easily re‑fetched from a source on startup.
• Use Filesystem if: You are tracking a state machine (e.g., ALARM_ACTIVE), storing user preferences, or maintaining a counter that must survive a power cycle.

Implementation: Enabling Filesystem Persistence

To enable persistence, you must modify the settings.js file, typically located in the .node-red directory of your user home folder.

1. Configuration

Locate the contextStorage object in settings.js. If it is commented out, uncomment it and configure the default store as follows:

// settings.js
contextStorage: {
    default: {
        module: "localfilesystem",
        filename: ".node-red/context-store"
    }
}

Permissions: Ensure the user running the Node-RED process has read/write permissions for the .node-red directory.

Risk: Incorrectly specifying the filename path can prevent Node-RED from starting if the directory does not exist or is read-only.

2. Validation Flow

To verify that persistence is working, create a simple flow with the following components:

1. An Inject node connected to a Function node.
2. In the Function node, set a global variable: global.set("persistenceTest", "Success"); return msg;
3. A Debug node to display the value: global.get("persistenceTest").

3. Verification Steps

1. Deploy the flow and trigger the Inject node.
2. Verify the Debug node shows "Success".
3. Restart the Node-RED process (e.g., sudo systemctl restart nodered).
4. Trigger the Debug node again without triggering the Inject node. If it still displays "Success", persistence is active.
5. Check the .node-red folder for a directory or file named context-store to confirm physical disk usage.

Rollback and Cleanup

If you experience performance degradation or slow deployments, revert the settings.js change by changing the module back to "memory" or commenting out the contextStorage block. To completely remove persisted data, delete the context-store directory/file from the .node-red folder before restarting the service.