Как я подружился с n8n и автоматизировал половину сервера

Как я дошёл до n8n

Всё началось с того, что я устал каждый день проверять почту и телеграм, не упал ли сервер. У меня крутится штук пять сервисов на домашнем сервере: тут и сайт, и базы, и тестовые среды. Если что-то отваливается — я узнаю об этом только когда захожу на сайт и вижу ошибку. А это может быть и через час, и через три.

Сначала я хотел написать простой bash-скрипт, который проверяет доступность портов и шлёт уведомления. Написал. Работало. Но как только я захотел добавить проверку свободного места на диске, потом температуру процессора, потом время ответа сайта — скрипт разросся до нечитаемых размеров. Я понял: нужна автоматизация, но не на коленке.

Знакомый посоветовал n8n. Я сначала отмахнулся — «очередной low-code конструктор». Но глянул: n8n — это опенсорсная платформа для автоматизации рабочих процессов. Тяжёлая артиллерия в мире «если это, то то». Бесплатно, self-hosted, с кучей интеграций из коробки.

Решил попробовать. И залип на неделю.

Где я его развернул

У меня на Proxmox крутится Ubuntu Server 24.04. Я поставил Docker, на него n8n в контейнере. Официальный образ — n8nio/n8n. Запустил одной командой:

docker run -d --name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n

Всё. Через минуту n8n уже был доступен по адресу http://192.168.0.130:5678. Правда, я сразу повесил за nginx-прокси с HTTPS, потому что передавать API-ключи по открытому HTTP — идея так себе.

Первое, что я сделал — зашёл в веб-интерфейс. Выглядит приятно, узлы перетаскиваются, соединения рисуются стрелками. Всё как в нормальных конструкторах автоматизации. Только не плиточный, а нодовый — каждый шаг это отдельный блок на графе.

Мой первый workflow: мониторинг сервера

Я начал с простого: каждые 5 минут стучаться на localhost:80 и проверять, отвечает ли nginx. Если не отвечает — шлёт сообщение в Telegram.

Workflow выглядит так: Trigger (Schedule) → HTTP Request → IF (response code = 200?) → Telegram. Всё. Собрал за 10 минут, хотя никогда раньше не пользовался n8n.

Потом я добавил проверку свободного места на диске через SSH-команду. n8n умеет подключаться по SSH к удалённому серверу, выполнять команду и возвращать результат. Я прописал команду df -h / | tail -1, распарсил вывод, и если места осталось меньше 20% — летит уведомление.

Дальше — больше. Я добавил температуру процессора через sensors, нагрузку на RAM, количество ошибок в логах nginx за последний час. Теперь у меня в телеграм приходит ежедневный дайджест: «Сервер в порядке, CPU 12%, RAM 45%, диск 34%, всё ок». А если что-то не ок — сообщение приходит сразу.

Честно говоря, первый раз, когда я получил уведомление в 3 часа ночи, что nginx упал — я был скорее рад, чем расстроен. Система работает!

С чем я намудрил

Не всё было гладко. Вот мои грабли:

Таймзоны

n8n в Docker-контейнере живёт в UTC, а я в Москве. Когда я настроил ежедневный отчёт на 9 утра, он приходил в 6 утра. Пришлось добавить в docker-compose переменную TZ=Europe/Moscow. Мелочь, а полчаса гугления.

SSH Credentials

n8n хранит credentials в зашифрованном виде, но ключ шифрования нужно передавать через переменную окружения N8N_ENCRYPTION_KEY. Если не задать — при перезапуске контейнера все пароли сбросятся. Я не задал, и после обновления образа пришлось всё переподключать. Больше не повторю эту ошибку.

HTTP Requests к внутренним сервисам

Когда n8n стучится к сервису на локалхосте, он стучится к себе внутри контейнера. А мне нужно было достучаться до хостового nginx. Пришлось использовать IP Docker-хоста и убедиться, что порт не заблокирован фаерволом. Вместо localhost я написал host.docker.internal — не сработало на Linux. В итоге использовал IP хоста из сети Docker.

Что я автоматизировал ещё

Как только я распробовал n8n, остановиться было сложно. Теперь у меня крутится:

Резервное копирование БД. Каждую ночь n8n выполняет дамп MySQL через SSH, архивирует и отправляет на отдельный бекап-сервер. Раньше я делал это crontab-ом, но с n8n удобнее визуально видеть, что бекап прошёл успешно.

Публикация в соцсети. Я пишу статью в WordPress, ловлю webhook и автоматически пощу анонс в Telegram-канал. Без n8n я бы просто забывал это делать.

Мониторинг SSL-сертификатов. Раз в день проверяю, сколько дней осталось до истечения сертификата Let’s Encrypt. Если меньше 7 — шлю панику в Telegram. Однажды сертификат протух, и сайт лёг — больше такого не хочу.

Уборка логов. Раз в неделю чищу логи nginx и Docker старше 30 дней. Скрипт тривиальный, но в n8n он хотя бы виден и не теряется.

Что мне не нравится

n8n не без греха. Он жрёт память — контейнер с n8n на нагрузке ест около 300-400 MB RAM, хотя я дал ему 512. Для домашнего сервера терпимо, но если бы я крутил его на Raspberry Pi — пришлось бы экономить.

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

Но главное — документация. Она есть, но часто описывает идеальный сценарий, а на практике что-то идёт не так. Например, SSH Node: в доке написано «просто введи хост», а в реальности мне пришлось разбираться с ключами, known_hosts и правами на приватный ключ. Минут 40 потерял.

Итог

n8n — это штука, которую я советую попробовать всем, у кого есть домашний сервер и хотя бы пара рутинных задач. Он не заменяет bash-скрипты для всего, но для визуального контроля над автоматизацией — лучшее, что я пробовал.

Главное, что я вынес: начинайте с малого. Не пытайтесь построить идеальный workflow с первого раза. Сделайте один простой сценарий — пусть пингует сервер и шлёт уведомления. Когда увидите, что это реально работает, добавите остальное само собой.

Расширю рассказ о настройке n8n на VPS дополнительными деталями. Как я дошёл до n8n. Всё началось с того, что я устал каждый день проверять почту и телеграм, не упал ли сервер. У меня крутится штук пять сервисов на домашнем сервере: тут и сайт, и базы, и тестовые среды. Если что-то отваливается — я узнаю об этом только когда захожу на сайт и вижу ошибку. А это может быть и через час, и через три. Сначала я хотел написать простой bash-скрипт, который проверяет доступность портов и шлёт уведомления. Написал. Работало. Но как только я захотел добавить проверку свободного места на диске, потом температуру процессора, потом время ответа сайта — скрипт разросся до нечитаемых размеров. Я понял: нужна автоматизация, но не на коленке. Ручная проверка сервера — это потеря времени и нервы: сбой может жить часами, пока вы не заметите. Скрипты растут, обрастают условиями и перестают быть читаемыми. Мне нужен был визуальный инструмент, где каждый шаг автоматизации виден и понятен. Знакомый посоветовал n8n.

Я сначала отмахнулся — «очередной low-code конструктор». Но глянул: n8n — это опенсорсная платформа для автоматизации рабочих процессов. Тяжёлая артиллерия в мире «если это, то то». Бесплатно, self-hosted, с кучей интеграций из коробки. Решил попробовать. И залип на неделю. n8n — это платформа, где вы строите workflow из узлов: триггеры, действия, условия. Каждый узел — это отдельный шаг, соединённый стрелками с другими. Визуальная автоматизация даёт контроль: вы видите весь процесс, данные на каждом шаге, ошибки. Начал с малого, а через неделю автоматизировал половину рутины. Проект развивается быстро, есть огромное комьюнити и тысячи готовых шаблонов.

Где я его развернул. У меня на Proxmox крутится Ubuntu Server 24.04. Я поставил Docker, на него n8n в контейнере. Официальный образ — n8nio/n8n. Запустил одной командой: docker run -d —name n8n -p 5678:5678 -v n8n_data:/home/node/.n8n n8nio/n8n. Всё. Через минуту n8n уже был доступен по адресу http://192.168.0.130:5678. Правда, я сразу повесил за nginx-прокси с HTTPS, потому что передавать API-ключи по открытому HTTP — идея так себе. Развёртывание в Docker — это десять минут и одна команда. Образ официальный, том для данных отдельный. nginx-прокси с HTTPS — это безопасность: все ключи и логины передаются в зашифрованном виде. Профиль n8n, настройки и workflow живут в томах Docker. Первое, что я сделал — зашёл в веб-интерфейс.

Выглядит приятно, узлы перетаскиваются, соединения рисуются стрелками. Всё как в нормальных конструкторах автоматизации. Только не плиточный, а нодовый — каждый шаг это отдельный блок на графе. Веб-интерфейс n8n — это граф: слева панель узлов, в центре канвас, справа настройки выбранного узла. Триггеры — это входы, действия — узлы обработки. Собрать workflow — просто перетащить узлы и соединить стрелками. Огромная библиотека интеграций: Telegram, Gmail, MySQL, WordPress, Slack, HTTP-запросы, SSH и сотни других. Даже если интеграции нет — есть Webhook и HTTP Request. Мой первый workflow: мониторинг сервера.

Я начал с простого: каждые 5 минут стучаться на localhost:80 и проверять, отвечает ли nginx. Если не отвечает — шлёт сообщение в Telegram. Workflow выглядит так: Trigger (Schedule) → HTTP Request → IF (response code = 200?) → Telegram. Всё. Собрал за 10 минут, хотя никогда раньше не пользовался n8n. Первый workflow — это учебник: как работает триггер, как проверяется ответ, как работает ветвление. Schedule-триггер запускает workflow по расписанию. HTTP Request стучится на URL и возвращает статус. Узел IF проверяет условие и направляет поток в нужную ветку. Telegram шлёт уведомление. Десять минут — и у вас есть свой мониторинг.

Потом я добавил проверку свободного места на диске через SSH-команду. n8n умеет подключаться по SSH к удалённому серверу, выполнять команду и возвращать результат. Я прописал команду df -h / | tail -1, распарсил вывод, и если места осталось меньше 20% — летит уведомление. SSH-узел — это окно в любой сервер: выполняете любую команду и получаете результат. Я добавил проверку диска, и это открыло глаза: можно мониторить всё, что умеет командная строка. Парсинг вывода — через функции n8n или простой поиск. Условие «меньше 20%» — это одна строчка. Автоматизация, которая раньше требовала скрипта, теперь — визуальная цепочка. Дальше — больше. Я добавил температуру процессора через sensors, нагрузку на RAM, количество ошибок в логах nginx за последний час. Теперь у меня в телеграм приходит ежедневный дайджест: «Сервер в порядке, CPU 12%, RAM 45%, диск 34%, всё ок». А если что-то не ок — сообщение приходит сразу. Честно говоря, первый раз, когда я получил уведомление в 3 часа ночи, что nginx упал — я был скорее рад, чем расстроен. Система работает! Мониторинг — это только начало: любой SSH-инструмент можно превратить в узел автоматизации. Дайджест утром, алерты при сбоях — вы всегда в курсе.

С чем я намудрил. Не всё было гладко. Вот мои грабли: Таймзоны. n8n в Docker-контейнере живёт в UTC, а я в Москве. Когда я настроил ежедневный отчёт на 9 утра, он приходил в 6 утра. Пришлось добавить в docker-compose переменную TZ=Europe/Moscow. Мелочь, а полчаса гугления. Таймзоны в контейнерах — это классическая проблема: по умолчанию контейнеры живут в UTC. Одна переменная окружения — и расписания работают в вашем времени. Запомните: всегда задавайте TZ при развёртывании. Это сэкономит время в будущем. SSH Credentials. n8n хранит credentials в зашифрованном виде, но ключ шифрования нужно передавать через переменную окружения N8N_ENCRYPTION_KEY. Если не задать — при перезапуске контейнера все пароли сбросятся. Я не задал, и после обновления образа пришлось всё переподключать. Больше не повторю эту ошибку. Ключ шифрования — это страховка ваших данных: без него при пересоздании контейнера все credentials теряются. Генерация ключа — одна команда, а настройка — одна строка в docker-compose. Правило: любые секреты в Docker — только через переменные окружения. Это надёжно и не теряется при обновлениях.

HTTP Requests к внутренним сервисам. Когда n8n стучится к сервису на локалхосте, он стучится к себе внутри контейнера. А мне нужно было достучаться до хостового nginx. Пришлось использовать IP Docker-хоста и убедиться, что порт не заблокирован фаерволом. Вместо localhost я написал host.docker.internal — не сработало на Linux. В итоге использовал IP хоста из сети Docker. Сетевые адреса внутри Docker — это отдельная вселенная: localhost внутри контейнера — это сам контейнер. Для доступа к хосту нужен IP хоста из сети Docker или специальное имя. На Linux host.docker.internal работает не всегда. Правильный путь — узнать IP хоста в Docker-сети и открыть нужный порт в файрволе. Час возни — но теперь знаю. Что я автоматизировал ещё.

Как только я распробовал n8n, остановиться было сложно. Теперь у меня крутится: Резервное копирование БД. Каждую ночь n8n выполняет дамп MySQL через SSH, архивирует и отправляет на отдельный бекап-сервер. Раньше я делал это crontab-ом, но с n8n удобнее визуально видеть, что бекап прошёл успешно. Бэкапы через n8n — это наглядность: вы видите каждый шаг — дамп, архивацию, отправку. Ошибка подсвечивается, и вы узнаёте о ней сразу. crontab работает вслепую: команда выполнилась или нет — неизвестно. n8n даёт визуальный контроль над бекапами. Публикация в соцсети. Я пишу статью в WordPress, ловлю webhook и автоматически пощу анонс в Telegram-канал. Без n8n я бы просто забывал это делать. Webhook-интеграция — это мост между сайтом и Telegram. WordPress шлёт вебхук при публикации, n8n его ловит и форматирует анонс. Автоматическая публикация экономит время и не даёт забыть о новых статьях. Одна публикация — и анонс улетает подписчикам. Это правило для любого контент-проекта.

Мониторинг SSL-сертификатов. Раз в день проверяю, сколько дней осталось до истечения сертификата Let’s Encrypt. Если меньше 7 — шлю панику в Telegram. Однажды сертификат протух, и сайт лёг — больше такого не хочу. Протухший SSL-сертификат — это не просто ошибка, это потерянный трафик и доверие посетителей. Мониторинг дней до истечения — тривиальный workflow, но он защищает от глупой потери сайта. Проверка раз в день, уведомление при остатке менее недели. Автопродление Let’s Encrypt работает почти всегда, но контроль не помешает. Лучше перебдеть. Уборка логов. Раз в неделю чищу логи nginx и Docker старше 30 дней. Скрипт тривиальный, но в n8n он хотя бы виден и не теряется. Ручная уборка логов — это скучная рутина, которую легко забыть. Логи растут, диск забивается, и однажды сайт падает по «No space left». Автоматическая уборка раз в неделю держит диск чистым. n8n делает её видимой: вы всегда знаете, что и когда выполнилось. Что мне не нравится.

n8n не без греха. Он жрёт память — контейнер с n8n на нагрузке ест около 300-400 MB RAM, хотя я дал ему 512. Для домашнего сервера терпимо, но если бы я крутил его на Raspberry Pi — пришлось бы экономить. Потребление памяти — это цена за удобство. Node.js и многочисленные библиотеки весят прилично. Для домашнего сервера 400 MB — приемлемо. Для Raspberry Pi — уже впритык, но многие крутят n8n и на них. Оптимизация: отключить неиспользуемые узлы и интеграции. Ещё веб-интерфейс тормозит, если в workflow больше 20 узлов. Граф начинает подлагивать при перетаскивании. Для сложных сценариев это раздражает. Большие workflow — это нагрузка на браузер: каждый узел — это DOM-элементы, данные, соединения. Совет: разбивайте сложные сценарии на несколько workflow. Один процесс — один workflow. Это и читабельнее, и быстрее. Но главное — документация. Она есть, но часто описывает идеальный сценарий, а на практике что-то идёт не так.

Например, SSH Node: в доке написано «просто введи хост», а в реальности мне пришлось разбираться с ключами, known_hosts и правами на приватный ключ. Минут 40 потерял. SSH — это зона повышенной сложности: ключи, known_hosts, права доступа 600, типы ключей. Практические сценарии всегда отличаются от идеальных примеров. Выход — комьюнити n8n: форумы, Discord, готовые шаблоны. Если что-то не работает — почти наверняка кто-то уже это решал. Документация — точка роста проекта. Итог. n8n — это штука, которую я советую попробовать всем, у кого есть домашний сервер и хотя бы пара рутинных задач. Он не заменяет bash-скрипты для всего, но для визуального контроля над автоматизацией — лучшее, что я пробовал. Главное, что я вынес: начинайте с малого. Не пытайтесь построить идеальный workflow с первого раза. Сделайте один простой сценарий — пусть пингует сервер и шлёт уведомления. Когда увидите, что это реально работает, добавите остальное само собой. Начните с одного workflow, доведите его до ума — и автоматизация станет вашей привычкой. n8n открыл мне глаза на то, сколько рутины можно автоматизировать без написания скриптов.