Деплой монорепозитория на один VPS

Фронт, API и воркер в одном репозитории — удобно разрабатывать, но нужно грамотно задеплоить. Развернём монорепо на VPS: соберём затронутые пакеты, запустим сервисы и разведём их по доменам nginx.

Почему монорепо и один VPS

Монорепозиторий (Turborepo, Nx, pnpm workspaces) держит фронт, бэкенд и общие пакеты вместе: единые версии, общий код, атомарные изменения. Разворачивать несколько сервисов из него удобно на одном VPS с root — вы сами решаете, что и где запускать.

Сборка монорепо — это тяжёлый Node-процесс с кэшем. NVMe + быстрые ядра AMD EPYC у MAATRIX ускоряют install и build, а на одном сервере можно поднять сразу фронт, API и воркеры без переплат за отдельные инстансы.

Типичная ошибка — размазывать монорепо по нескольким платным сервисам: фронт на одном хостинге, API на другом, воркер на третьем. Это дорого и усложняет деплой, ведь версии кода на сервисах расходятся. Один VPS с root решает задачу элегантно: вы клонируете репозиторий, собираете нужные пакеты и запускаете все процессы рядом, разводя их по портам и доменам. Для команд из России удобно и то, что зарубежный сервер оплачивается картой РФ, СБП, криптой или токеном MAAT.

Готовим сервер

curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt install -y nodejs nginx git
npm install -g pnpm pm2
pnpm -v && pm2 -v

Клонируем репозиторий и ставим зависимости всего воркспейса одной командой:

git clone https://github.com/USER/monorepo /opt/app
cd /opt/app
pnpm install --frozen-lockfile

Сборка только затронутого

Turborepo кэширует и собирает лишь изменённые пакеты — это резко ускоряет деплой:

pnpm turbo run build
# или собрать конкретные пакеты
pnpm turbo run build --filter=web --filter=api

Кэш Turborepo лежит в node_modules/.cache/turbo; на NVMe повторные сборки почти мгновенные. Флаг --filter позволяет собирать и деплоить только реально изменившиеся приложения — если правился лишь apps/api, нет смысла пересобирать фронт. В связке с CI это сокращает время релиза в разы.

Запуск сервисов через PM2

Опишем все процессы монорепо в одном ecosystem-файле /opt/app/ecosystem.config.js:

module.exports = {
  apps: [
    { name: 'web',    cwd: 'apps/web',    script: 'pnpm', args: 'start', env: { PORT: 3000 } },
    { name: 'api',    cwd: 'apps/api',    script: 'pnpm', args: 'start', env: { PORT: 4000 } },
    { name: 'worker', cwd: 'apps/worker', script: 'pnpm', args: 'start' }
  ]
};

Один ecosystem-файл описывает все процессы монорепо: PM2 поднимет их разом, будет следить за падениями и рестартить. Флаги cwd и env задают рабочую директорию и порт для каждого приложения, чтобы сервисы не конфликтовали. Запускаем всё и включаем автостарт после ребута:

cd /opt/app
pm2 start ecosystem.config.js
pm2 save
pm2 startup systemd

nginx-роутинг и частые ошибки

Разводим сервисы по доменам: фронт на основном домене, API на поддомене. nginx слушает 443 и проксирует на локальные порты, которые наружу закрыты файрволом — публично торчит только сам nginx.

server {
    listen 443 ssl http2;
    server_name example.com;
    location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; }
}
server {
    listen 443 ssl http2;
    server_name api.example.com;
    location / { proxy_pass http://127.0.0.1:4000; proxy_set_header Host $host; }
}

nginx -t && systemctl reload nginx

• pnpm install падает по памяти — добавьте swap или используйте --frozen-lockfile и больший тариф.
• Сервис не стартует после ребута — забыли pm2 save и pm2 startup.
• Конфликты портов — задавайте PORT в env каждого приложения явно.

Для нулевого даунтайма при релизе используйте pm2 reload ecosystem.config.js вместо restart — PM2 перезапускает процессы по очереди, не обрывая обслуживание. Один VPS от MAATRIX держит весь монорепо-стек, а ежедневные бэкапы фиксируют состояние сервера перед каждым релизом.

Частые вопросы