VPS для Node.js: стабильный хостинг API и веб-приложений

Node.js отлично подходит для API, realtime и SSR. На VPS вы контролируете версию runtime, процессы и reverse proxy. Разбираем production-стек: NodeSource, PM2, nginx и мониторинг.

Почему Node.js на VPS, а не serverless

Serverless удобен для редких запросов, но при постоянном трафике VPS часто дешевле и предсказуемее. Вы не платите за каждый миллион invocations и cold start.

На VPS держите WebSocket, long polling и фоновые job без ограничений платформы. Express, NestJS, Fastify — всё работает как на локальной машине, только 24/7.

Фиксированная цена тарифа MAATRIX упрощает бюджет: 2 vCPU и 2 ГБ RAM хватит для типичного REST API с PostgreSQL на том же сервере.

Event loop Node.js однопоточен для JavaScript, но I/O асинхронный — поэтому один процесс обслуживает тысячи одновременных соединений, если код не блокирует loop тяжёлыми sync-операциями.

Версию Node фиксируйте в .nvmrc и CI — расхождение minor версии между build и runtime иногда ломает native addons.

Какой VPS выбрать

Минимум для API без SSR — 1 vCPU, 1 ГБ RAM. Next.js SSR или NestJS с TypeORM — 2 vCPU, 2–4 ГБ RAM: V8 и сборка проекта жадны к памяти.

NVMe-диск ускоряет npm ci и запись логов. Для production не экономьте на RAM: Node не прощает swap при пиках нагрузки.

• REST API — 1–2 vCPU, 1–2 ГБ RAM.
• SSR Next.js — 2 vCPU, 2–4 ГБ RAM.
• Socket.io + API — 2–4 vCPU, 4 ГБ RAM.

Для нескольких CPU ядер используйте PM2 cluster mode (-i max) или несколько systemd instances за nginx upstream — иначе второй core простаивает.

TypeScript в production на VPS: компиляция в dist/ на CI, на сервере только node dist/server.js — меньше devDependencies и поверхность атаки.

Установка Node.js LTS

Не используйте Node из стандартных репозиториев Debian — версия часто устаревшая. Подключите NodeSource или nvm под пользователя deploy:

curl -fsSL https://deb.nodesource.com/setup_22.x | bash -
apt install -y nodejs

Зафиксируйте версию в .nvmrc или engines в package.json. На production запускайте npm ci, а не npm install — reproducible builds.

Сборку (npm run build) делайте на CI или на VPS с достаточной RAM; runtime-образ может содержать только dist/ и node_modules --production.

Файловая система VPS на NVMe снижает latency при чтении шаблонов SSR и source maps в production debug сессиях.

NestJS modular architecture на одном VPS: один процесс держит HTTP и microservices через internal TCP если не нужен Kubernetes.

PM2 и systemd

PM2 — популярный process manager: cluster mode, автоперезапуск, логи. Альтернатива — чистый systemd unit без PM2 — меньше слоёв, нативные логи journalctl.

pm2 start dist/main.js --name api -i max
pm2 startup systemd
pm2 save

Restart=always в systemd unit поднимет процесс после OOM или ребута. EnvironmentFile для NODE_ENV=production и DATABASE_URL.

Graceful shutdown: обрабатывайте SIGTERM — закройте HTTP-сервер и connection pool перед exit, иначе деплой обрывает активные запросы.

Отдельный пользователь deploy владеет каталогом приложения — npm install не должен выполняться от root, иначе node_modules получают root ownership и ломают CI deploy.

Логирование pino или winston JSON в stdout — journald собирает без файловых дескрипторов на каждый worker.

nginx и WebSocket

nginx слушает 443, проксирует на 127.0.0.1:3000. Для WebSocket добавьте proxy_http_version 1.1 и заголовки Upgrade.

Rate limiting на nginx защищает API от простых DDoS и brute force без изменений в коде. SSL — certbot --nginx.

Статику Next.js (/_next/static) nginx может кэшировать с длинным expires — снижает нагрузку на Node при SSR.

Reverse proxy буферизует медленных клиентов: nginx принимает запрос быстро и отдаёт backend, освобождая worker Node для других соединений.

CORS и helmet middleware в Express — базовая HTTP security headers без nginx конфигурации для каждого header.

Секреты и мониторинг

JWT secrets, API keys — в .env с chmod 600, не в репозитории. dotenv на старте, в Docker — secrets или env_file.

Мониторинг: pm2 monit или node_exporter + Prometheus. Алерт при росте event loop lag — ранний признак блокирующего кода в async handlers.

Логируйте request id и latency p95 — без этого сложно понять, где тормозит API под реальной нагрузкой.

При росте трафика первым узким местом часто становится PostgreSQL, а не Node — мониторьте slow queries параллельно с CPU процесса node.

Типичные проблемы

• Блокировка event loop — sync crypto или fs в hot path.
• Утечки памяти — глобальные кэши без TTL.
• Нет graceful shutdown — обрыв запросов при деплое.
• npm install на prod — devDependencies и лишний риск.

Проверяйте NODE_ENV=production: без этого Express отдаёт stack traces и работает медленнее.

Telegram-алерт при падении systemd unit api.service — минимальная автоматизация, которую стоит настроить в первый день после деплоя.

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