Установка n8n в Docker: self-hosted на своём сервере

Главная причина ставить n8n у себя - не экономия, а контроль: данные не уходят третьей стороне, а тарификация по количеству операций исчезает. Плата за это - вы становитесь администратором сервиса, и есть несколько вещей, которые лучше сделать сразу правильно.

Минимальный запуск

Для знакомства достаточно одного контейнера с примонтированным томом:

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

Том здесь - не опция. Без него все воркфлоу и доступы живут внутри контейнера и исчезнут при первом же обновлении образа.

Этого хватит, чтобы пощупать интерфейс. Для чего-то дольше пары дней нужен compose-файл и несколько переменных.

Что задать до первого воркфлоу

N8N_ENCRYPTION_KEY - самое важное. Этим ключом шифруются креденшелы. Если n8n сгенерирует его сам и вы потеряете том, восстановление из бэкапа базы даст воркфлоу без единого рабочего доступа. Задайте ключ явно и положите его туда же, где храните остальные секреты.

WEBHOOK_URL - публичный адрес вашего n8n. Без него вебхуки в интерфейсе будут показывать localhost:5678, и внешний сервис никуда не достучится.

GENERIC_TIMEZONE - часовой пояс для расписаний. По умолчанию UTC, и это ровно та причина, по которой «ежедневный отчёт в 9 утра» приходит в полдень.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - '127.0.0.1:5678:5678'
    environment:
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - WEBHOOK_URL=https://n8n.example.com/
      - GENERIC_TIMEZONE=Europe/Moscow
    volumes:
      - n8n_data:/home/node/.n8n
volumes:
  n8n_data:

Обратите внимание на 127.0.0.1:5678 - контейнер слушает только локально, наружу его выпускает прокси. Открывать порт в интернет напрямую не стоит.

HTTPS и реверс-прокси

Без домена с сертификатом self-hosted n8n остаётся игрушкой: платёжные системы, GitHub и большинство SaaS не отправят вебхук на http и на адрес с портом.

Реверс-прокси (Caddy проще всего, nginx привычнее) решает это: он терминирует TLS и проксирует на 5678. Одна деталь, о которую спотыкаются: прокси не должен обрезать длинные запросы и рвать соединение по таймауту - воркфлоу может выполняться минуты, и слишком строгий таймаут прокси оборвёт его на середине.

SQLite или PostgreSQL

По умолчанию n8n работает на SQLite. Для личных задач и десятка воркфлоу этого достаточно.

Переходить на PostgreSQL стоит, когда: выполнений становится много и история распухает, нужны параллельные запуски без блокировок, или n8n перестаёт быть личным инструментом и становится частью рабочего процесса. Переезд позже возможен, но это отдельная операция - если понимаете, что проект серьёзный, проще стартовать сразу на Postgres.

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

Обновления

Обновление сводится к смене образа: остановить, docker compose pull, поднять заново. Данные в томе переживают обновление.

Две привычки, которые экономят нервы: не обновляться вслепую на активном проекте (перед мажорной версией загляните в changelog - ноды меняются) и иметь свежий бэкап до апдейта, а не после.

Что бэкапить

Три вещи, и все три обязательны:

1. База данных - воркфлоу, выполнения, настройки.
2. Том /home/node/.n8n - файлы и локальные данные.
3. N8N_ENCRYPTION_KEY - иначе первые два пункта дадут вам систему без доступов.

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

Когда одного контейнера мало

Если воркфлоу становится много и они запускаются одновременно, одиночный процесс упрётся в себя. Тогда n8n разворачивают в режиме очереди: отдельный основной процесс, Redis для очереди и несколько воркеров, между которыми распределяются выполнения.

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