Node.js на VPS: настройка PM2, systemd, NGINX и Let's Encrypt

Heroku убил свой бесплатный тариф и поднял нижнюю планку. Vercel взимает плату за каждое рабочее место и устанавливает тайм-ауты для длительных задач. Render и Railway масштабируют цену в зависимости от трафика.

Откройте последний счет от вашего хостинг-провайдера. Node-приложение, база данных Postgres и кэш Redis. Три строки, три набора предупреждений о превышении лимитов, один лихорадочный тред в Slack в тот день, когда маркетинг наконец запускает кампанию.

Именно из-за этого счета многие команды снова присматриваются к VPS. Node.js сам по себе не заботится о том, где он работает. Единственное, от чего вас защищал serverless, — это необходимость узнать, что происходит после «npm start».

Давайте рассмотрим шаблон production-конфигурации для Node.js на Linux-боксе, которым вы управляете. Если вы умеете подключаться по SSH к серверу и читать конфигурационные файлы, к концу статьи у вас будет production-стек, который может работать годами при затратах на обслуживание в пару часов в месяц.

Когда имеет смысл запускать Node.js на VPS?

VPS — правильный выбор для Node.js, когда у вас есть длительный процесс, стек, который вы хотите объединить в один счет, или счет за управляемый рантайм, который превысил удобство.

В целом есть три подходящих сценария:

• Длительные процессы: WebSocket-серверы, обработчики очередей, планировщики cron, MCP-серверы. Все, что должно оставаться запущенным и слушающим. Большинство serverless-платформ по-прежнему оптимизированы под короткие выполнения и жизненные циклы запросов. Node-процесс на VPS просто работает.
• Консолидация затрат: Node-приложение, Postgres, Redis и небольшой сборщик — все живут на одном 4 ГБ боксе. Одна строка в счете, а не четыре.
• Приложения, которые переросли PaaS: Тайм-ауты функций при длительной генерации PDF. Посадочная тарификация для команды, которая наконец наняла четвертого разработчика. Счет Heroku, переваливающий за 60 долларов в месяц за нагрузку, которая отлично работает на VPS за 15 долларов.

И есть три неподходящих сценария:

• Статические сайты и контент SSG: Экспорт из Next.js, сборка Astro, блог на Gatsby. Бесплатный тариф Vercel — правильный инструмент. VPS — это избыточно.
• Разреженные, событийно-ориентированные нагрузки: AWS Lambda или Cloudflare Workers стоят копейки для вебхука, который запускается десять раз в день. VPS стоит одинаково, занято приложение или спит.
• Горизонтально масштабируемые real-time приложения: Если вашему WebSocket-серверу нужно обслуживать 100 000 одновременных соединений, один VPS — не решение. Здесь нужен кластер Kubernetes, распределенная edge-инфраструктура или управляемая real-time платформа.

JavaScript — самый используемый язык в Опрос разработчиков Stack Overflow за 2025 год, и Node.js остается одним из основных способов запуска JavaScript на серверной стороне. Это много людей, запускающих Node где-то. Эта статья для тех из них, кому было бы удобнее запускать его на собственном сервере.

Я видел, как команды переносили четыре production-приложения Node с Heroku на один VPS объемом 4 ГБ, с тем же аптаймом, втрое меньшим счетом и долгоживущими WebSocket'ами, которые наконец работали без обходных путей.

Миграция — это в основном полдня «apt install», «pm2 start» и изменение DNS.

Какие характеристики VPS реально нужны Node.js?

Сам Node.js легковесен. Минимальный Express-сервер может простаивать, потребляя значительно меньше 100 МБ резидентной памяти. Совет «Node нужно всего 1 ГБ», который вы все еще найдете в старых блогах, технически верен, но практически бесполезен. К тому моменту, как вы добавите Postgres, Redis, логи и процесс развертывания, который держится не только на надежде, в тихий день вы уже выйдете за этот предел.

Реалистичные размеры для типичных нагрузок:

Нагрузка	ОЗУ	vCPU	Хранилище	Примечания
Небольшой Express API, без БД на боксе	2 ГБ	1–2	40 ГБ NVMe	Реалистичный минимум для одного production-приложения
Node API + Postgres + Redis на одном боксе	4 ГБ	2	80 ГБ NVMe	Золотая середина; большинство команд выбирают это
Тяжелое SSR-приложение (Next.js, Nuxt, Remix)	8 ГБ	4	80 ГБ NVMe	SSR-рендеринг и пайплайны сборки — вот куда уходит память
Real-time/WebSocket приложение, умеренный масштаб	8 ГБ	4	80 ГБ NVMe	Каждое постоянное соединение потребляет память

Несколько конкретных моментов, которые нужно уточнить перед выделением ресурсов:

• NVMe-накопители важнее, чем сырой объем диска: Современные Node-приложения работают с тысячами маленьких файлов во время установки, сборки и запуска. Медленные диски заметно ухудшают установку зависимостей, холодный запуск и пересборку SSR.
• Виртуализация KVM, а не OpenVZ: Старые планы на OpenVZ используют общее ядро с хостом, что может означать устаревшие версии ядра и периодические проблемы совместимости с новыми рантаймами. Большинство надежных VPS-провайдеров теперь используют только KVM, но это все равно стоит проверить.
• Swap-пространство: Включите 1–2 ГБ свопа на небольших боксах. V8-куча Node может сильно колебаться во время сборки мусора. Без свопа кратковременный всплеск убивает процесс. Я наблюдал, как 4 ГБ бокс получал Out Of Memory (OOM) во время обычного развертывания, потому что кто-то отключил своп, думая, что это анахронизм эпохи Docker.
• Пропускная способность: Большинство современных VPS-планов включают 1–4 ТБ трафика в месяц, чего достаточно почти для всего, кроме размещения видеоконтента. Тарифные планы Self-Managed VPS включают безлимитный трафик, что на одну строку меньше в таблице планирования емкости.

VPS на 4 ГБ стоит около 15 долларов в месяц по рыночной цене. Это 50 центов в день, или примерно одна чашка кофе в аэропорту раз в две недели. По сравнению с отдельной оплатой рантаймов приложений, управляемых Postgres и Redis на PaaS, экономия оказывается удивительно быстрой.

Какую версию Node.js следует установить?

Установите Node.js 24 (кодовое имя Krypton). Это текущий Active LTS-релиз, переведенный в LTS в октябре 2025 года и поддерживаемый до апреля 2028 года согласно официальному графику релизов Node.js.

Многие руководства до сих пор указывают на Node 22. Эти руководства не обновлялись. Если вы начинаете новое развертывание сегодня, зафиксируйте ваш CI-образ и VPS на Node 24.x.

Версия	Кодовое имя	Статус	Окончание поддержки (EOL)
Node.js 26.x	(нет)	Current	Переход в LTS в конце 2026
Node.js 24.x	Krypton	Active LTS	Апрель 2028
Node.js 22.x	Jod	Maintenance LTS	Апрель 2027
Node.js 20.x	Iron	End-of-life |	Достиг EOL 30 апреля 2026. Не использовать.

Несколько эмпирических правил:

• Не запускайте Current (не-LTS) релизы в production: Node 26 существует для тестирования будущей совместимости и новых функций рантайма, а не для приложения, от которого зависит ваш доход.
• Node 22 — запасной вариант, если критическая зависимость еще не догнала совместимость с Node 24: Большая часть экосистемы стабилизировалась в течение нескольких месяцев после перехода в LTS.
• Фиксируйте версию Node везде: Ваш CI-образ, Dockerfile, .nvmrc и production VPS должны совпадать. «Работает на моей машине» быстро становится дорогим, когда в дело вступают нативные модули.

🤔Думаете о Bun? Он быстрее на некоторых нагрузках и действительно впечатляет, но экосистема все еще меньше, а история работы в production короче, чем у Node. Для большинства команд побеждает проверенное решение.

NodeSource, поддерживающая репозитории apt и yum, из которых многие продакшн-команды устанавливают Node, выделяет улучшения в линейке 24.x, начиная с более новой версии движка V8. Node 24 также поставляется с уже зрелыми инструментами, такими как встроенный node –watch и стабильный встроенный тестовый раннер (node: test), оба из которых стабилизировались в версиях 20–22 и перенесены сюда. Ничего кричащего. Это просто снимает небольшую операционную нагрузку каждый месяц.

Как установить Node.js на VPS?

У вас есть два реалистичных пути установки. Выбор зависит от того, работает ли на сервере одно приложение Node или несколько.

NodeSource для сервера с одним приложением

Это самый простой способ для продакшна. Один установочный скрипт и одна команда apt install дадут вам текущую LTS-линейку Node 24 в качестве системного пакета, а будущие обновления безопасности будут приходить через обычные обновления пакетов.

На Ubuntu или Debian:

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

Проверьте установку:

node -v
npm -v

Вы должны увидеть версию Node 24.x.

Инструкции для дистрибутивов семейства RHEL (yum/dnf) находятся в официальном репозитории дистрибутивов NodeSource.

nvm для переключения версий в рамках проекта

nvm (Node Version Manager) устанавливает Node в ваш домашний каталог и позволяет разным проектам использовать разные версии Node. Полезно, если вы размещаете несколько приложений на одном сервере или у вас нет доступа к sudo.

Запустите это от имени пользователя приложения, а не root:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash

Перезагрузите вашу оболочку, затем установите Node 24:

nvm install 24
nvm use 24
nvm alias default 24

👉Одно важное правило: Не используйте sudo ‘npm install -g’ для зависимостей приложения.

Глобальные установки обычно предназначены для системных CLI-инструментов, таких как pm2, typescript или nodemon. Зависимости вашего приложения должны находиться в package.json и устанавливаться из каталога проекта с помощью npm ci.

NodeSource	nvm
Одна версия Node на сервер	Несколько версий Node на сервер
Устанавливается системно, может запускаться любым пользователем	Устанавливается для каждого пользователя
Автоматические обновления через ‘apt’	Управление вручную
Требует sudo	Не требует sudo

Если вы не уверены, начните с NodeSource. Большинству однозадачных продакшн-серверов не нужно переключение версий Node для каждого проекта.

👉Пользователям DreamHost Self-Managed VPS: Приложение Node, доступное при развертывании, поставляется с Node 22 LTS — поддерживается до апреля 2027 года. Чтобы запустить Node 24, используйте шаги для NodeSource или nvm после развертывания.

Стоит ли использовать PM2 или systemd для поддержания работы вашего приложения?

Подойдет любой вариант. Честный ответ — тот, с которым вашей команде удобнее. PM2 — это путь для разработчиков. systemd — это нативный путь Unix. Оба решают одни и те же три проблемы: перезапуск при сбое, запуск при загрузке и корректное завершение по сигналу 'SIGTERM'.

Если вы начинаете с нуля, вот как выбрать:

	PM2	systemd
Время настройки	3 минуты	10 минут
Кластерный режим (многоядерность)	Встроен	Не встроен (запуск N юнитов)
Ротация логов	Модуль: ‘pm2-logrotate’	Встроена через ‘journalctl’
Перезагрузка без даунтайма	‘pm2 reload’	Обычно выполняется вручную с помощью rolling restarts или нескольких юнитов
Накладные расходы памяти (демон)	Небольшие накладные расходы на демон	Нет (нет дополнительного демона)
Лучше всего подходит для	Одноплатформенные серверы, JS-команды, быстрая итерация	Серверы с множеством приложений, комфорт для ops-команды

Быстрый старт PM2 именно такой, быстрый:

npm install -g pm2
pm2 start app.js --name api
pm2 startup    # выводит команду запуска systemd для выполнения
pm2 save       # сохраняет текущий список процессов

После этого PM2 становится единственным инструментом, с которым вы работаете: 'pm2 logs', 'pm2 reload api', 'pm2 monit'.

👉Также стоит знать: Команда 'pm2 startup' создает systemd-юнит, так что настройка PM2 фактически использует systemd под капотом.

Минимальный systemd-юнит для прямого управления Node в '/etc/systemd/system/api.service':

[Unit]
Description=My Node API
After=network.target

[Service]
Type=simple
User=app
WorkingDirectory=/var/www/api
ExecStart=/usr/bin/node server.js
Restart=on-failure
RestartSec=5
Environment=NODE_ENV=production
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
Затем 'systemctl enable --now api'. Логи находятся в 'journalctl -u api -f'.

Если у вас уже работает PM2 и все функционирует, не мигрируйте на systemd только потому, что кто-то на Hacker News так сказал. Потребление памяти демоном PM2 — не причина для миграции.

Мигрируйте, когда появится реальная причина, например, запуск полудюжины Node-процессов, где важен каждый мегабайт, или при развертывании в среде ops, где каждый другой сервис является systemd-юнитом, а PM2 выделяется как чужеродный элемент.

Как разместить NGINX (или Caddy) перед вашим Node-приложением?

Вам нужен обратный прокси перед Node по пяти причинам: терминация HTTPS, сжатие gzip/brotli, раздача статических файлов, запуск нескольких приложений на одном сервере и более простое ограничение скорости. Node может делать все это. NGINX и Caddy делают это лучше, и они не загружают ваш цикл событий, когда что-то идет не так.

Выбирайте NGINX, если кто-то в вашей команде уже с ним знаком. Выбирайте Caddy, если хотите HTTPS в три строки конфигурации и вас устраивает меньшая экосистема расширенных настроек.

Минимальная конфигурация NGINX

Поместите этот блок прокси в /etc/nginx/sites-available/api, создайте симлинк в sites-enabled, затем выполните nginx -t && systemctl reload nginx.

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        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_cache_bypass $http_upgrade;
    }
}

Заголовки 'Upgrade' и 'Connection' — это строки поддержки WebSocket. Документация NGINX отмечает, что Upgrade является заголовком типа hop-by-hop, поэтому его нужно явно обрабатывать при проксировании WebSocket-трафика.

Оставьте их, если ваше приложение использует WebSocket сейчас или может использовать в будущем. Socket.IO, подписки GraphQL через WebSocket и удивительное количество "обычных" функций реального времени зависят от этого рукопожатия Upgrade.

Самая распространенная продакшн-ошибка, которую я вижу в Node-настройках — это сервер Socket.IO за NGINX без этих двух строк. Соединения нестабильно обрываются, разработчики винят Socket.IO, а реальная проблема обычно в конфигурации прокси.

Минимальный Caddyfile

Версия того же самого из краткого руководства по обратному прокси Caddy:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Это весь файл. Пока домен указывает на сервер и порты 80/443 доступны, Caddy автоматически предоставляет и обновляет HTTPS. В документации Caddy сказано, что автоматическое предоставление HTTPS выдает TLS-сертификаты для сайтов и поддерживает их обновление; в кратком руководстве по обратному прокси также отмечается, что HTTPS автоматический, когда Caddy знает имя хоста.

Привяжите Node к localhost, а не к 0.0.0.0

Какой бы прокси вы ни выбрали, настройте ваше Node-приложение на прослушивание 127.0.0.1:3000, а не 0.0.0.0:3000. Единственное, что должно быть обращено к публичному интернету на сервере с Node, — это прокси. Сочетайте это с UFW, стандартным фаерволом Ubuntu, чтобы запретить всё, кроме портов 22, 80 и 443.

ufw default deny incoming
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Если SSH работает на нестандартном порту, разрешите этот порт перед включением UFW.

Привязывайтесь к localhost с самого начала. Встреча, на которой кто-то признается: «приложение было раскрыто, потому что Node привязался к 0.0.0.0» — это не та встреча, на которой вы хотите оказаться.

Как настроить HTTPS для вашего Node.js приложения?

Используйте Let’s Encrypt. Он бесплатный, автоматизированный и доверенный всеми браузерами. Есть два пути, в зависимости от того, какой прокси вы выбрали.

NGINX + Certbot

Направьте A-запись на IP вашего VPS и дождитесь распространения DNS.

Установите Certbot:

apt install certbot python3-certbot-nginx

Запустите:

certbot --nginx -d api.example.com

Certbot обновляет вашу конфигурацию NGINX и автоматически перезагружает сервер.

На современных версиях Ubuntu таймер systemd, установленный пакетом Certbot, автоматически обрабатывает обновление.

Откройте https://api.example.com и убедитесь, что есть значок замка.

В официальной документации Certbot также описан способ установки через snap, если пакет вашего дистрибутива устарел.

Caddy

Добавьте домен в Caddyfile (в примере выше он уже есть), затем перезапустите Caddy. Пока домен правильно разрешается и порты 80/443 доступны, сертификат будет предоставлен автоматически при первом запуске. Certbot не нужен.

Не завершайте TLS в самом Node для продакшена.

Модуль https в Node работает отлично, но обратные прокси, такие как NGINX и Caddy, специально созданы для завершения TLS. Они предоставляют OCSP stapling, современные шифры по умолчанию, автоматическое обновление сертификатов, поддержку HTTP/2 и — в случае Caddy — поддержку HTTP/3 из коробки.

Могли бы вы обработать всё это непосредственно в Node? Конечно. Вы бы просто перестраивали инфраструктуру, которую ваш прокси уже отлично решает.

Как на самом деле выглядит готовая к продакшену настройка Node.js?

Восемь вещей, которые подводят людей в продакшене. Большинство из них отсутствует в руководствах по установке, потому что они не вписываются в сценарий «установи Node, запусти приложение». Это разница между приложением, которое переживает второй месяц, и тем, которое нет.

• NODE_ENV=production: Самый часто пропускаемый шаг. Во многих фреймворках и библиотеках Node он отключает поведение только для разработки и включает оптимизации для продакшена. Express, например, кэширует скомпилированные шаблоны представлений и возвращает более краткие ошибки в продакшене — его собственная документация указывает на улучшение производительности до 3x. Установите эту переменную окружения везде.
• Graceful shutdown (Плавное завершение): Когда ваш VPS перезагружается или PM2 отправляет SIGTERM, у вашего приложения есть несколько секунд, чтобы завершить текущие запросы, закрыть соединения с базой данных и аккуратно завершиться. Подключите обработчик process.on('SIGTERM', …). Время завершения по умолчанию в PM2 зависит от конфигурации и окружения, так что не предполагайте, что у вас всегда будет много времени на очистку.
• Log rotation (Ротация логов): Модуль pm2-logrotate обрабатывает это для PM2. Журнал systemd обрабатывает это для прямых юнитов systemd. Без ротации ваши логи съедят диск за четверть ожидаемого времени.
• .env discipline (Дисциплина .env): Никогда не коммитьте секреты, никогда не логируйте их. Используйте dotenv для локальной разработки. В продакшене устанавливайте переменные окружения через Environment= в юните systemd или в файле экосистемы PM2. В день, когда вы случайно сделаете console.log(process.env), вы будете менять все учетные данные.
• A reverse proxy in front of Node (Обратный прокси перед Node): Привяжите Node к localhost; пусть NGINX или Caddy смотрят в публичный интернет.
• A firewall (Фаервол): UFW запрещает всё, кроме 22, 80, 443. Перенос SSH с порта 22 не остановит решительного атакующего, но резко сокращает автоматический брутфорс и мусор в логах аутентификации.
• Monitoring (Мониторинг): Эндпоинт проверки здоровья, который ваш инструмент мониторинга проверяет каждую минуту. У PM2 есть встроенные основы. Для серьезных вещей запустите Prometheus и Grafana или используйте хостинговый сервис аптайма, такой как Better Stack или UptimeRobot. Вы хотите узнать, что ваше приложение упало, до того, как вам скажет клиент.

Оценка обслуживания для вышеуказанного стека: от одного до трех часов в месяц.

Обновления apt, периодическое обновление зависимостей и ежеквартальный просмотр объема логов. Это плата за экономию и контроль.

Когда VPS — неправильный выбор для Node.js?

VPS — неправильный выбор, когда ваша нагрузка создана для чего-то другого. Будьте честны с собой, на какой вы стороне, прежде чем выделять ресурсы.

• Static sites and SSG content (Статические сайты и SSG-контент): Next.js export, Astro, Gatsby и блог на Eleventy. Платформы, такие как Vercel, Netlify или Cloudflare Pages, предоставляют глобально кэшированный статический хостинг, развертывание на основе Git и автоматическую пересборку из коробки. VPS обычно является излишней инфраструктурой для чисто статического контента.
• Sparse, event-driven workloads (Разреженные, событийно-ориентированные нагрузки): Cloudflare Workers и AWS Lambda недороги для вебхуков, запускающихся десять раз в день.
• Real-time apps that need 100,000+ concurrent connections (Реалтайм-приложения, которым нужно 100 000+ одновременных подключений): Один VPS не масштабируется горизонтально. Вам понадобится оркестрация (Kubernetes, ECS, Nomad) или управляемая реалтайм-платформа, такая как Ably или Pusher.
• Compliance-heavy regulated workloads (Нагрузки с высокими требованиями к соответствию): HIPAA, PCI-DSS Level 1, FedRAMP. Управляемый PaaS со встроенными сертификатами соответствия избавляет от головной боли при аудите. Самостоятельное размещение с соответствием требованиям на VPS — это проект на несколько кварталов, который вам, вероятно, не нужен.
• No Linux comfort — and no appetite to build it (Нет комфорта с Linux — и нет желания его обретать): Платформы, такие как Render, Railway и DigitalOcean App Platform, находятся где-то между сырым VPS-хостингом и полностью управляемым PaaS. Инструменты, такие как Dokploy, добавляют workflow развертывания в стиле Heroku поверх вашей собственной VPS-инфраструктуры. Вы все еще получаете много преимуществ в стоимости и контроле, не углубляясь в iptables, внутренности systemd или отладку обратного прокси в час ночи.

Нет ничего постыдного ни в одном из этих ответов. Лучшее техническое решение — то, которое соответствует вашей нагрузке.

Выбираем стек Node и заселяемся

Откройте этот счет за хостинг еще раз.

Вы собираетесь заменить значительную его часть одним счетом за VPS.

👉Стек: Ubuntu 24.04 LTS, Node 24, PM2 (или systemd), NGINX (или Caddy), Let’s Encrypt через Certbot (или встроенный в Caddy).

Запустите самый маленький тариф VPS, который попадает в нужный вам объем ОЗУ, установите Node, запустите приложение на «127.0.0.1», укажите на него NGINX и переключите DNS.

Если приложение переживет развертывание, перезагрузку и ночную работу без происшествий, вы почти у цели.

Остальное — обслуживание. Час-два в месяц, периодическое окно «apt upgrade», ежеквартальное обновление зависимостей. Такова сделка, которую вы заключили, когда обменяли счет за каждого пользователя на фиксированный, и Self-Managed VPS Stack 4 от DreamHost — это то, с чего вы можете начать.

Часто задаваемые вопросы о запуске Node.js на VPS

Можно ли запустить Node.js на любом VPS?

Большинство современных VPS-тарифов без проблем работают с Node.js. Современные KVM-тарифы с 64-битным дистрибутивом Linux — самый безопасный выбор для актуальных версий Node.js.

Старые тарифы на базе OpenVZ иногда имеют ограничения ядра, которые ломают новые версии Node. Если вы выбираете между провайдерами, уточните, используют ли они KVM.

Сколько оперативной памяти нужно Node.js на VPS?

Минимальный сервер Express потребляет менее 100 МБ в простое, но реалистичное продакшн-приложение с промежуточным ПО, логированием и пулом соединений обычно работает в диапазоне 150–300 МБ.

Реалистичный минимум для одного продакшн-приложения — 2 ГБ; оптимальный объем для стека Node + Postgres + Redis — 4 ГБ. DreamHost Self-Managed VPS Stack 4 (4 ГБ) справляется с большинством рабочих нагрузок Node. Для приложений с тяжелым SSR или реальным временем переходите на Stack 8 (8 ГБ).

Какая текущая LTS-версия Node.js?

Текущая активная LTS — Node.js 24.x («Krypton»), выпущена 28 октября 2025 года и поддерживается до апреля 2028 года. Node.js 22.x («Jod») находится в режиме сопровождения LTS до апреля 2027 года, если для обратной совместимости требуется зависимость. Node.js 26 вышла 5 мая 2026 года как Current и будет переведена в LTS в октябре 2026 года.

Большинство продакшн-команд придерживаются LTS-релизов, если им не нужны новые функции среды выполнения.

Нужен ли PM2, если у меня есть systemd?

Нет, оба не нужны. PM2 и systemd решают одну и ту же задачу: поддержание работы Node-приложения при сбоях и перезагрузках. Многие команды, работающие с Node, выбирают PM2 из-за встроенной кластеризации, управления логами и инструментов перезагрузки.

Команды, уже использующие systemd для всего остального, выбирают systemd.

Зачем ставить NGINX перед Node.js?

NGINX (или Caddy) перед Node.js централизует завершение TLS, сжатие, обслуживание статических файлов и ограничение скорости в программном обеспечении, специально разработанном для проксирования и веб-обслуживания.

Это также позволяет запускать несколько Node-приложений на одном VPS без конфликтов портов. В продакшене Node слушает на localhost; NGINX обращен к публичному интернету.

Дешевле ли Node.js на VPS, чем Heroku или Vercel?

Да, часто. VPS на 4 ГБ обычно стоит где-то $15–25 в месяц по рыночным ценам и может объединить расходы на среду выполнения приложения, базу данных и кэш, которые на многих PaaS-платформах выставляются отдельно.

Ценообразование Vercel Pro зависит от количества мест, а бессерверные платформы по-прежнему накладывают ограничения на время выполнения в зависимости от среды выполнения и тарифа.

Компромисс в том, что вы занимаетесь эксплуатацией самостоятельно — примерно от одного до трех часов в месяц.

Можно ли запустить несколько Node-приложений на одном VPS?

Да, и это самая распространенная причина, по которой команды переходят с PaaS на VPS. Запустите каждое приложение на своем внутреннем порту (3000, 3001, 3002) и маршрутизируйте трафик с помощью серверных блоков NGINX по имени хоста. PM2 управляет всеми ими как отдельными процессами; systemd использует один unit-файл на приложение.

VPS на 4 ГБ часто может справиться с несколькими легковесными Node-сервисами вместе с небольшой рабочей нагрузкой базы данных.

Можно ли запустить Node.js на общем хостинге DreamHost?

Нет. Node.js требует постоянных процессов, установки пакетов на уровне root и прямого привязки портов, чего нет на общем хостинге. Тарифы Self-Managed VPS от DreamHost (Stack 4 и выше) подходят для рабочих нагрузок Node с полным root-доступом, NVMe-накопителями и безлимитным трафиком.