HomeHome AutomationPreserving variables in NodeRED

Preserving variables in NodeRED

From time to time, my NodeRED server demands a reboot. In fact, I have a scheduled reboot each night in conjuction with linux auto-updates. When this happens, all data saved in global and flow variables will get wiped. This can lead to unexpected errors and flows not functioning correctly. Let’s talk about preserving variables in NodeRED.

Preserving variables in NodeRED (flow|global)

If you are not familiar with global|flow|context variables, take a look part 4 of my tutorial for beginners. These variables get wiped when the NodeRED stops. Not having these defined, can lead to unexpected errors in NodeRED flows. Before I show you how to save these, let’s mention error proofing.


When the variable is wiped, the content of the “container” will be replaced with the “undefined” message. This will replace all the variable types (bool, string, int) and it can cause an annoyance in the string at best, and “NaN” in maths calculations or JS errors in the worst case scenarios.

There are a couple of things we can do to protect our flows. A simple IF statement can set default values before our function or flow returns an unwanted error:

if(x === undefined){
    x = "default value";

Preserving variables in NodeRED

Loading default values is great, but it won’t save us from the data loss. To protect the data, we have to save it somewhere for the duration of the NodeRED restart. Before v19 of the NodeRED you would simply save these values to a file and load it back as variables once the server is online again. (a big thank you to u/frygod)

This is the “old way” of doing things. It’s probably simpler and quicker if you only going to do this a couple of times. If your NodeRED flows are ever expanding, you may consider moving to the new solution.

The old way

Save to file

An inject node has an interval built in. This can be used to save our variables every X sec/min/hours. The flow is very simple, but before you save the data to a file, consider writing it as JSON. Trust me, you will thank me later. It may not be a problem if you want to store single information, but that’s rarely the case.

var x = flow.get("ImportantData1");
var y = flow.get("ImportantData2");
var z = flow.get("ImportantData3");

msg.payload = {
    "data1": x,
    "data2": y,
    "data3": z
return msg;

This JSON is then written to file. Avoid storing sensitive credentials this way, as the file can be opened by anyone who has the access to that machine. There is no encryption. Setting a strong passwords for SSH access is recommended.

Read from file

To restore the data from file, I’m going through the reversed process. The file is read and converted into a JSON, then appropriate entries are saved as variables. To trigger this after NodeRED reboot, you will need an inject node configured to Started! I would recommend you to add a couple of seconds of delay as well.


return msg;

Preserving variables in NodeRED v19

The new version of the NodeRED introduces a new way of storing the variables. By default, the variables are stored in the memory, and get wiped when the server is restarted. Now we can specify where we would like to store the variables.

  • keep variable in the memory
  • store it in a context store

What is the context store?

We can enable a new way of storing the data in variables. NodeRED v19 can save the data stored in the variables to a local file structure. These are saved automatically every 30 sec. It’s not enabled by default and we have to configure settings.js file to enable this.

contextStorage: { 
    storeName : { module: "storeModule" } 

This is the entry in the settings.js that we have to modify.

  • storeName – a custom name for your “bank” of information (“default” is, well the defaul “bank”)
  • storeModule – type of storage: (memory|localfilesystem)

Let me show you on the example how to configure the file

Default – store everything in memory
contextStorage: { 
 default: { module: "memory" } 

In this configuration, the variables are not saved to file but kept in the memory only. This is the default NodeRED behaviour.

Store everything- store everything in a local file
contextStorage: { 
 default: { module: "localfilesystem" } 

In this configuration, every variable is saved to a local file structure.

Mixed mode – using context storage
contextStorage: { 
 default: { module: "memory" }, 
 bank1: { module: "localfilesystem" } 

In this mode, you can choose where your variable is stored. To specify the context storage used, we have to define it in the variable command:

flow.set("DayOfTheWeek", "Monday", "bank1") 
\\content of the variable "DayOfTheWeek" is stored in the context store called "bank1"
flow.set("DayOfTheWeek", "Monday", "default") 
flow.set("DayOfTheWeek", "Monday") 
\\content of the variable "DayOfTheWeek" is stored in the memory

You can create multiple context stores and save the variables to different “banks”.  These are organised in the ~/.node-red/context folder. The file structure will correspond with your flow structure with exeption of global variables, which are all stored in the same folder (which makes sense as these are available across the flows).


Preserving variables in NodeRED can save you from manually opening the dashboard and setting everything correctly. The data will survive the server restart. You can also store the copy of that file to create an additional backup and synchronise it using a method I created earlier. Got questions? Here is a Reddit post for you!

Project Download

Download project files here. Bear in mind that Patreon supporters have early access to project files and videos.


Nothing says "Thank you" better than keeping my coffee jar topped up!


Support me on Patreon and get an early access to tutorial files and videos.


Bitcoin (BTC)

Use this QR to keep me caffeinated with BTC: 1FwFqqh71mUTENcRe9q4s9AWFgoc8BA9ZU

Smart Ideas with

Automate your space in with these ecosystems and integrate it with other automation services


Learn NodeRED

NodeRED for beginners: 1. Why do you need a NodeRED server?

To server or not to server? That's a very silly question!

Best Automation Projects

Sonoff R3 DIY mode & why it sucks

Long awaited Sonoff R3 DIY mode is even worse than I expected.

IKEA TRADFRI Wireless dimmer in NodeRED

Thanks to NodeRED you can use IKEA TRADFRI Wireless Dimmer to interact with everything

Things they don’t tell you about IKEA Trådfri

There are things you should know about IKEA Tradfri before you make your purchase

Flashing Tasmota on Sonoff ZigBee Bridge

How to flash Tasmota on Sonoff ZigBee Bridge to enable it for NodeRED and Home Assistant

Flashing ESP with Tasmotizer is a dream come true

How to flash Tasmota on ESP devices with new Tasmotizer tool

Smart Home

No more hubs: Aqara G2H

Aqara G2H brings the power of ZigBee sensors to an IP camera.

Two cool features of Avatar Smart Bulbs

Avatar Smart Bulbs come with 2 cool features I wish more smart bulb manufacturers would include in their products.

Shelly 2.5 vs Sonoff DualR3

It's time to pitch similar devices against each other and compare their functions: Shelly 2.5 vs Sonoff DualR3

How to flash Tasmota on Sonoff DualR3

Make the device yours by flashing Tasmota on Sonoff DualR3. Now with channel control and power consumption

Shelly Duo – going beyond twice

Their #ShellyDuo is a WiFi-enabled lightbulb with colour temperature. Plus it comes with 2 features don't often offered by other smart lights.