Бэкап и обновление n8n в продакшене (Docker Compose + PostgreSQL)
Руководство по эксплуатации самохостового n8n: автоматизированные бэкапы PostgreSQL, защита ключа шифрования, внесерверные копии с rclone, аварийное восстановление с чистого VPS, безопасные обновления через Docker Compose, откат и миграция с 1.x на 2.x.
Ты поднял n8n на VPS с Docker Compose и PostgreSQL. Это был первый день. Второй день — это поддержание работоспособности: автоматические бэкапы, проверенные восстановления и безопасные обновления.
Это руководство покрывает всё, что нужно для защиты продакшен-инстанса n8n. Мы соберём скрипт бэкапа, автоматизируем его через cron, скопируем бэкапы на другой сервер, пройдём аварийное восстановление на чистом VPS и безопасно обновим n8n с возможностью отката. Также разберём миграцию с 1.x на 2.x.
Руководство предполагает, что ты настроил n8n по нашему руководству по установке n8n с Docker Compose. Твой стек работает на Docker Compose с PostgreSQL, непривилегированным пользователем deploy и обратным прокси.
Какие данные хранит n8n и что нужно бэкапить?
n8n хранит пять компонентов, которые нужно бэкапить вместе. Если не хватает хотя бы одного, восстановление может быть частичным или невозможным. База PostgreSQL содержит воркфлоу, учётные данные (зашифрованные), историю выполнений и аккаунты пользователей. Ключ шифрования (encryption key) расшифровывает эти учётные данные. Docker-том хранит кастомные ноды и бинарные данные. Файлы .env и docker-compose.yml определяют конфигурацию запуска.
| Компонент | Содержимое | Риск при потере | Метод бэкапа |
|---|---|---|---|
| База PostgreSQL | Воркфлоу, зашифрованные учётные данные, история выполнений, пользователи | Все данные потеряны | pg_dump (формат custom) |
N8N_ENCRYPTION_KEY |
Ключ AES-256 для расшифровки учётных данных | Все сохранённые учётные данные становятся безвозвратно утраченными | Копия из .env или конфигурации контейнера |
Docker-том (.n8n) |
Кастомные ноды, бинарные данные выполнений | Кастомные ноды и загруженные файлы потеряны | Alpine tar-контейнер |
Файл .env |
Пароли БД, ключ шифрования, конфигурация домена | Нужно пересоздавать вручную | Копия файла |
docker-compose.yml |
Определения сервисов, маппинг томов, теги образов | Нужно пересоздавать вручную | Копия файла |
Как бэкапить базу PostgreSQL n8n с помощью pg_dump?
Используй pg_dump с --format=custom для создания сжатого восстанавливаемого дампа базы n8n. Формат custom поддерживает выборочное восстановление и параллельную обработку. Запускай дамп через работающий контейнер PostgreSQL.
docker exec n8n-postgres \
pg_dump -U n8n -d n8n --format=custom \
> /home/deploy/n8n-backups/n8n-db-$(date +%Y%m%d-%H%M%S).dump
Что делает эта команда: docker exec запускает pg_dump внутри контейнера PostgreSQL. -U n8n — пользователь базы. -d n8n — имя базы. --format=custom создаёт сжатый бинарный дамп, который pg_restore может восстанавливать выборочно. Вывод перенаправляется в файл с меткой времени на хосте.
Проверь, что дамп валидный:
cat /home/deploy/n8n-backups/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list | head -20
Поскольку pg_restore находится внутри контейнера PostgreSQL, дамп передаётся через пайп в docker exec -i. Ты должен увидеть список объектов базы (таблицы, последовательности, данные). Если видишь ошибку или пустой вывод — дамп не удался.
Бэкап Docker-тома
Том данных n8n содержит кастомные ноды и бинарные данные выполнений. Бэкапь его временным Alpine-контейнером:
docker run --rm \
-v n8n_n8n_data:/source:ro \
-v /home/deploy/n8n-backups:/backup \
alpine tar czf "/backup/n8n-data-$(date +%Y%m%d-%H%M%S).tar.gz" -C /source .
Имя тома n8n_n8n_data состоит из имени проекта Docker Compose (n8n, из директории) плюс имени тома (n8n_data, из docker-compose.yml). Запусти docker volume ls, если у тебя отличается.
Что делает эта команда: Монтирует том данных n8n в режиме только для чтения (:ro) в одноразовый Alpine-контейнер. Контейнер создаёт сжатый архив содержимого тома и записывает его в директорию бэкапов. Контейнер удаляется после завершения (--rm).
Проверь архив:
tar tzf /home/deploy/n8n-backups/n8n-data-*.tar.gz | head -10
Ты должен увидеть пути файлов из директории .n8n.
Бэкап конфигурационных файлов
BACKUP_DIR="/home/deploy/n8n-backups"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
cp /home/deploy/n8n/.env "$BACKUP_DIR/env-$TIMESTAMP.bak"
cp /home/deploy/n8n/docker-compose.yml "$BACKUP_DIR/docker-compose-$TIMESTAMP.yml.bak"
chmod 600 "$BACKUP_DIR/env-$TIMESTAMP.bak"
Файл .env содержит твой N8N_ENCRYPTION_KEY и пароль базы данных. Ограничь права до 600, чтобы только пользователь бэкапа мог его читать.
Почему ключ шифрования n8n — самый важный бэкап?
n8n шифрует каждый сохранённый credential (API-ключи, OAuth-токены, пароли баз данных) с помощью AES-256, используя N8N_ENCRYPTION_KEY. Если потеряешь этот ключ, каждый credential в базе станет безвозвратно утраченным. Механизма сброса нет. Бэкдора нет. Придётся вручную перевводить каждый credential в каждом воркфлоу.
Ключ либо задан явно в файле .env, либо автоматически сгенерирован n8n при первом запуске и сохранён в контейнере по пути /home/node/.n8n/config.
Найди свой ключ шифрования:
Если ты задал его в .env:
grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env
Если n8n сгенерировал его автоматически (ты никогда его явно не задавал):
docker exec n8n cat /home/node/.n8n/config
Ищи поле encryptionKey в JSON-выводе.
Сохрани ключ надёжно:
- Скопируй значение ключа в менеджер паролей (Bitwarden, KeePass, 1Password).
- Убедись, что он есть в файле
.envв видеN8N_ENCRYPTION_KEY=<твой-ключ>. - Скрипт бэкапа уже копирует
.env, но сохрани ключ и отдельно. Если сервер сгорит и бэкапы окажутся повреждёнными, ты всё равно сможешь восстановить credentials, если есть ключ.
Как автоматизировать бэкапы n8n через cron?
Объедини дамп базы, бэкап тома и копию конфигов в один скрипт. Добавь очистку по сроку хранения и пинг health check для отслеживания сбоев.
Создай скрипт бэкапа:
nano /home/deploy/n8n/backup-n8n.sh
#!/usr/bin/env bash
set -euo pipefail
# --- Configuration ---
BACKUP_DIR="/home/deploy/n8n-backups"
N8N_DIR="/home/deploy/n8n"
COMPOSE_PROJECT="n8n"
DB_CONTAINER="n8n-postgres" # Matches container_name in docker-compose.yml
DB_USER="n8n"
DB_NAME="n8n"
VOLUME_NAME="${COMPOSE_PROJECT}_n8n_data" # docker compose prefixes project name
RETENTION_DAYS=7
RETENTION_WEEKS=4
HEALTHCHECK_URL="" # Set to your healthcheck.io or uptime-kuma URL
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
DAY_OF_WEEK=$(date +%u)
mkdir -p "$BACKUP_DIR/daily" "$BACKUP_DIR/weekly"
# --- PostgreSQL dump ---
echo "[$(date)] Starting PostgreSQL backup..."
docker exec "$DB_CONTAINER" \
pg_dump -U "$DB_USER" -d "$DB_NAME" --format=custom \
> "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump"
# Verify dump is not empty
if [ ! -s "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump" ]; then
echo "[$(date)] ERROR: Database dump is empty!" >&2
exit 1
fi
# --- Docker volume backup ---
echo "[$(date)] Starting volume backup..."
docker run --rm \
-v "${VOLUME_NAME}:/source:ro" \
-v "$BACKUP_DIR/daily:/backup" \
alpine tar czf "/backup/n8n-data-$TIMESTAMP.tar.gz" -C /source .
# --- Config files ---
echo "[$(date)] Backing up config files..."
cp "$N8N_DIR/.env" "$BACKUP_DIR/daily/env-$TIMESTAMP.bak"
cp "$N8N_DIR/docker-compose.yml" "$BACKUP_DIR/daily/docker-compose-$TIMESTAMP.yml.bak"
chmod 600 "$BACKUP_DIR/daily/env-$TIMESTAMP.bak"
# --- Weekly copy (Sundays) ---
if [ "$DAY_OF_WEEK" -eq 7 ]; then
echo "[$(date)] Creating weekly backup copy..."
cp "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump" "$BACKUP_DIR/weekly/"
cp "$BACKUP_DIR/daily/n8n-data-$TIMESTAMP.tar.gz" "$BACKUP_DIR/weekly/"
cp "$BACKUP_DIR/daily/env-$TIMESTAMP.bak" "$BACKUP_DIR/weekly/"
fi
# --- Retention cleanup ---
echo "[$(date)] Cleaning old backups..."
find "$BACKUP_DIR/daily" -type f -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR/weekly" -type f -mtime +$((RETENTION_WEEKS * 7)) -delete
# --- Health check ping ---
if [ -n "$HEALTHCHECK_URL" ]; then
curl -fsS --retry 3 "$HEALTHCHECK_URL" > /dev/null
fi
echo "[$(date)] Backup complete."
Установи права и протестируй:
chmod 750 /home/deploy/n8n/backup-n8n.sh
/home/deploy/n8n/backup-n8n.sh
Проверь, что файлы бэкапа созданы:
ls -lh /home/deploy/n8n-backups/daily/
Обрати внимание на размеры файлов. Типичный дамп базы n8n весит от 500 КБ до 50 МБ в зависимости от истории выполнений. Если дамп 0 байт — что-то пошло не так.
Настройка cron
crontab -e
Добавь эту строку для запуска бэкапов каждый день в 03:00:
0 3 * * * /home/deploy/n8n/backup-n8n.sh >> /home/deploy/n8n-backups/backup.log 2>&1
Что делает эта команда: Запускает скрипт бэкапа каждый день в 3 часа ночи. Вывод и ошибки добавляются в backup.log для диагностики сбоев.
Оповещения о сбоях бэкапа
Переменная HEALTHCHECK_URL в скрипте поддерживает сервисы вроде Healthchecks.io или самохостовый инстанс Uptime Kuma. Эти сервисы ожидают пинг с определённым интервалом. Если пинг прекращается (потому что скрипт упал или cron не сработал), ты получишь уведомление.
Настрой проверку с периодом 24 часа и допуском в 1 час. Если скрипт бэкапа не пингнул до 04:00, ты получишь оповещение.
Как скопировать бэкапы n8n на другой сервер с помощью rclone?
Бэкапы на том же сервере, что и n8n — это не настоящие бэкапы. Если диск сдохнет, потеряешь и то, и другое. Используй rclone для копирования бэкапов в S3-совместимое объектное хранилище (Wasabi, Backblaze B2, MinIO или любой S3-провайдер).
Установи rclone:
sudo apt install rclone
Настрой удалённое хранилище. Этот пример использует любое S3-совместимое хранилище:
rclone config
Следуй интерактивным подсказкам для создания remote с именем n8n-backup. Выбери "Amazon S3 Compliant Storage Providers" и введи свой endpoint, ключ доступа и секретный ключ.
Проверь, что remote работает:
rclone lsd n8n-backup:
Ты должен увидеть свой бакет в списке.
Добавь синхронизацию в скрипт бэкапа. Вставь это перед строкой пинга health check:
# --- Off-server copy ---
echo "[$(date)] Syncing to remote storage..."
rclone sync "$BACKUP_DIR" n8n-backup:your-bucket-name/n8n \
--transfers 4 \
--min-age 1m \
--log-level ERROR
--min-age 1m не даёт загружать файлы, которые ещё записываются. --transfers 4 запускает четыре параллельных загрузки.
Как проверить валидность бэкапов n8n?
Бэкап, который ты ни разу не тестировал — это бэкап, которого у тебя нет. Запускай эти проверки регулярно.
Целостность дампа базы:
cat /home/deploy/n8n-backups/daily/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"
Целостность архива тома:
tar tzf /home/deploy/n8n-backups/daily/n8n-data-*.tar.gz > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"
Контрольные суммы для удалённой верификации:
Сгенерируй контрольные суммы после бэкапа:
sha256sum /home/deploy/n8n-backups/daily/* > /home/deploy/n8n-backups/daily/checksums.sha256
После загрузки с удалённого хранилища проверь:
sha256sum -c checksums.sha256
Каждая строка должна показать OK. Любое расхождение означает, что файл повредился при передаче.
Как восстановить n8n из бэкапа на чистом VPS?
Это процедура аварийного восстановления. Ты потерял сервер. У тебя есть чистый VPS и файлы бэкапов (из удалённого хранилища или локальной копии). Вот как вернуть n8n к жизни.
1. Развернуть новый VPS и установить Docker
Настрой VPS с Docker и Docker Compose. Следуй нашему руководству по установке n8n с Docker Compose до шага установки Docker, затем возвращайся сюда.
2. Создать пользователя deploy и директорию проекта
adduser --disabled-password deploy
mkdir -p /home/deploy/n8n /home/deploy/n8n-backups
chown deploy:deploy /home/deploy/n8n /home/deploy/n8n-backups
3. Скачать бэкапы
Из удалённого хранилища:
su - deploy
rclone copy n8n-backup:your-bucket-name/n8n/daily /home/deploy/n8n-backups/daily --progress
Или с другого сервера через scp:
scp user@old-server:/home/deploy/n8n-backups/daily/* /home/deploy/n8n-backups/daily/
4. Восстановить конфигурационные файлы
cp /home/deploy/n8n-backups/daily/env-*.bak /home/deploy/n8n/.env
cp /home/deploy/n8n-backups/daily/docker-compose-*.yml.bak /home/deploy/n8n/docker-compose.yml
chmod 600 /home/deploy/n8n/.env
Проверь, что ключ шифрования на месте:
grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env
Эта команда должна вернуть строку с твоим ключом. Если пусто или отсутствует — достань ключ из менеджера паролей и добавь вручную. Без этого ключа твои credentials потеряны.
5. Запустить только PostgreSQL
cd /home/deploy/n8n
docker compose up -d postgres
Подожди инициализацию PostgreSQL:
docker compose logs -f postgres
Ищи database system is ready to accept connections.
6. Восстановить базу данных
docker cp /home/deploy/n8n-backups/daily/n8n-db-*.dump n8n-postgres:/tmp/n8n.dump
docker exec n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists /tmp/n8n.dump
Что делает эта команда: Копирует файл дампа в контейнер, затем pg_restore загружает его. --clean удаляет существующие объекты перед восстановлением. --if-exists предотвращает ошибки, если объекты ещё не существуют.
Ты можешь увидеть предупреждения о несуществующих объектах. Это нормально для чистой базы. Ошибки, связанные с данными или ограничениями — не нормально.
7. Восстановить Docker-том
Docker Compose уже создал том n8n_n8n_data, когда ты запускал PostgreSQL на предыдущем шаге. Восстанови в него:
docker run --rm \
-v n8n_n8n_data:/target \
-v /home/deploy/n8n-backups/daily:/backup:ro \
alpine sh -c "tar xzf /backup/n8n-data-*.tar.gz -C /target"
8. Запустить весь стек
docker compose up -d
9. Проверить восстановление
docker compose ps
Все контейнеры должны показывать статус running.
Проверь логи n8n:
docker compose logs -f n8n
Ищи Editor is now accessible via: http://localhost:5678. Никаких ошибок ключа шифрования.
Открой веб-интерфейс n8n и проверь:
- Воркфлоу на месте и совпадают с тем, что было раньше.
- Credentials работают. Открой любой credential и убедись, что отображаются сохранённые значения (API-ключи, пароли). Если видишь пустые поля или ошибки расшифровки — ключ шифрования неправильный.
- Запусти тестовый воркфлоу. Выполни простой воркфлоу, чтобы убедиться, что подключение к базе и движок выполнения работают.
Проверь снаружи сервера:
curl -s https://your-n8n-domain.com/healthz
Ответ 200 подтверждает, что n8n доступен и работает.
Как безопасно обновить n8n через Docker Compose?
Обновление n8n состоит из четырёх шагов: бэкап, проверка release notes, загрузка нового образа, верификация. Никогда не пропускай шаг бэкапа.
1. Сделать бэкап
/home/deploy/n8n/backup-n8n.sh
Это обязательно. Если обновление что-то сломает, нужна точка восстановления.
2. Проверить release notes на breaking changes
Перед загрузкой новой версии прочитай release notes n8n. Обрати внимание на:
- Миграции базы данных (запускаются автоматически при старте, но могут занять время)
- Устаревшие ноды, которые используют твои воркфлоу
- Изменённые переменные окружения
- Минимальные требования к версии PostgreSQL
3. Записать текущую версию
docker compose exec n8n n8n --version
Запиши. Понадобится для отката.
4. Загрузить и перезапустить
Если твой docker-compose.yml использует тег n8nio/n8n:latest или n8nio/n8n:stable:
cd /home/deploy/n8n
docker compose pull
docker compose down
docker compose up -d
Если ты зафиксировал конкретную версию (рекомендуется для продакшена), сначала отредактируй docker-compose.yml:
services:
n8n:
image: n8nio/n8n:2.12.3 # Change to the target version
Затем:
docker compose up -d
5. Проверить обновление
docker compose exec n8n n8n --version
Убедись, что версия соответствует ожидаемой.
Проверь логи на ошибки миграции:
docker compose logs --tail 50 n8n
Ищи Migrations completed и Editor is now accessible via: http://localhost:5678.
Протестируй health-эндпоинт API:
curl -s https://your-n8n-domain.com/healthz
Запусти тестовый воркфлоу через интерфейс, чтобы убедиться, что выполнение работает.
Как откатить неудачное обновление n8n?
Если обновление ломает воркфлоу или интерфейс недоступен, откатись на предыдущую версию.
1. Остановить сломанный инстанс
cd /home/deploy/n8n
docker compose down
2. Установить предыдущий тег образа
Отредактируй docker-compose.yml и измени образ на предыдущую версию:
services:
n8n:
image: n8nio/n8n:2.11.2 # Your previous working version
3. Восстановить базу, если прошли миграции
Если n8n выполнил миграции базы во время неудачного обновления, схема могла измениться. Восстанови из бэкапа до обновления:
docker compose up -d postgres
docker cp /home/deploy/n8n-backups/daily/n8n-db-*.dump n8n-postgres:/tmp/n8n.dump
docker exec n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists /tmp/n8n.dump
4. Запустить старую версию
docker compose up -d
Проверь:
docker compose exec n8n n8n --version
docker compose logs --tail 20 n8n
Вот для чего мы делаем бэкап перед каждым обновлением. Без дампа до обновления безопасно откатиться после миграции не получится.
Как мигрировать n8n с версии 1.x на 2.x?
n8n 2.0 вышел в декабре 2025 с breaking changes. Если ты ещё на 1.x, мигрируй скорее. Версия 1.x получала только фиксы безопасности в течение трёх месяцев после выхода 2.0, и это окно уже закрылось.
Ключевые breaking changes в n8n 2.0
| Изменение | Поведение 1.x | Поведение 2.x | Требуемое действие |
|---|---|---|---|
| Поддержка MySQL/MariaDB | Поддерживается | Полностью удалена | Мигрируй на PostgreSQL до обновления |
| Task runners | Опционально | Включены по умолчанию, отдельный Docker-образ | Используй образ n8nio/runners для внешнего режима |
| Переменные окружения в Code node | Доступны | Заблокированы по умолчанию | Установи N8N_BLOCK_ENV_ACCESS_IN_NODE=false при необходимости |
| Start node | Работает | Удалён | Замени на конкретные триггер-ноды |
| Save vs. Publish | Save = deploy | Save и Publish — отдельные действия | Обнови командные воркфлоу |
| Python Code node | На Pyodide | Нативный Python через task runners | Используй task runners во внешнем режиме |
Ноды ExecuteCommand и LocalFileTrigger |
Включены | Отключены по умолчанию | Включи явно при необходимости |
CLI-опция --tunnel |
Доступна | Удалена | Используй обратный прокси |
N8N_CONFIG_FILES |
Поддерживается | Удалён | Используй переменные окружения напрямую |
Шаг 1: Запустить отчёт о миграции
Инструмент отчёта о миграции доступен начиная с n8n 1.121.0. Он находит проблемы на уровне воркфлоу и инстанса до обновления.
В интерфейсе n8n перейди в Settings > Migration Report. Пункт виден только глобальным администраторам.
Отчёт содержит две вкладки:
- Workflow Issues: Список воркфлоу с устаревшими нодами, удалёнными функциями или изменённым поведением.
- Instance Issues: Переменные окружения и конфигурация, которые нужно обновить.
Исправь каждую проблему из отчёта, прежде чем продолжать.
Шаг 2: Сначала обновить до последней 1.x
Перед прыжком на 2.x обновись до последней версии 1.x. Это гарантирует, что все промежуточные миграции базы выполнятся:
docker compose pull # With image set to n8nio/n8n:1-latest or latest 1.x tag
docker compose down && docker compose up -d
Шаг 3: Забэкапить всё
/home/deploy/n8n/backup-n8n.sh
Это твоя точка отката. Если 2.x сломает конфигурацию, можно восстановить этот бэкап и остаться на 1.x.
Шаг 4: Обновиться до 2.x
Отредактируй docker-compose.yml:
services:
n8n:
image: n8nio/n8n:stable # Or a specific 2.x version like 2.12.3
docker compose pull
docker compose down
docker compose up -d
Шаг 5: Проверить миграцию
docker compose logs --tail 100 n8n
Ищи завершённые миграции и отсутствие ошибок.
Протестируй воркфлоу, отмеченные отчётом о миграции. Открой credentials, чтобы убедиться, что расшифровка работает. Запусти несколько воркфлоу от начала до конца.
Если что-то сломано, откатись по процедуре из предыдущего раздела с бэкапом 1.x и тегом образа 1.x.
Устранение неполадок
pg_dump: error: connection to server failed
Контейнер PostgreSQL не запущен. Запусти его командой docker compose up -d postgres и подожди готовности перед запуском бэкапов.
Credentials пустые после восстановления
Твой N8N_ENCRYPTION_KEY не совпадает с тем, что использовался при сохранении credentials. Проверь файл .env. Сравни с ключом в менеджере паролей.
docker exec падает с "no such container"
Имена контейнеров зависят от имени директории проекта и compose-файла. Запусти docker ps, чтобы узнать реальное имя контейнера. Поправь переменную DB_CONTAINER в скрипте бэкапа.
Скрипт бэкапа выполняется, но healthcheck не пингует
Проверь, установлена ли HEALTHCHECK_URL в скрипте. Протестируй URL вручную: curl -fsS "your-healthcheck-url". Правила файрвола могут блокировать исходящий HTTPS.
n8n не запускается после обновления с ошибкой миграции
Проверь логи командой docker compose logs n8n. Если ошибка упоминает конкретную миграцию, поищи эту ошибку на форуме сообщества n8n. Откатись при необходимости.
rclone sync падает с ошибкой аутентификации
Запусти rclone config reconnect n8n-backup: для обновления учётных данных. Проверь, что ключ доступа и секретный ключ верны.
Где искать логи:
# n8n application logs
docker compose logs -f n8n
# PostgreSQL logs
docker compose logs -f postgres
# Backup script log
tail -f /home/deploy/n8n-backups/backup.log
# Cron execution log
grep CRON /var/log/syslog | tail -20
Авторское право 2026 Virtua.Cloud. Все права защищены. Данный контент является оригинальным произведением команды Virtua.Cloud. Воспроизведение, повторная публикация или распространение без письменного разрешения запрещены.
Готовы попробовать?
Разверните свой сервер за секунды. Linux, Windows или FreeBSD.
Смотреть тарифы VPS