Home Home Automation Preserving 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 in style with crypto-currency

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

ESP8266 WIFI lights under $5

Your Sonoff device can't do this!

Free wireless doorbell (Amazon Dash button hack)

The most terrifying situation I can imagine* is missing a parcel

New Amazon Dash Buttons

You can teach new buttons old tricks!

ESP8266 ceiling light – demo

Testing the ESP8266 as a WIFI light controller

Try Tasker and Raspberry Pi for your home automation needs!

Raspberry Pi can help you with your Tasker profiles

Smart Home

Army of robots: SwitchBot Curtain

An army of SwitchBot Curtains - adorable CurtainBots to open and close practically any curtains!

Zemismart Roller Shade Driver

Frustrated with UK's roller measurements I reached out for Zemismart Roller Shade Driver

Most affordable smart lightbulbs: Sonoff B02 & B05

ITEAD just dropped a range of very affordable smart Sonoff lightbulbs

Creepy Alexa for Halloween

Turning Amazon Echo into a Creepy Alexa monster for Halloween

How to make Sonoff ZB Mini and ZigBee2MQTT work together

It's time to make Sonoff ZB Mini and ZigBee2MQTT work together!