Choosing a Context Storage Mechanism for Node‑RED Flows

Decision and Constraints

You need a way for Node‑RED flow context to survive a process restart. The solution must add little operational overhead, work with existing flows unchanged, and allow horizontal scaling if you later run multiple Node‑RED instances.

Options Comparison

Option	Persistence	Scalability	Setup Complexity	Typical Use
Memory	None	Single process	None	Prototyping, stateless logic
File	Disk (JSON)	Single process (file locking)	Low	Small‑to‑medium deployments, easy backup
Redis	Remote DB	Horizontal (multiple nodes)	Medium	Distributed, high‑availability scenarios

Trade‑offs

• Memory – fastest access but loses all context on every restart.
• File – simple disk persistence, low latency, but only one Node‑RED process can safely write the file; heavy write load can become a bottleneck and power loss may corrupt the JSON.
• Redis – enables shared context across instances and horizontal scaling, yet adds network latency and introduces an external service that must be monitored.

Implementation Steps

1. Locate the Node‑RED settings file, usually $HOME/.node-red/settings.js or the path passed with --settings. You need read/write permission on this file.

2. Choose the storage module. For file‑based persistence add (or edit) the context section:

   context: {
     storage: {
       module: 'localfilesystem',
       // optional: change the default directory
       dir: '/data/nodered/context'
     }
   }

   For Redis storage use:

   context: {
     storage: {
       module: 'redisdb',
       // Redis connection details – adjust host, port, password if needed
       host: '127.0.0.1',
       port: 6379
     }
   }

3. Save the file and restart Node‑RED (e.g., systemctl restart nodered or node-red-stop followed by node-red-start).

4. Create a simple test flow:

   • Inject node → Function node → Debug node.
   • In the Function node set:

   let count = flow.get('counter', 0);
   count = count + 1;
   flow.set('counter', count);
   return {payload: count};

   • Deploy the flow.

Validation and Checks

1. Open the debug sidebar and click the inject node repeatedly. Observe the counter increasing (1, 2, 3 …).

2. Stop Node‑RED (node-red-stop or system stop).

3. If you used file storage, verify that a JSON file exists under the directory you set (e.g., /data/nodered/context/flow.json) and contains a counter property.

4. If you used Redis, run redis-cli GET 'node-red:flow:counter' (the exact key depends on Node‑RED's naming) to see the stored value.

5. Start Node‑RED again and inject once more. The counter should continue from the last value (e.g., 4 if you stopped at 3).

6. As an extra check, manually edit the stored value (e.g., set the file's counter to 99 or run redis-cli SET 'node-red:flow:counter' 99), restart Node‑RED, and inject; the flow should read the edited value, proving persistence.

Limitations and Practical Tips

• File storage relies on proper filesystem permissions; ensure the Node‑RED process can write to the chosen directory and consider placing it on a reliable volume with regular backups.
• Redis storage adds an external dependency; monitor Redis health (e.g., redis-cli ping) and plan for fallback or alerting if the database becomes unavailable.
• If you anticipate running multiple Node‑RED instances, file storage is not suitable; choose Redis or another shared database.
• After changing the storage module, you must restart Node‑RED for the change to take effect; reverting to a previous module follows the same edit‑and‑restart steps.