Как Запустить Node.js на VPS

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

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

Этот счёт является причиной, по которой множество команд снова обращают внимание на VPS. Node.js сам по себе не волнует, где он работает. Единственное, от чего serverless защищал, это от необходимости узнать, что происходит после ‘npm start’.

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

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

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

В общем, есть три подходящих варианта:

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

И есть три неправильных подхода:

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

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

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

Миграция в основном занимает один день на ‘apt install,’ ‘pm2 start’ и изменение DNS.

Какие Характеристики VPS Необходимы Для Node.js?

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

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

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

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

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

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

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

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

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

Версия	Кодовое имя	Статус	Срок службы
Node.js 26.x	(нет)	Текущий	Переходит в LTS в конце 2026 года
Node.js 24.x	Криптон	Активный LTS	Апрель 2028
Node.js 22.x	Йод	Поддерживаемый LTS	Апрель 2027
Node.js 20.x	Железо	Снято с поддержки	Достиг срока службы 30 апреля 2026 года. Не использовать.

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

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

🤔Рассматриваешь Bun? Он быстрее в некоторых задачах и действительно впечатляет, но экосистема все еще меньше, а опыт использования в производстве короче, чем у 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

Перезагрузи свою Shell, затем установи Node 24:

nvm install 24
nvm use 24
nvm alias default 24

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

Глобальные установки обычно предназначены для инструментов командной строки уровня машины, таких как 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’	Обычно обрабатывается вручную с поэтапными перезапусками или несколькими единицами
Загрузка памяти (демон)	Небольшая загрузка демона	Нет (нет дополнительного демона)
Лучше всего подходит для	Одноузловая, JS-магазин, быстрая итерация	Много-приложений, комфорт команды операций

Быстрый старт 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 unit, так что настройка PM2 фактически использует systemd под капотом.

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

[Unit]
Description=Мой 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, где каждый мегабайт на счету, или отправляешь в операционную среду, где каждая другая служба — это systemd unit, и 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 является заголовком пошаговой передачи, поэтому при проксировании трафика WebSocket требуется явная обработка.

Оставь их, если твоё приложение использует WebSockets сейчас или может использовать в будущем. Socket.IO, подписки GraphQL через WebSockets и удивительно множество «обычных» функций в реальном времени зависят от этого обновления handshake.

Самая распространенная ошибка в продакшене, которую я наблюдаю в настройках 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 известно имя хоста.

Привязать Узел к 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 кэширует скомпилированные шаблоны представлений и возвращает более краткие ошибки в продакшене — в его собственной документации упоминается улучшение производительности вплоть до 3 раз. Установи переменную окружения ‘env var’ везде.
• Корректное завершение работы: Когда твой VPS перезагружается или PM2 отправляет ‘SIGTERM,’ твоему приложению даётся несколько секунд на обработку текущих запросов, закрытие соединений с базой данных и корректное завершение работы. Настрой обработчик ‘process.on(‘SIGTERM’, …)’. Стандартное время завершения работы в PM2 зависит от конфигурации и окружения, так что не полагайся на то, что у тебя всегда будет много времени на очистку.
• Ротация логов: Модуль ‘pm2-logrotate’ в PM2 обрабатывает это для PM2. Системный журнал обрабатывает это для прямых единиц systemd. Без ротации, твои логи заполнят диск примерно в четыре раза быстрее, чем ты ожидаешь.
• Дисциплина .env: Никогда не коммить секреты, никогда не записывай их в логи. Используй ‘dotenv’ для локальной разработки. В продакшене устанавливай переменные окружения через ‘Environment=’ в твоей единице systemd или в файле экосистемы PM2. Тот день, когда ты случайно сделаешь ‘console.log(process.env)’, станет днём, когда тебе придётся изменить каждый учётный элемент.
• Обратный прокси перед Node: Привяжи Node к localhost; пусть NGINX или Caddy обращаются к общедоступному интернету.
• Брандмауэр: UFW запрещает все, кроме 22, 80, 443. Перемещение SSH с порта 22 не остановит настойчивого атакующего, но значительно сократит количество автоматизированных попыток брутфорса и мусорных записей аутентификации.
• Мониторинг: Точка проверки работоспособности, которую инструмент мониторинга проверяет каждую минуту. У PM2 есть базовые встроенные функции. Для всего серьёзного используй Prometheus и Grafana, или воспользуйся сервисом мониторинга времени работы, например Better Stack или UptimeRobot. Ты хочешь знать, что твоё приложение не работает, прежде чем клиент тебе об этом скажет.

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

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

Когда VPS Не Подходит Для Node.js?

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

• Статические сайты и контент SSG: Экспорт Next.js, Astro, Gatsby и блог Eleventy. Платформы вроде Vercel, Netlify или Cloudflare Pages предоставляют глобально кэшированный хостинг статического контента, развертывание на базе Git и автоматическое перестроение «из коробки». Для чисто статического контента VPS обычно является излишней инфраструктурой.
• Разреженные, событийно-ориентированные нагрузки: Cloudflare Workers и AWS Lambda недороги для веб-хуков, работающих десять раз в день. 
• Реальные приложения, требующие 100,000+ одновременных подключений: Один VPS не масштабируется горизонтально. Вам потребуется оркестрация (Kubernetes, ECS, Nomad) или управляемая платформа реального времени вроде Ably или Pusher.
• Регулируемые нагрузки с высокими требованиями к соблюдению норм: HIPAA, PCI-DSS уровня 1, FedRAMP. Управляемая PaaS с встроенными сертификатами соответствия уменьшает боли аудита. Самостоятельное хостинг-соблюдение на VPS — это проект на несколько кварталов, который, вероятно, ты не захочешь.
• Нет уверенности в использовании Linux — и нет желания её развивать: Платформы вроде Render, Railway и DigitalOcean App Platform находятся где-то между чистым VPS-хостингом и полностью управляемым PaaS. Инструменты вроде Dokploy добавляют рабочие процессы развертывания в стиле Heroku поверх собственной инфраструктуры VPS. Ты всё ещё получаешь многие преимущества в стоимости и контроле, не требуя глубоких знаний iptables, внутренностей systemd или отладки обратного прокси в 1 час ночи.

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

Выбор Твоего Node Стека и Переезд

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

Ты собираешься заменить значительное количество этого одним счетом за VPS.

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

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

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

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

Часто Задаваемые Вопросы О Работе Node.js На VPS

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

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

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

Сколько RAM требуется Node.js на VPS?

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

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

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

Текущий активный LTS — это Node.js 24.x («Krypton»), который был представлен 28 октября 2025 года и будет поддерживаться до апреля 2028 года. Node.js 22.x («Jod») находится на этапе поддержки LTS до апреля 2027 года, если зависимость требует обратной совместимости. Node.js 26 запущен 5 мая 2026 года в качестве текущей версии и будет переведен в 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 использует один файл единицы на приложение.

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

Могу ли я запустить Node.js на Shared Hosting DreamHost?

Нет. Node.js требует постоянных процессов, установки пакетов на уровне root и прямого связывания портов, чего не предоставляет shared hosting. Самоуправляемые VPS-планы DreamHost (Stack 4 и выше) подходят для работы с Node с полным доступом root, хранением на NVMe и неограниченной пропускной способностью.