Node-RED Context Storage: Choosing Between Memory and Localfilesystem for Restart Survival

Node-RED flows often need to remember values between restarts—a device's last known status, a counter, or a cached API response. In Node-RED, these values are called context: variables scoped to a node, a flow tab, or globally across the runtime. By default, context is stored in memory, which means that state disappears when the process stops. If you run a single instance and need that state to survive restarts, the localfilesystem context store is a supported option. But it is not a database, and choosing it requires accepting single-writer semantics and flush latency.

The Decision: Constraints First

Before changing configuration, confirm your constraints:

• Single instance: You run one Node-RED process against one context directory.
• Restart survival: Flow and global context values must persist across process restarts.
• State size: Values are small and written at low-to-moderate frequency.

If any of these are false—especially if you run multiple instances for high availability—keep the default memory store and move shared state to an external system such as Redis, MongoDB, or a relational database.

Comparing Supported Options

Option	Survives Restart	Multi-Instance Safe	Write Profile	Operational Cost
Memory (default)	No	Yes	Fastest, no disk I/O	None
Localfilesystem	Yes	No	Disk I/O with flush lag	Disk monitoring and cleanup
External store	Yes	Yes	Network dependent	Added dependency and ops

Configuring the Localfilesystem Store

Context storage is configured in settings.js, typically located in your Node-RED user directory (for example, ~/.node-red/settings.js). You need write access to that file and to the target storage directory.

Add or modify the contextStorage property. The exact option names and defaults vary by Node-RED version, so verify the keys against your installed version before production use.

contextStorage: {
    default: {
        module: "localfilesystem",
        config: {
            base: "/var/lib/node-red/context",
            flushInterval: "30"
        }
    }
}

In this example:

• base is the directory where context files are written. Replace the placeholder with a path appropriate for your deployment.
• flushInterval controls how often buffered writes are flushed to disk. A shorter interval reduces the window of potential data loss on crash but increases disk I/O. Confirm the accepted units and default for your version.

After editing settings.js, restart Node-RED for the change to take effect.

Using Context in Flows

Use global.set() and global.get() for values that must be shared across nodes and survive restarts. Use flow.set() and flow.get() for values scoped to a single flow tab. Keep node-local context for short-lived, per-node state that does not need to persist.

Example function node to set a value:

// Run in a Function node
global.set("lastDeviceStatus", msg.payload);
return msg;

Example function node to read it back:

// Run in a separate Function node
const status = global.get("lastDeviceStatus");
msg.payload = status === undefined ? "missing" : status;
return msg;

Validating Persistence

Validate in a disposable instance before relying on the store in production.

1. Deploy a flow that sets a known key, such as global.set("validationKey", "survives-restart").
2. Stop Node-RED. If running as a service, run sudo systemctl stop nodered (or the equivalent for your init system). If running in a terminal, press Ctrl+C.
3. Start Node-RED again.
4. Inject a message into a path that reads global.get("validationKey") and outputs the result to a Debug node.
5. Confirm the value survives-restart appears.
6. Inspect the configured base directory to confirm context files were created and updated.

Expected result: the key returns the stored value after restart, and the directory contains context files. If the key returns undefined, check the runtime log for context-store errors and verify the settings.js path and module name.

Limitations and Cautions

Localfilesystem persistence is convenient but not transactional. A crash immediately after a write may lose recent values because of flush latency. Avoid high-frequency counters, large payloads, or queue semantics in context; use memory for hot state and an external store for authoritative data.

Do not use localfilesystem context on multiple active Node-RED instances. Concurrent writers can overwrite each other, causing lost updates. If you need high availability, use an external context store module designed for multi-instance access.

Context values may contain secrets. Restrict directory permissions on the base path and avoid logging full context objects.

Old values are not automatically expired. Monitor disk growth under the context directory and implement retention or cleanup if your writes accumulate over time.

Finally, redeploying or changing node IDs can change context scope availability. Verify that global and flow scopes still resolve as expected after refactoring flows.