Node-RED Docker

Starting from Node-RED version 1.2.0, the VOLUME [/data] instruction has been removed from the Dockerfile.

Previous Behavior (v1.1.3 and earlier): If you did not explicitly specify a volume for /data, Docker would automatically create an anonymous volume and copy the contents of the /data folder from the base image into it. These anonymous volumes had long, random names and required manual cleanup to avoid cluttering the host system.

New Behavior (v1.2.0 and later): Docker no longer automatically creates an anonymous volume for /data. This change prevents unexpected volume creation and simplifies management, as users are encouraged to explicitly manage persistence.

How you handle the change in volume behavior depends on your current setup:

• Scenario A: You explicitly specify a volume for /data (e.g., via a bind mount or named volume).

  • Impact: None. Your configuration remains exactly the same, and your data will persist as expected across upgrades.

• Scenario B: You do NOT explicitly specify a volume for /data.

  • Impact: Data saved in /data is persisted in the container's writable layer and survives container stops/restarts. However, if you remove the container, the data is lost unless you explicitly managed a volume.
  • Note for docker-compose users: If you rely on the old automatic anonymous volumes, you must remove the container before upgrading to a new image to ensure the new image's /data content is used instead of the old volume.

To allow Node-RED to communicate with other containers (like an MQTT broker) using container names as hostnames, use a user-defined Docker bridge network.

1. Create a network: docker network create <network_name>
2. Run the service (e.g., Mosquitto) on that network with a --name.
3. Run Node-RED on the same network using --network <network_name>.

In Node-RED, you can then address the other service using its --name (e.g., mybroker) instead of an IP address.

# 1. Create network
docker network create iot

# 2. Run broker on network
docker run -itd --network iot --name mybroker eclipse-mosquitto mosquitto -c /mosquitto-no-auth.conf

# 3. Run Node-RED on same network
docker run -itd -p 1880:1880 --network iot --name mynodered nodered/node-red

There are three ways to add nodes to your Node-RED instance:

1. Node-RED Admin Tool: Install node-red-admin on your host and use it to target the running container (assumes Node-RED is at localhost:1880).
2. npx via Docker Exec: Run admin commands directly through the container without installing tools on the host.
3. Container Shell: Access the container's bash shell to run npm install manually in the /data directory.

# Using node-red-admin on host
npm install -g node-red-admin
node-red-admin install node-red-node-openwhisk

# Using npx via docker exec
docker exec -it mynodered npx node-red admin hash-pw

# Using container shell
docker exec -it mynodered /bin/bash
# Inside shell:
# cd /data && npm install node-red-node-smooth && exit

Native GPIO support for Raspberry Pi has been dropped in favor of node-red-node-pi-gpiod. The new method allows a single Node-RED container to interact with GPIO on multiple Raspberry Pis via a daemon, avoiding the need for privileged=true or direct access to /dev/mem on the host.

Migration Steps:

1. Install node-red-node-pi-gpiod via the Node-RED palette.
2. Install and run the PiGPIOd daemon on the host Raspberry Pi.
3. Replace all existing native GPIO nodes in your flows with pi gpiod nodes.
4. Configure the pi gpiod nodes to connect to the PiGPIOd daemon.

Finding the Daemon IP: If the host machine is the Docker gateway, the IP is often 172.17.0.1:8888. You can verify the gateway IP by running:

docker exec -it mynodered ip route show default | awk '/default/ {print $3}'

To modify the default timezone of the Node-RED container, use the TZ environment variable with a valid timezone string (e.g., America/New_York).

Using Docker CLI: Use the -e flag.

Using Docker Compose: Define it under the environment key.

# Docker CLI
docker run -it -p 1880:1880 -v node_red_data:/data --name mynodered -e TZ=America/New_York nodered/node-red

# Docker Compose
services:
  node-red:
    environment:
      - TZ=America/New_York

If you are using docker-compose and have not explicitly defined a volume for the /data folder, upgrading to a newer Node-RED image (one without the VOLUME [/data] instruction) may result in the old anonymous volume being preserved instead of using the new flows provided in the updated image.

This happens because docker-compose up preserves existing mounted volumes when recreating containers. To ensure you are using the flows included in the new image, follow these steps:

1. Stop and remove the existing container for the service.
2. Run docker-compose up to rebuild the container. Since no volume is being automatically created by the image anymore, the container will now use the /data folder from the new image without mounting the old anonymous volume.

When user data is persisted externally (via bind mount or named volume), updating the Node-RED instance is a simple three-step process: pull the new image, stop the old container, and start a new one.

docker pull nodered/node-red
docker stop mynodered
docker start mynodered

To allow Node-RED to access hardware devices on the host (such as a serial port like /dev/ttyACM0), use the --device flag in your docker run command.

docker run -it -p 1880:1880 -v node_red_data:/data --name mynodered --device=/dev/ttyACM0 nodered/node-red

Docker named volumes can be used to store persistent user data outside the container lifecycle. This allows you to destroy and recreate containers without losing configuration.

1. Create a volume: docker volume create --name <volume_name>
2. Run the container using the volume: docker run -v <volume_name>:/data ...

$ docker volume create --name node_red_data_vol
$ docker volume ls
$ docker run -it -p 1880:1880 -v node_red_data_vol:/data --name mynodered nodered/node-red