Установка n8n self-hosted: с нуля до первого workflow

Self-hosted n8n — популярный выбор для тех, кто хочет держать данные у себя и не платить ежемесячно за облако. Но установка — это только начало. Дальше начинается эксплуатация: обновления, бэкапы, безопасность, падения в три часа ночи. Эта статья честно проведёт тебя через весь путь — от пустого сервера до работающего первого workflow — без пропущенных шагов и лишней теории. Всё, что написано ниже, мы в FlowFrame делали руками сотни раз.

Ты понимаешь, что берёшь на себя: чем self-hosted отличается от облака

Self-hosted n8n — это установка и запуск платформы автоматизации n8n на собственном сервере, без использования облачного сервиса n8n Cloud. Ты получаешь полный контроль над данными, неограниченное количество воркфлоу и исполнений, но берёшь на себя всю техническую ответственность: обновления, безопасность, бэкапы и доступность сервиса. Это принципиальное отличие от облака, где всё это делает команда n8n за тебя.

Давай по-честному разберём три параметра, которые реально влияют на решение.

Стоимость. n8n Cloud в 2026 году стоит от $20 до $50 в месяц на базовых тарифах, и цена растёт с количеством исполнений. Self-hosted обходится в $10–20 в месяц за VPS плюс твоё время. Если воркфлоу простые и их немного — облако дешевле с учётом нулевых трудозатрат. Если исполнений тысячи в день — self-hosted выигрывает по деньгам.

Контроль данных. Всё, что проходит через n8n — данные клиентов, API-ключи, содержимое запросов — при self-hosted остаётся на твоём сервере. Для бизнеса с требованиями к обработке персональных данных или корпоративной политикой безопасности это часто не выбор, а необходимость.

Техническая нагрузка. Вот тут — главный подводный камень. У наших клиентов часто складывается ощущение, что установить n8n — это разовая задача на два часа. На деле за ней тянется операционный хвост: раз в месяц обновить контейнер, следить за дисковым пространством, реагировать на инциденты. Если в команде нет человека, который умеет работать с Linux и Docker хотя бы на базовом уровне — self-hosted превращается в источник стресса, а не экономии.

Сервер выбран и готов к установке

Минимальные требования для комфортной работы n8n на малый бизнес в 2026 году: 2 ГБ RAM, 1 vCPU, 20 ГБ SSD, операционная система Ubuntu 22.04 LTS. Это не теоретический минимум — это то, что реально работает без тормозов при 50–200 исполнениях в день.

Где брать сервер: Hetzner, DigitalOcean, Timeweb Cloud, Selectel — все подходят. Hetzner CX22 за €3.79 в месяц закрывает базовые потребности. Для российского бизнеса с требованиями к размещению данных в РФ — Timeweb Cloud или Selectel от 500–800 ₽ в месяц за аналогичные характеристики.

Классическая ошибка тут — брать самый дешёвый VPS за $5 с 1 ГБ RAM. n8n на Node.js при старте потребляет около 300–400 МБ сразу, плюс операционная система, плюс Nginx, плюс база данных. При такой конфигурации n8n начинает свопиться на диск, и пользователи жалуются, что «всё тормозит». Мы видели это у каждого третьего клиента, который приходил к нам после самостоятельной установки.

Что установить на сервер перед началом: Docker Engine, Docker Compose v2, Nginx, Certbot. Всё это есть в стандартных репозиториях Ubuntu и ставится за 10 минут.

n8n запущен и доступен по вашему домену

Установка через Docker Compose — самый надёжный способ, который легко обновлять и откатывать. Вот минимальный рабочий docker-compose.yml:

• Создай директорию: mkdir ~/n8n && cd ~/n8n
• Создай файл docker-compose.yml со следующим содержимым:

Переменные окружения, которые нужно прописать обязательно: N8N_HOST — твой домен (например, n8n.company.ru), N8N_PORT — 5678, N8N_PROTOCOL — https, WEBHOOK_URL — полный URL с https, N8N_ENCRYPTION_KEY — случайная строка из 32+ символов (хранит credentials зашифрованными). Без последнего ключа при пересоздании контейнера все сохранённые credentials станут нечитаемыми.

Запуск: docker compose up -d. Проверка, что контейнер поднялся: docker compose logs -f. Если в логах нет ошибок и видна строка «Editor is now accessible» — n8n работает на порту 5678.

Настройка Nginx в роли обратного прокси занимает 5 минут. Создай конфиг в /etc/nginx/sites-available/n8n, пропиши proxy_pass на 127.0.0.1:5678, включи поддержку WebSocket (заголовки Upgrade и Connection — обязательны, иначе редактор будет работать нестабильно). Получи SSL-сертификат командой certbot --nginx -d n8n.company.ru — Certbot сам допишет конфиг и настроит автообновление сертификата.

На нашей практике 80% проблем на этом этапе — неправильно настроенные WebSocket-заголовки в Nginx. Если редактор n8n открывается, но воркфлоу не запускаются или интерфейс зависает — первым делом проверяй именно их.

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

Аккаунт создан и базовая безопасность настроена

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

После регистрации первым делом сделай три вещи. Первое — отключи публичную регистрацию новых пользователей: в Settings → Users отключи возможность самостоятельной регистрации, если не нужна командная работа. Второе — убедись, что переменная окружения N8N_ENCRYPTION_KEY задана и зафиксирована в файле .env (не потеряй её — это ключ от всех твоих credentials). Третье — настрой двухфакторную аутентификацию для владельца аккаунта через встроенные настройки безопасности.

Открытый n8n без пароля на публичном IP — мы встречали это у каждого пятого нового клиента, который обращался к нам за помощью. Иногда люди устанавливали n8n «посмотреть», забывали про него на неделю, а потом обнаруживали чужие воркфлоу или использование их сервера для спам-рассылок. Дополнительно можно закрыть порт 5678 в firewall (ufw deny 5678) — снаружи n8n должен быть доступен только через Nginx на 443 порту.

Данные не потеряются: резервное копирование настроено

По умолчанию n8n хранит всё в SQLite-файле по пути /home/node/.n8n/database.sqlite внутри контейнера, который монтируется в директорию на хосте — обычно ~/.n8n/. Там же лежат credentials в зашифрованном виде. Вся эта директория — это и есть твой бэкап.

Минимальный рабочий сценарий бэкапа: cron-задача, которая раз в сутки копирует директорию ~/.n8n/ в облачное хранилище. Для этого подойдёт rclone — бесплатный инструмент, который умеет работать с S3, Google Drive, Яндекс Диском и десятками других хранилищ. Настройка занимает 20 минут, скрипт — 5 строк. Добавь в crontab: 0 3 * * * /usr/bin/rclone sync ~/.n8n/ remote:n8n-backup/$(date +\%Y-\%m-\%d) — и бэкап будет создаваться каждую ночь в 3:00.

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

Если планируешь расти — сразу смотри в сторону Postgres вместо SQLite. Переход болезненный: нужна миграция данных. Лучше принять это решение на старте, чем через полгода.

Первый рабочий workflow запущен и проверен

Прежде чем строить боевые автоматизации, убедись, что всё работает корректно. Для этого собери простой тестовый сценарий: Webhook → Set → Telegram. Это проверяет сразу три вещи: входящие запросы принимаются, данные обрабатываются, исходящие интеграции подключаются.

1. Добавь ноду Webhook, выбери метод POST, скопируй тестовый URL.
2. Добавь ноду Set — задай переменную message со значением из входящих данных.
3. Добавь ноду Telegram — подключи бота через BotFather, укажи chat_id, отправь message.
4. Активируй воркфлоу и отправь тестовый POST-запрос через curl или Postman.

Если сообщение пришло в Telegram — установка полностью рабочая. Если нет — смотри логи: docker compose logs n8n --tail=50. Логи n8n очень информативны: там будет точная нода, где возникла ошибка, и HTTP-код ответа от внешнего сервиса.

Что ещё проверить перед боевым использованием: убедись, что Webhook URL в настройках n8n совпадает с реальным доменом (иначе внешние сервисы не смогут достучаться), проверь, что SSL-сертификат валиден (certbot certificates), и убедись, что контейнер настроен на автозапуск после перезагрузки сервера (restart: unless-stopped в docker-compose.yml). Посмотри также наши примеры автоматизаций — там есть готовые сценарии, которые можно адаптировать под свои задачи.

FAQ

Можно ли потом перенести воркфлоу с self-hosted на n8n Cloud или обратно?

Да, воркфлоу переносятся через экспорт и импорт JSON — это работает в обе стороны. Но credentials (API-ключи, токены, пароли) перенести нельзя: они зашифрованы и привязаны к конкретному экземпляру. После переноса придётся вручную перевязывать все подключения заново. Также стоит проверить совместимость версий: если на self-hosted стоит более новая версия n8n, чем в облаке, некоторые ноды могут не импортироваться корректно.

Какая база данных лучше: SQLite или Postgres?

SQLite достаточно для старта и команды до 3–5 человек при нагрузке до 500–1000 исполнений в день. Postgres нужен, если воркфлоу запускаются очень часто (тысячи в день), нужна репликация или несколько экземпляров n8n. Практический порог: если SQLite-файл вырос до 1 ГБ и ты замечаешь задержки — пора переходить. Лучше принять это решение на старте, чем мигрировать потом.

Нужен ли системный администратор для поддержки self-hosted n8n?

Постоянный сисадмин не нужен, но нужен кто-то в команде, кто умеет читать логи Docker, обновлять контейнер раз в месяц и реагировать на инциденты. Это занимает 1–2 часа в месяц в штатном режиме. Если такого человека нет — инциденты будут накапливаться: закончится дисковое пространство, просрочится сертификат, сломается обновление. Всё это решаемо, но требует времени в самый неподходящий момент.

Как обновлять n8n без потери данных и воркфлоу?

Правильный порядок: сначала бэкап директории ~/.n8n/, затем проверка changelog на breaking changes (они бывают при мажорных обновлениях), затем docker compose pull && docker compose up -d. Делать pull вслепую опасно: в некоторых версиях менялась схема базы данных или поведение нод. Миграция базы запускается автоматически при старте, но без бэкапа откатиться при проблеме будет невозможно.

Сколько стоит содержать self-hosted n8n в месяц?

Прямые расходы: VPS от 500 ₽ до 1500 ₽ в месяц в зависимости от провайдера и конфигурации. Скрытые расходы — время на администрирование: в штатном режиме 1–2 часа в месяц, при инцидентах может быть 4–8 часов. Для сравнения: n8n Cloud на сопоставимом объёме задач стоит $20–50 в месяц, но включает всё обслуживание. Self-hosted выгоден, если исполнений много или данные нельзя выносить за периметр.

Хочешь, чтобы это сделали за тебя?

Если в процессе чтения стало понятно, что возиться с Docker, Nginx, бэкапами и обновлениями — не то, на что хочется тратить время, это абсолютно нормальная реакция. Большинство владельцев бизнеса приходят именно к такому выводу после первой самостоятельной попытки.

FlowFrame занимается именно этим: разворачивает n8n под ключ, настраивает безопасность, резервное копирование и мониторинг, а затем строит автоматизации под конкретные процессы твоего бизнеса. Мы уже прошли этот путь сотни раз — и знаем, где обычно ломается.

Если нужна оценка проекта или просто хочешь понять, сколько это стоит и что реально можно автоматизировать — напиши нам на странице экспертизы по n8n. Расскажем честно, даже если окажется, что облако подойдёт лучше.