n8n Self-Hosting гайд 2026: повне налаштування production

Self-hosting n8n у 2026 коштує $4–12/міс за VPS і дає необмежену кількість executions, повний контроль над даними та платформу, яка масштабується з вашими потребами, а не з вашим рахунком. Архітектура — Docker Compose з PostgreSQL за Nginx reverse proxy і SSL від Let’s Encrypt — близько 30 хвилин якщо ви вже працювали з Linux-сервером. У цьому гайді — production-конфігурація, security hardening, бекапи й підводні камені, які зазвичай вилазять на другому тижні.

Зміст

Навіщо self-hosting n8n у 2026
Вимоги до сервера і порівняння провайдерів
Production-налаштування docker-compose
Environment variables, які мають значення
Nginx reverse proxy і SSL від Let’s Encrypt
Чек-ліст безпеки
Автоматичні бекапи
Оновлення та керування версіями
Типові пастки і як їх обійти
Коли масштабувати: queue mode і Redis
FAQ

Навіщо self-hosting n8n у 2026

n8n Cloud стартує від €24/міс за 2 500 executions на тарифі Starter. €4 Hetzner VPS дає необмежені executions і повний контроль над даними. Математика стає очевидною дуже швидко — але ціна не єдина причина. Self-hosting — правильна відповідь коли:

Ви робите понад 50 000 executions/міс. Вище цього обсягу будь-яка хмарна платформа автоматизації стає дорогою. У n8n self-hosted немає оплати за виконання.
Важлива data residency. Медицина, фінтех, суворі GDPR-кейси в ЄС — інфраструктура під вашим контролем це найчистіший шлях до compliance.
Потрібні кастомні інтеграції або npm-пакети. Self-hosted n8n дозволяє писати JavaScript або Python, ставити кастомні пакети та запускати код, який хмарні платформи обмежують.
Хочете незалежність від платформи. Жодного vendor lock-in, ніяких сюрпризів з цінами, ніяких rate limits, що визначає хтось інший.

Компроміс реальний: ви стаєте відповідальні за uptime, бекапи, security-патчі та продовження SSL. Якщо це звучить болісно — перегляньте порівняння альтернатив Zapier разом із managed n8n, перш ніж обирати self-hosting.

Вимоги до сервера і порівняння провайдерів

Мінімальні характеристики: 1 vCPU, 1 GB RAM, 25 GB SSD. Підійде для особистого користування й легкої роботи з клієнтами — але обов’язково ввімкніть swap, щоб уникнути падінь через нестачу пам’яті в пікові моменти.

Рекомендовано для production: 2 vCPU, 4 GB RAM, 40+ GB SSD. Спокійно тягне n8n + PostgreSQL + Nginx для SMB або агенції. Це sweet spot для 90% self-hosters.

Провайдер	Рекомендований план	Характеристики	Ціна	Найкраще для
Hetzner	CAX11 (ARM) / CX22	2 vCPU / 4 GB / 40 GB	€3,29–4,51/міс	Найкраща ціна/перформанс, EU
DigitalOcean	Basic Droplet	2 vCPU / 4 GB / 80 GB	$24/міс	Полірований UX, чудова дока
Vultr	High Performance	2 vCPU / 4 GB / 80 GB	$24/міс	Глобальне покриття, 32 ДЦ
Contabo	VPS S	4 vCPU / 8 GB / 200 GB	~$7/міс	Найбільше RAM за гроші
Hostinger VPS	KVM 2	2 vCPU / 8 GB / 100 GB	~$5–7/міс	Початківці, є шаблон n8n

Для більшості читачів Hetzner CAX11 — очевидний переможець: €3,29/міс за 2 vCPU і 4 GB RAM — це непереможно в Європі. Компроміс — верифікація особи на реєстрації, що займає кілька годин. Sign-up credit DigitalOcean у $200 може компенсувати премію за перші 12 місяців.

Production-налаштування docker-compose

Рекомендований спосіб запуску n8n — Docker Compose з PostgreSQL. SQLite підходить для одного користувача в тестовому інстансі, але для production-навантажень правильний вибір — Postgres: чисто переживає рестарти контейнерів, легко бекапиться, масштабується коли ви ростете.

Створіть директорію проєкту і файл docker-compose.yml:

services:
  postgres:
    image: postgres:16-alpine
    container_name: n8n-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: n8n
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - n8n-network
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_HOST=${DOMAIN}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://${DOMAIN}/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_RUNNERS_ENABLED=true
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
      - GENERIC_TIMEZONE=${TZ}
      - TZ=${TZ}
      - NODE_ENV=production
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - n8n-network

volumes:
  postgres_data:
  n8n_data:

networks:
  n8n-network:
    driver: bridge

Зверніть увагу на binding до 127.0.0.1:5678 замість 0.0.0.0. Це означає, що n8n доступний лише через локальний Nginx reverse proxy, ніколи напряму з інтернету. Для production це обовʼязково.

Environment variables, які мають значення

Створіть файл .env поряд із docker-compose. Згенеруйте сильні значення для секретів:

POSTGRES_PASSWORD=$(openssl rand -base64 32)
N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)
DOMAIN=automation.yourdomain.com
TZ=Europe/Kyiv

Дві критичні змінні, які більшість гайдів проскакують:

N8N_ENCRYPTION_KEY — шифрує збережені креденшіали. Втратите її — і всі збережені креденшіали неможливо відновити. Збережіть її в password manager одразу після генерації. n8n автоматично створює ключ при першому запуску, якщо він відсутній, але краще задати явно — тоді контроль за вами.
WEBHOOK_URL — повинна точно збігатися з публічним HTTPS URL. Слеш у кінці важливий. Якщо webhooks не спрацьовують після налаштування, причина майже завжди тут. Webhooks — основа більшості сценаріїв n8n; якщо ви новачок, читайте наш матеріал про що таке webhook і як його тестувати.

Nginx reverse proxy і SSL від Let’s Encrypt

Встановіть Nginx і Certbot на хості, спрямуйте A-запис домену на IP вашого VPS, потім створіть /etc/nginx/sites-available/n8n.conf:

server {
    listen 80;
    server_name automation.yourdomain.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name automation.yourdomain.com;

    ssl_certificate /etc/letsencrypt/live/automation.yourdomain.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/automation.yourdomain.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 86400;
    }
}

Далі видаємо сертифікат та активуємо автопродовження:

sudo certbot --nginx -d automation.yourdomain.com
sudo systemctl enable certbot.timer
sudo systemctl start certbot.timer

Налаштування proxy_read_timeout 86400 — критичне: без нього довгі executions n8n обриватиме Nginx. Заголовки Upgrade і Connection потрібні для WebSocket-зʼєднання редактора.

Чек-ліст безпеки

Self-hosted n8n зі слабкою безпекою — це просто крадіжка креденшіалів, що чекає свого часу. Платформа зберігає API-ключі, паролі баз, OAuth-токени — рівно те, що потрібно атакерам. Зачиніть це до підключення першої інтеграції:

UFW firewall: дозвольте лише SSH (бажано на нестандартному порту), 80 і 443. Все інше — заблоковано.
SSH-hardening: вимкніть password auth, лише ключі, поставте PermitRootLogin no. Додайте fail2ban проти brute-force.
Увімкніть вбудовану 2FA n8n для облікового запису власника одразу після першого логіну.
Закріпіть версію Docker-образу в production: docker.n8n.io/n8nio/n8n:1.x.x замість :latest. Це запобігає неочікуваним апгрейдам при рестарті контейнера.
Обмежте середовище task runners: ставте NODE_FUNCTION_ALLOW_EXTERNAL=* лише за крайньої потреби, ніколи на публічному інстансі, що виконує недовірений код.
Запустіть автоматичні OS-апдейти для security-патчів: unattended-upgrades на Debian/Ubuntu.

Автоматичні бекапи

База n8n тримає workflows, креденшіали та історію виконань. Втратите її — втратите місяці роботи. Бекап має включати dump PostgreSQL і data volume n8n (там лежить файл ключа шифрування). Бекап лише одного з них — марний.

Скрипт щоденного бекапу (покладіть у /usr/local/bin/n8n-backup.sh, зробіть виконуваним, запускайте через cron):

#!/bin/bash
BACKUP_DIR=/var/backups/n8n
DATE=$(date +%Y-%m-%d)
mkdir -p $BACKUP_DIR

# PostgreSQL dump
docker exec n8n-db pg_dump -U n8n n8n | gzip > $BACKUP_DIR/db-$DATE.sql.gz

# n8n data volume (encryption key, custom nodes)
docker run --rm -v n8n_data:/data -v $BACKUP_DIR:/backup \
    alpine tar -czf /backup/n8n-data-$DATE.tar.gz -C /data .

# Тримаємо останні 14 днів локально
find $BACKUP_DIR -name "*.gz" -mtime +14 -delete

# Sync на віддалений сторадж (S3, Backblaze B2 або rsync)
rclone copy $BACKUP_DIR remote:n8n-backups/

Додайте у cron через crontab -e:

0 3 * * * /usr/local/bin/n8n-backup.sh >> /var/log/n8n-backup.log 2>&1

Протестуйте процес відновлення хоча б раз. Бекап, з якого ви ніколи не відновлювалися, — це не бекап, а надія.

Оновлення та керування версіями

n8n релізить часто — minor-версії з фіксами, major-версії раз на кілька місяців з можливими breaking changes. Процес апдейту для Docker:

# Спочатку завжди бекап
/usr/local/bin/n8n-backup.sh

# Pull і перезапуск
cd /opt/n8n
docker compose pull
docker compose up -d

# Перевірка
docker compose logs -f n8n

Читайте release notes n8n перед будь-яким major-апгрейдом. Database migrations інколи незворотні. Найбезпечніший production-патерн — закріпити конкретну версію, відстежувати changelog і апгрейдитись свідомо, а не автоматично тягнути latest.

Типові пастки і як їх обійти

Webhooks повертають 404 або не спрацьовують. Майже завжди неправильний WEBHOOK_URL — повинен точно збігатися з публічним HTTPS URL, включно зі слешем у кінці. Перезапустіть контейнер після виправлення.
Out-of-memory падіння на 1 GB VPS. Додайте swap-файл на 2 GB. Реалістично — апгрейдьте до 4 GB RAM, якщо запускаєте щось серйозніше за хоббі-навантаження.
“Editor unreachable” або WebSocket-помилки після Nginx. Не вистачає заголовків Upgrade/Connection у proxy-конфігу. Перепровірте Nginx-блок.
Помилка decryption креденшіалів після відновлення. Encryption key відсутній у відновленому data volume. Або відновіть повний n8n_data volume, або задайте N8N_ENCRYPTION_KEY явно з оригінальним значенням.
Повільне виконання через кілька тижнів. Історія виконань роздуває базу. Налаштуйте EXECUTIONS_DATA_PRUNE=true і EXECUTIONS_DATA_MAX_AGE=336 (годин = 14 днів).
Бекапи тихо не працюють. Перевірте, що cron виконується: grep CRON /var/log/syslog. Налаштуйте dead-man’s switch — моніторинг, що пінгує вас, коли бекап не запустився.

Коли інстанс стабільний, логуйте все, що проходить через webhook-границі — у нашому матеріалі про як логувати webhooks правильно розібрані патерни, що роблять дебаг можливим.

Коли масштабувати: queue mode і Redis

Single-instance setup вище комфортно тримає 5–8 одночасних workflows на 2 vCPU / 4 GB. Більшість SMB ніколи не виростає за нього — реальне вузьке місце для типових навантажень це час відповіді API, а не VPS.

Якщо ви впираєтесь у стелю (великі concurrent-навантаження, багато довгих workflows, черга росте), переходьте у queue mode з Redis. Додайте Redis у compose, поставте EXECUTIONS_MODE=queue, QUEUE_HEALTH_CHECK_ACTIVE=true, запустіть окремі worker-контейнери. Глибше про порівняння масштабованості різних платформ автоматизації — у нашому матеріалі n8n vs Make.

FAQ

Скільки реально коштує self-hosting n8n у 2026?

$4–12/міс за VPS залежно від провайдера й характеристик. Hetzner CAX11 за €3,29/міс — найдешевший production-варіант. Додайте ~$1–2/міс на off-site бекапи (Backblaze B2, S3) — і виходить менше $15/міс загалом за необмежені executions і повний контроль над даними.

Чи можна self-hosting n8n на 1 GB RAM VPS?

Так, для особистого або хоббі-кейсу — але вмикайте swap-файл на 2 GB, щоб запобігти OOM-падінням. Для будь-якого production-навантаження реалістичний мінімум — 4 GB RAM. Йти нижче — фальшива економія: дебаг OOM-крешів зʼїдає набагато більше часу, ніж $2/міс різниці.

SQLite чи PostgreSQL для n8n?

SQLite для тестів і одного користувача. PostgreSQL для всього іншого. Postgres правильно тримає одночасні записи, плавно масштабується, спрощує бекапи. Docker Compose з Postgres додає максимум 5 хвилин до setup і рятує від необхідності перебудови коли ви виростете з SQLite.

Як безпечно оновлювати n8n не зламавши workflows?

Закріпіть конкретні версії в production. Робіть бекап перед будь-яким апдейтом. Для major-версій читайте changelog щодо breaking changes, тестуйте на staging-інстансі якщо ваші workflows бізнес-критичні, і майте план відкату (попередній Docker-тег плюс бекап бази до апгрейду).

Чи self-hosted n8n безпечний для чутливих даних?

Може бути безпечнішим за будь-яку хмарну альтернативу — ви контролюєте увесь стек. Але “може бути” вимагає зусиль: SSH-hardening, firewall, автоматичні OS-апдейти, шифровані бекапи, моніторинг логів доступу. Із цим self-hosted n8n підходить для HIPAA, GDPR, SOC 2. Без цього — у вас treasure trove креденшіалів на публічному інтернеті.

Коли переходити з self-hosted на managed n8n?

Коли час на підтримку інфраструктури перевищує вартість managed-хостингу за вашою ставкою. Для більшості соло-розробників і малих команд накладні витрати — близько 1 години/міс після початкового setup. Якщо проводите 4+ годин на місяць у n8n-ops, managed за $7–25/міс — мабуть, краща економіка, що звільняє вас на побудову автоматизацій.