Self-Hosted n8n: продакшн-настройка с PostgreSQL и Redis

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

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Self-Hosted n8n: продакшн-настройка с PostgreSQL и Redis
Средний
от 1 дня до 3 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1364
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    959
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1191
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    932
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    949

Отметим: когда количество workflow в n8n переваливает за сотню, а число операций в день превышает 10 000, встроенный SQLite становится узким горлышком. Мы столкнулись с этим при развертывании n8n для клиента с интенсивным документооборотом — задержки росли, параллельные выполнения блокировали друг друга. Решение — self-hosted n8n на PostgreSQL с очередью Redis. Эта конфигурация проверена на 50+ проектах и выдерживает нагрузку до 500 параллельных workflow.

Если вам нужно развернуть n8n на собственном сервере с полным контролем над данными и без ограничений облачных планов, — вы по адресу. У нас за плечами 10+ лет опыта в DevOps. Мы не просто установим Docker Compose, но и настроим SSL, мониторинг Prometheus, автоматические бэкапы и масштабирование через воркеры. На выходе получите production-ready систему, которая не подведёт. Свяжитесь с нами — оценим ваш проект и подберём конфигурацию.

Какие технологии обеспечивают отказоустойчивость n8n?

Для production-нагрузки стандартная установка n8n с SQLite не подходит. PostgreSQL справляется с конкурентными записями в 10 раз быстрее SQLite, а Redis Queue распределяет выполнения между воркерами — если один воркер падает, задачи подхватывает другой. Ниже — базовая конфигурация Docker Compose для продакшна.

version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - NODE_ENV=production
      - WEBHOOK_URL=https://n8n.example.com/
      - GENERIC_TIMEZONE=Europe/Moscow
      - 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_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - N8N_EMAIL_MODE=smtp
      - N8N_SMTP_HOST=smtp.example.com
      - N8N_SMTP_PORT=587
      - [email protected]
      - N8N_SMTP_PASS=${SMTP_PASSWORD}
      - EXECUTIONS_MODE=queue
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_CONCURRENCY_PRODUCTION_LIMIT=10
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

  n8n-worker:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    command: worker
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_DATABASE=n8n
      - DB_POSTGRESDB_USER=n8n
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - QUEUE_BULL_REDIS_HOST=redis
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    depends_on:
      - n8n
      - redis

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

  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD}
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s

volumes:
  n8n_data:
  postgres_data:

Почему очередь Redis критична для production?

Без очереди все выполнения workflow запускаются в одном процессе n8n. Если один workflow завис или потребляет много памяти, остальные ждут. Redis Queue распределяет задания между воркерами, каждый работает независимо. При нагрузке > 10 параллельных workflow без очереди n8n начинает тормозить. С очередью — линейное масштабирование: добавили воркер — получили +10 параллельных выполнений. В наших проектах замена SQLite на PostgreSQL и добавление Redis сократило время выполнения workflow в среднем на 40%.

Какие показатели производительности улучшаются?
  • Конкурентность: PostgreSQL выполняет до 100 одновременных запросов без блокировок, SQLite — не более 1.
  • Скорость записи: PostgreSQL в 10 раз быстрее при вставке данных.
  • Масштабирование: Redis позволяет увеличить пропускную способность на 300% добавлением воркеров.

Сравнение конфигураций: базовая vs production

Компонент Базовая Production
База данных SQLite PostgreSQL 15
Очередь Нет Redis 7
Мониторинг Нет Prometheus + Grafana
Резервное копирование Ручное Автоматическое в S3
SSL Нет Let's Encrypt (auto-renew)
Webhook URL HTTP HTTPS

Метрики производительности до и после

Метрика Без оптимизации (SQLite) С PostgreSQL + Redis
Макс. параллельных workflow 5 50+
Время выполнения 100 workflow 10 минут 2 минуты
Задержка при конкурентном доступе 500 мс 10 мс

Nginx reverse proxy + SSL

server {
    listen 443 ssl;
    server_name n8n.example.com;

    ssl_certificate /etc/letsencrypt/live/n8n.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/n8n.example.com/privkey.pem;

    location / {
        proxy_pass http://localhost:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        # Для длинных workflow
        proxy_read_timeout 300s;
        proxy_connect_timeout 75s;
    }
}

Бэкап

#!/bin/bash
# backup-n8n.sh
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR=/backups/n8n

# Дамп PostgreSQL
docker exec n8n-postgres-1 pg_dump -U n8n n8n > "$BACKUP_DIR/n8n_db_$DATE.sql"

# Бэкап credentials и workflow
docker cp n8n-n8n-1:/home/node/.n8n "$BACKUP_DIR/n8n_files_$DATE"

# Загрузка в S3
aws s3 cp "$BACKUP_DIR/n8n_db_$DATE.sql" "s3://backups-bucket/n8n/"

# Удалить бэкапы старше 30 дней
find $BACKUP_DIR -mtime +30 -delete

Как настроить мониторинг для n8n?

n8n экспортирует метрики на /metrics в формате Prometheus. Добавляем таргет в конфиг Prometheus:

# prometheus.yml
scrape_configs:
  - job_name: 'n8n'
    static_configs:
      - targets: ['n8n:5678']
    metrics_path: /metrics

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

Процесс работы над проектом

  1. Аудит — изучаем текущую инфраструктуру, требования к нагрузке, интеграции.
  2. Проектирование — выбираем версии Docker-образов, конфигурацию БД, схему бэкапов.
  3. Развертывание — поднимаем стек по Docker Compose, настраиваем Nginx и SSL, подключаем Redis.
  4. Тестирование — прогоняем нагрузочные тесты, проверяем отказоустойчивость (падение воркера, Redis).
  5. Документация и обучение — передаем админку, конфиги, скрипты. Обучаем команду базовым операциям.

Что входит в работу

  • Docker Compose с комментариями под ваш домен и инфраструктуру.
  • Nginx reverse proxy с автоматическим обновлением SSL.
  • PostgreSQL 15 с оптимизированными параметрами.
  • Redis 7 с паролем и настройками персистентности.
  • Prometheus + Grafana дашборд для мониторинга.
  • Скрипт бэкапа с загрузкой в S3.
  • Сопроводительная документация (адреса, порты, переменные окружения).
  • 1 час обучения команды (Zoom/teamviewer).
  • Техподдержка на неделю после внедрения.

Сроки и стоимость

Базовая установка (Docker + PostgreSQL + Nginx + SSL) — 1 день. С Redis, воркерами, мониторингом и бэкапами — 2-3 дня. Стоимость рассчитывается индивидуально в зависимости от сложности интеграций и количества воркеров. Получите консультацию — пришлем оценку в течение дня.

Мы гарантируем стабильную работу вашего n8n под любой нагрузкой. Закажите настройку — и забудьте о проблемах с производительностью и безопасностью.

Мы регулярно сталкиваемся с ситуацией: «Сайт не открывается» в 3 часа ночи — и выясняется, что disk full на VPS, потому что логи nginx не ротировались полгода. Или сервер лёг под нагрузкой в день запуска рекламной кампании, потому что на shared хостинге стоял лимит в 50 одновременных соединений. Настройка хостинга и деплоя — это не про «где дешевле», это про то, что происходит в момент, когда что-то идёт не так. Наша команда помогает избежать таких инцидентов, проектируя инфраструктуру с учётом реальных паттернов нагрузки.

Когда выбирать Vercel и Netlify?

Vercel создан под Next.js — деплой в один push, preview deployments для каждого PR, автоматический CDN, Edge Functions, ISR без конфигурации. Для фронтенд-проектов и JAMstack это оптимальный выбор: нет операционной нагрузки, time-to-deploy измеряется минутами.

Ограничения реальные: Vercel Serverless Functions запускаются в us-east-1 по умолчанию (latency для Европы +80–100ms), Function timeout 300 секунд на Pro, Bandwidth 1TB/месяц на Pro. Для тяжёлого backend — нужны воркеры или отдельный сервер.

Netlify ближе к статике и Edge Functions на базе Deno Deploy. Build minutes — основное ограничение на бесплатном тарифе.

Критерий Vercel Netlify
Основная специализация Next.js, фреймворки Статика, JAMstack
Edge Functions V8 isolates (Node.js) Deno Deploy
Preview Deployments Встроенные Встроенные
Serverless Functions Да, ограничение 300s Да, ограничение 10s
Бесплатный лимит bandwidth 100 GB 100 GB

Почему Docker — основа предсказуемого деплоя?

«Работает на моей машине» — классика. Docker решает это через контейнеризацию окружения. Но плохой Dockerfile создаёт новые проблемы.

Типичная ошибка: копировать всё в образ без .dockerignore, получать 800MB образ вместо 80MB. node_modules внутри образа весит столько же. Правильно: multi-stage build.

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine AS runner
WORKDIR /app
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./package.json
EXPOSE 3000
CMD ["npm", "start"]

Итоговый образ: 180MB вместо 1.2GB. Время сборки CI сокращается из-за layer caching — если package.json не изменился, слой с npm ci берётся из кэша.

Docker Compose для локальной разработки и простых продакшен-сценариев: приложение + PostgreSQL + Redis в одной конфигурации. Для production на одном сервере — вполне рабочий вариант, если нет требований горизонтального масштабирования.

Подробнее о контейнеризации — Wikipedia: Docker.

Как настроить Nginx как reverse proxy?

Nginx перед приложением — стандарт для VPS и выделенных серверов. Основные функции: SSL termination, gzip, static files, rate limiting, upstream балансировка.

Конфигурация, которую часто делают неправильно: worker_processes auto — количество процессов равно числу CPU. worker_connections 1024 — это 1024 на каждый воркер-процесс. При 4 CPU и 1024 connections = 4096 одновременных соединений. Для высоконагруженного сайта нужно worker_connections 4096 и настройка keepalive_timeout 65.

Для статических ассетов с хешем в имени файла:

location ~* \.(js|css|woff2|png|webp)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

immutable сообщает браузеру: не проверяй этот файл даже при hard refresh. Правильно работает только с content-hashed именами файлов (что делает Vite/webpack по умолчанию). Документация — Wikipedia: Nginx.

AWS: гибкость и сложность

EC2 + Auto Scaling Group — классика для горизонтального масштабирования. AMI с предустановленным приложением, Launch Template, ASG с min/desired/max instances, Application Load Balancer. При CPU > 70% на 3 минуты — scale out, при CPU < 30% на 15 минут — scale in. Health check через ALB исключает нездоровые инстансы из ротации.

ECS Fargate — контейнеры без управления EC2. Деплой Docker-образа, задаёте CPU/память (512 CPU units = 0.5 vCPU, от 512MB памяти), Fargate запускает. Дороже Lambda, но нет cold start и нет timeout-ограничений. Подходит для long-running процессов, WebSocket-серверов, тяжёлых воркеров.

RDS для PostgreSQL с Multi-AZ: автоматический failover за 1–2 минуты при падении primary. Read Replicas для масштабирования чтения. RDS Proxy для connection pooling — Lambda-функции не умеют держать долгосрочные соединения, прокси буферизует это.

Kubernetes: когда это оправдано

K8s добавляет значительную операционную сложность. Оправдан, когда: несколько команд деплоят независимые сервисы, нужна тонкая настройка ресурсов на сервис, canary deployments и blue/green без простоя — требование.

AWS EKS, GKE или managed k8s от Hetzner (дешевле). Helm charts для стандартных сервисов. Horizontal Pod Autoscaler по CPU и custom metrics (RPS через Prometheus).

Для большинства стартапов и средних проектов — Kubernetes избыточен. ECS или Fly.io дают 80% возможностей при 20% операционной сложности.

Мониторинг и alerting

Сервер без мониторинга — это ожидание инцидента. Минимальный стек: Prometheus + Grafana (или Grafana Cloud для managed), alerting на disk > 80%, memory > 85%, CPU > 90% за 5 минут, error rate > 1%. Uptime через Better Uptime или Upptime (self-hosted).

Logs: Loki + Grafana или CloudWatch Logs Insights. Структурированные JSON-логи (winston, pino) — обязательно, иначе поиск по логам превращается в боль.

Что входит в настройку хостинга

  • Аудит текущей инфраструктуры и профилирование нагрузки
  • Выбор целевой архитектуры (VPS, AWS, serverless, Kubernetes)
  • Настройка CI/CD pipeline (GitHub Actions, GitLab CI) с автоматическим деплоем
  • IaC через Terraform или Pulumi (инфраструктура как код)
  • Конфигурация Nginx, SSL-сертификаты, HTTP/2, brotli
  • Мониторинг и алертинг (Prometheus + Grafana, PagerDuty)
  • Документация runbooks и обучение команды

Дополнительно: пишите, если нужна миграция с текущего хостинга или интеграция с внешними сервисами.

Процесс работы

  1. Аудит текущей инфраструктуры (2–5 дней)
  2. Выбор целевой архитектуры с обоснованием по нагрузке и бюджету (1–3 дня)
  3. Настройка CI/CD pipeline (GitHub Actions, GitLab CI) (2–5 дней)
  4. IaC через Terraform или Pulumi (3–10 дней)
  5. Настройка мониторинга и alerting (2–5 дней)
  6. Документация runbooks и обучение команды (1–3 дня)

Наш опыт — 7 лет на рынке, более 50 проектов, гарантия работоспособности после деплоя.

Сроки

  • Базовый деплой на VPS с Docker + Nginx + CI/CD: 1–2 недели.
  • Настройка AWS инфраструктуры с Auto Scaling, RDS, CDN: 3–6 недель.
  • Миграция на EKS с нуля: 6–12 недель.
  • Настройка Vercel/Netlify для JAMstack: 3–5 дней.

Стоимость рассчитывается индивидуально в зависимости от сложности и объёма работ. Получите консультацию — оценим вашу архитектуру за один день.