Обновление и мониторинг self-hosted n8n

Обновление и восстановление — разные процедуры

Комплект фиксирует n8n и runner на 2.41.4 — stable-релизе, проверенном 30 сентября 2026 года. Оба используют N8N_VERSION. PostgreSQL 18 и Caddy 2 подключаются изменяемыми major-тегами: pull этих образов тоже меняет ПО. Рассматривайте их обновления отдельно, не меняя все компоненты во время разбора ошибки workflow.

До обновления n8n изучите изменения целевой версии, запишите текущие образы и сделайте полный бэкап. Сохраните прежние файлы и ключ шифрования. Если workflow выполняют важные внешние действия, сначала проверьте версию на тестовых данных или изолированной восстановленной копии.

docker compose images
docker compose ps

Измените только N8N_VERSION в существующем .env на выбранную версию; не запускайте configure.py повторно. В согласованное окно обслуживания:

docker compose pull n8n runners
docker compose stop runners n8n
docker compose up -d n8n runners
docker compose ps
docker compose logs --tail=80 n8n runners

При старте возможны миграции БД. Возврат прежнего тега образа не является универсальным безопасным откатом: старое приложение может не понимать обновлённую схему. Для восстановления используйте вместе базу до обновления, постоянные файлы, конфигурацию и совместимые старые образы в новой установке.

Проверяйте действия, а не только процессы

Выполните локальный пример, повторно войдите в редактор, проверьте безвредный защищённый webhook и характерную интеграцию явным тестовым действием. Убедитесь, что runner подключился, а credentials расшифровываются. Запущенный контейнер может содержать неработающие workflow; health check не отправляет за вас сообщение в Telegram.

docker compose stats --no-stream
df -h
docker compose logs --since=15m --tail=100 n8n

Не публикуйте необработанные логи и payload выполнений. Ошибка коннектора может содержать данные клиента, даже если сам токен хранится в защищённом credential.

Оставляйте полезную историю

Комплект сохраняет ошибки, не сохраняет данные успешных запусков и не оставляет ручные выполнения в истории. Очистка настроена на семь дней или примерно 1 000 завершённых выполнений с учётом правил и задержек n8n. Waiting/running и помеченные записи не полностью охвачены обычной очисткой; это не строгая квота диска. Настройки workflow могут переопределять значения установки.

Первое время еженедельно проверяйте размер БД и число ошибок. Если нужен аудит, определите состав и место хранения отдельно: бессрочное сохранение каждого payload увеличивает объём данных и круг вопросов доступа. Успешность бэкапа и наличие копии вне VPS проверяйте независимо от здоровья приложения.

Знайте способ остановки сценария

Снимите production-workflow с публикации, если триггер создаёт неправильные запросы, затем проверьте уже ожидающие и работающие выполнения. Для общего простоя остановите контейнеры, учитывая возможные повторы со стороны отправителей. Не лечите растущую очередь одним увеличением параллелизма: сначала измерьте нагрузку.

Все руководства по n8n.

Официальные источники: Pinned n8n release, Execution retention.