Как развернуть n8n на своём сервере: установка, защита, обновления

Короткий ответ

Для рабочего self-hosted n8n понадобятся:

• VPS с Docker и Docker Compose;
• PostgreSQL вместо SQLite по умолчанию;
• обратный прокси с HTTPS (Caddy, Nginx или Traefik) и домен;
• постоянный ключ шифрования N8N_ENCRYPTION_KEY;
• бэкапы базы и плановые обновления на конкретную версию.

Установка через Docker Compose

Минимальная конфигурация с PostgreSQL. Секреты храните в файле .env рядом, а не в самом compose-файле:

services:
  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - pg_data:/var/lib/postgresql/data

  n8n:
    image: docker.n8n.io/n8nio/n8n:${N8N_VERSION}
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_HOST: n8n.example.com
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://n8n.example.com/
      GENERIC_TIMEZONE: Asia/Tashkent
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres

volumes:
  pg_data:
  n8n_data:

Порт открыт только на 127.0.0.1 — снаружи n8n доступен лишь через прокси. С Caddy HTTPS-сертификат выпускается автоматически:

n8n.example.com {
    reverse_proxy localhost:5678
}

WEBHOOK_URL обязателен за прокси: иначе n8n будет показывать в вебхуках внутренний адрес вместо публичного.

SQLite или PostgreSQL

Для всего, на что опирается бизнес, берите PostgreSQL сразу: переезд потом сложнее, чем установка с нуля.

Queue mode: когда он нужен

По умолчанию все выполнения идут в одном процессе. Если сценариев много, они тяжёлые или вебхуки приходят пачками, включают queue mode:

• основной процесс принимает триггеры и вебхуки и кладёт задания в очередь Redis;
• отдельные воркеры (n8n worker) забирают и выполняют задания;
• воркеров можно добавлять по мере роста нагрузки.

Включается переменной EXECUTIONS_MODE=queue и настройками Redis. У всех процессов должен быть одинаковый N8N_ENCRYPTION_KEY. Не включайте queue mode «на вырост» — это лишние компоненты, которые тоже нужно обслуживать.

Защита

• Ключ шифрования. n8n шифрует сохранённые учётные данные (credentials) этим ключом. Задайте его явно и храните копию в менеджере паролей. Потеряете ключ — все credentials придётся вводить заново.
• Доступ. Включите учётные записи пользователей и двухфакторную аутентификацию, не используйте общий логин на всю команду.
• Сеть. Наружу открыты только 80 и 443, SSH — по ключам, база данных не публикуется.
• Вебхуки. Включайте аутентификацию в узле Webhook (заголовок, Basic или JWT), если вызывающая сторона это позволяет.
• История выполнений. Включите очистку старых выполнений (EXECUTIONS_DATA_PRUNE), иначе база будет расти и хранить персональные данные дольше, чем нужно.

Бэкапы

Бэкапить нужно три вещи:

1. Базу данных — там workflow, credentials и история.
2. Ключ шифрования — без него зашифрованные credentials из бэкапа бесполезны.
3. Том /home/node/.n8n — там конфигурация экземпляра.

docker compose exec -T postgres pg_dump -U n8n n8n | gzip > n8n-$(date +%F).sql.gz

Храните копии вне сервера и периодически проверяйте восстановление на тестовой машине.

Обновления

• Закрепляйте версию в N8N_VERSION, не используйте latest в продакшене.
• Перед обновлением прочитайте release notes и раздел о breaking changes.
• Сделайте бэкап, затем:

docker compose pull
docker compose up -d

• После обновления проверьте ключевые workflow и логи. При мажорном переходе сначала прогоните его на копии.

Когда self-hosting выгоднее облака

Свой сервер имеет смысл, если:

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

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