Node-RED

Обзор

Node-RED позволяет собирать автоматизацию как наглядный поток узлов. Входящий webhook, таймер, MQTT-сообщение, HTTP-запрос, обращение к базе или небольшой JavaScript-код передают данные следующему шагу. Среда особенно полезна для устройств и умного дома, но подходит и как компактная собственная платформа для API-связок и заданий по расписанию.

Рецепт запускает один официальный контейнер без отдельной базы данных. В постоянном Docker-томе хранятся потоки, установленные узлы, настройки и зашифрованные учётные данные. Редактор требует локально заданный пароль и по умолчанию доступен только через localhost; перед публичным доступом используйте один из примеров HTTPS reverse proxy.

Node-RED лучше n8n, когда нужен прямой контроль над событийными и IoT-потоками, собственный JavaScript и небольшой runtime. У n8n больше готовых SaaS-коннекторов и более подробная история запусков. В обоих случаях непроверенный community-узел не становится безопасным — изучайте пакеты до установки.

Оценка безопасности

Рецепт не использует privileged mode, host network или Docker socket и задаёт no-new-privileges. Редактор по умолчанию привязан к 127.0.0.1, поэтому не доступен напрямую из сети.

Но сам редактор — высокопривилегированная панель управления. Любой, у кого есть учётные данные редактора, может развернуть произвольный JavaScript в узлах Function и установить сторонние palette-пакеты; и то и другое работает с правами контейнера. Давайте доступ к редактору только тем, кому разрешён запуск кода на сервере, и проверяйте community-узлы перед установкой.

Потоки могут содержать API-токены и пароли. Они шифруются NODE_RED_CREDENTIAL_SECRET, но получивший одновременно этот секрет и постоянный том или резервную копию сможет их расшифровать. Считайте .env и резервные копии секретами уровня пароля. При публикации редактора или webhook размещайте их за HTTPS, используйте отдельный стойкий пароль и не открывайте порт 1880 напрямую.

Пошаговая инструкция

1. Проверьте сервер

Нужны Ubuntu 22.04+ или Debian 12+, Docker Engine и Docker Compose v2.24+. Минимум для Node-RED — 1 CPU, 256 МБ RAM и 2 ГБ диска; для потоков с большим числом узлов или контекстом оставьте 512 МБ. Отдельная БД не нужна: потоки, установленные узлы и учётные данные лежат в Docker-томе.

docker --version
docker compose version

2. Подготовьте рецепт

Поместите все файлы рецепта, включая config/settings.js, в закрытый каталог:

mkdir -p ~/services/node-red
cd ~/services/node-red
cp .env.example .env
chmod 600 .env

Создайте bcrypt-хеш пароля редактора и секрет шифрования учётных данных. В .env записывайте хеш, а не открытый пароль; пароль и секрет храните в менеджере паролей. Не меняйте NODE_RED_CREDENTIAL_SECRET после создания credentials: старые значения перестанут расшифровываться.

docker run --rm -it nodered/node-red:5.0.8-24 node-red admin hash-pw
openssl rand -hex 32

Первый вывод запишите в NODE_RED_ADMIN_PASSWORD_HASH, задайте нестандартный NODE_RED_ADMIN_USERNAME, второй — в NODE_RED_CREDENTIAL_SECRET. NODE_RED_SETTINGS_FILE указывает на приложенный файл JavaScript, включающий вход по паролю; контейнер должен иметь возможность его читать.

3. Запустите Node-RED

docker compose pull
docker compose up -d
docker compose ps
curl -I http://127.0.0.1:1880/

Последняя команда возвращает HTTP-ответ, но редактор должен запросить заданные выше credentials. Для первого входа используйте SSH-туннель:

ssh -L 1880:127.0.0.1:1880 user@server.example

Откройте http://localhost:1880, войдите, перетащите на новый поток узлы Inject и Debug, соедините их и нажмите Deploy. Так вы проверите, что редактор сохраняет и исполняет поток. Не помещайте настоящие токены в незашифрованный export или скриншоты.

Локальная сеть

По возможности сохраните localhost bind и SSH-туннель. Для доверенной LAN замените 127.0.0.1 в пробросе порта на LAN-IP сервера, например 192.168.1.10, и закройте порт 1880 со всех прочих сетей. Не открывайте порт на все интерфейсы: пароль не заменяет TLS и сетевой контроль доступа.

Домен и HTTPS

В proxy/ есть примеры Caddy, Nginx и Traefik для flows.example.com. Замените имя своим. Caddy получает TLS автоматически, Nginx ожидает сертификаты Certbot, Traefik использует resolver letsencrypt. При адаптации сохраняйте заголовки Host, X-Forwarded-For и X-Forwarded-Proto. До публикации webhook войдите через HTTPS-адрес.

Резервная копия

chmod +x backup.sh restore.sh
./backup.sh

Скрипт ненадолго останавливает Node-RED и архивирует весь том данных: потоки, установленные модули палитры и зашифрованные credentials. Храните копию вне сервера в зашифрованном виде; секрет из .env и config/settings.js держите вместе с ней, но защищайте отдельно.

Восстановление

Восстановление необратимо заменяет текущий том. Сначала создаётся safety backup, затем загружается выбранный архив:

./restore.sh ./backups/node-red-YYYYMMDDTHHMMSSZ.tar.gz
docker compose up -d

Откройте редактор и задеплойте безопасный сохранённый поток. Используйте NODE_RED_CREDENTIAL_SECRET на момент создания архива: без него credentials не будут работать.

Обновление

Сначала сделайте backup, прочитайте release notes, поменяйте NODE_RED_VERSION в .env и пересоздайте сервис:

docker compose pull
docker compose up -d
docker compose logs --tail=100 node-red

Войдите и задеплойте небольшой существующий flow. До смены варианта Node.js (-24) или сторонних узлов изучите примечания к релизу.

Откат

Верните прежний image tag в .env и пересоздайте контейнер. Если старая версия не читает данные после обновления, восстановите backup, созданный до него:

docker compose up -d
./restore.sh ./backups/node-red-PRE-UPDATE.tar.gz

Полное удаление

docker compose down останавливает сервис, но сохраняет потоки. После проверки внешней копии удалить всё можно так:

docker compose down
docker volume rm node-red-data
rm -rf ~/services/node-red

Источники: официальный Docker guide, защита редактора и projects с файлами потоков.

Сообщить о проблеме с рецептом

Рассказать, как прошло на вашем сервере

Откроется предзаполненный issue на GitHub. Нужен аккаунт GitHub; после отправки сообщение будет публичным.

Диагностика

Контейнер завершается или остаётся unhealthy

Проверьте настройки и обязательные переменные:

docker compose config
docker compose ps --all
docker compose logs --tail=200 node-red

NODE_RED_ADMIN_PASSWORD_HASH должен быть bcrypt-хешем, а не открытым паролем. Создайте его через node-red admin hash-pw и пересоздайте контейнер.

Редактор отвечает 401 или вход не работает

Убедитесь, что в .env есть текущий пользователь и хеш, затем пересоздайте сервис:

grep '^NODE_RED_ADMIN_USERNAME=' .env
grep '^NODE_RED_ADMIN_PASSWORD_HASH=' .env
docker compose up -d --force-recreate

Не удаляйте adminAuth из config/settings.js, чтобы вернуть доступ к публичному серверу. Создайте новый парольный хеш. Секрет credentials не влияет на вход, но его смена делает сохранённые credentials нечитаемыми.

Порт 1880 уже занят

Измените NODE_RED_PORT в .env, пересоздайте сервис и обновите upstream в reverse proxy. Сохраните localhost bind:

docker compose up -d
docker compose port node-red 1880

Поток не deploy или не найден узел

Откройте debug sidebar и изучите runtime-логи:

docker compose logs --tail=200 node-red

Устанавливайте через palette manager только проверенные узлы и экспортируйте поток до изменений. Community-узел — исполняемый код в контейнере; удаление пакета может сделать зависимые потоки невалидными.

Credentials не расшифровываются после restore

Для flows_cred.json требуется тот же NODE_RED_CREDENTIAL_SECRET, который использовался при шифровании. Верните сохранённое значение в .env, пересоздайте контейнер и повторите попытку. Если старый секрет утрачен, сначала экспортируйте потоки без секретов, удалите повреждённые credentials и введите их заново: обхода шифрования нет.