Разместить обычный сайт на PHP относительно просто: загружаем файлы на хостинг, создаем базу данных, указываем домен — и в большинстве случаев проект уже можно запускать. С Node.js все немного интереснее. Приложение представляет собой постоянно работающий процесс, которому может потребоваться определенная версия Node.js, установка npm-пакетов, переменные окружения, собственный порт, доступ к базе данных и возможность автоматически перезапуститься после сбоя.
Поэтому первый попавшийся виртуальный хостинг для Node.js подойдет далеко не всегда. Одни провайдеры вообще не позволяют запускать Node-приложения, другие предлагают такую возможность с ограничениями, третьи предоставляют практически готовое окружение. А если проекту нужен полный контроль над системой, обычно начинают смотреть в сторону VPS.
При этом арендовать виртуальный сервер для любого небольшого приложения тоже необязательно. Простой сайт, API, Telegram-бот или небольшой сервис могут прекрасно работать в более простом окружении, если хостинг предоставляет все необходимые функции.
Выбор зависит не столько от самого Node.js, сколько от приложения. Небольшой backend для личного проекта и сервис с WebSocket, базой данных, очередями задач и тысячами одновременных подключений используют одну технологию, но требуют совершенно разной инфраструктуры.
Разберемся, какой хостинг выбрать для Node.js, можно ли использовать обычный виртуальный тариф, зачем нужны SSH и npm, что делать с постоянно работающим процессом, когда понадобится VPS и на какие характеристики сервера действительно стоит смотреть.
Чем хостинг для Node.js отличается от обычного хостинга сайтов
Чтобы понять разницу, полезно сначала посмотреть, как работает привычный PHP-сайт.
Посетитель отправляет запрос. Веб-сервер передает его PHP, выполняется необходимый код, формируется ответ, после чего выполнение конкретного запроса заканчивается. Управлением PHP-процессами и веб-сервером занимается инфраструктура хостинга.
Node.js-приложение обычно работает иначе.
Разработчик запускает приложение, например сервер на Express, и процесс продолжает работать, ожидая новые запросы. Если процесс остановить, приложение перестанет отвечать.
Отсюда появляется первое важное требование к хостингу: он должен не просто «поддерживать JavaScript», а позволять запускать серверные Node.js-процессы.
JavaScript в браузере и Node.js на сервере — совершенно разные вещи с точки зрения размещения.
Практически любой хостинг способен отдавать посетителю файл script.js. Это еще ничего не говорит о возможности запустить на сервере Express, NestJS или другое Node.js-приложение.
Поэтому фраза «поддержка JavaScript» в характеристиках тарифа не должна вводить в заблуждение.
Нужна именно поддержка Node.js.
Второе отличие — зависимости.
Современное Node-приложение редко состоит из одного файла. Используются библиотеки и фреймворки, которые устанавливаются через npm, pnpm или Yarn. Информация о зависимостях проекта обычно находится в package.json и lock-файле.
Следовательно, серверное окружение должно позволять устанавливать необходимые пакеты.
Третья особенность — версия Node.js.
Проект может нормально работать на одной версии среды выполнения и не запускаться на другой. Особенно это актуально для старых приложений или зависимостей.
Поэтому хороший хостинг для Node.js позволяет выбрать подходящую версию и впоследствии обновить ее без сложного переноса проекта.
Четвертая особенность — переменные окружения.
В них обычно хранят конфигурацию приложения, адрес базы данных, режим работы, ключи различных сервисов и другие параметры, которые не стоит жестко записывать непосредственно в исходный код.
Хостинг должен предоставлять удобный и безопасный способ задавать такие значения.
И наконец, Node-приложению нужно корректно связаться с внешним миром. Оно может слушать внутренний порт, а запросы с обычных HTTPS-портов передаются к нему через инфраструктуру хостинга или reverse proxy.
На специализированной платформе значительную часть этой работы выполняет провайдер. На VPS настраивать ее приходится самостоятельно.
Можно ли разместить Node.js на обычном виртуальном хостинге
Можно, если конкретный провайдер это поддерживает.
Само понятие виртуального хостинга не означает, что там обязательно доступен только PHP. Современные панели и инфраструктура некоторых хостеров позволяют создавать Node.js-приложения непосредственно внутри обычного аккаунта.
Такой вариант может быть очень удобен для небольшого проекта.
Пользователь получает привычную панель управления, домен, SSL, резервные копии и другие функции обычного хостинга, но дополнительно может выбрать версию Node.js, указать каталог приложения и запустить его.
Для небольшого сайта или API это избавляет от необходимости администрировать собственный сервер.
Но перед оплатой тарифа нужно выяснить, что провайдер понимает под «поддержкой Node.js».
Возможности сильно различаются.
Где-то доступно полноценное создание приложения через панель. Где-то Node.js можно запускать только через SSH. Где-то существуют ограничения на продолжительность или количество процессов. А у некоторых хостеров упоминание Node.js относится вообще к VPS, хотя пользователь может принять его за характеристику обычного тарифа.
Поэтому лучше заранее проверить документацию или спросить поддержку.
Что проверить у виртуального Node.js-хостинга
В первую очередь посмотрите доступные версии Node.js. Желательно, чтобы провайдер поддерживал несколько актуальных версий и позволял переключаться между ними.
Затем выясните, как устанавливаются зависимости.
Есть ли SSH? Можно ли выполнять npm install? Поддерживаются ли необходимые вашему проекту инструменты?
Уточните, как запускается приложение и что произойдет после его падения.
Это один из ключевых вопросов.
Если процесс завершился из-за ошибки, сайт не должен оставаться недоступным до тех пор, пока владелец случайно не заметит проблему и вручную не запустит его снова.
Проверьте работу с переменными окружения, собственными доменами и HTTPS.
Если проект использует WebSocket, обязательно выясните его поддержку отдельно. То, что обычные HTTP-запросы работают, еще не гарантирует подходящую конфигурацию для длительных соединений.
То же самое относится к фоновым процессам.
Некоторые приложения одновременно обслуживают веб-запросы и выполняют дополнительные задачи. На shared-хостинге возможности для такой архитектуры могут быть ограничены.
И наконец, узнайте ресурсные лимиты.
Node.js не требует какого-то магического количества процессорных ядер или памяти, но приложение должно укладываться в ограничения конкретного тарифа.
Если провайдер практически ничего не сообщает о лимитах, имеет смысл уточнить их до переноса рабочего проекта.
Когда для Node.js лучше сразу выбрать VPS
VPS дает значительно больше свободы.
Вы получаете виртуальную машину, на которой можно установить подходящую операционную систему, Node.js нужной версии, Nginx, базу данных, менеджер процессов, Docker и практически любые другие необходимые компоненты.
Это особенно удобно для нестандартных приложений.
Например, проект состоит не только из веб-сервера, но и из отдельного worker-процесса. Используется Redis. Работает очередь задач. Нужен WebSocket. Есть собственная база данных. Требуется определенная конфигурация Nginx.
На обычном хостинге каждый такой пункт приходится сверять с ограничениями платформы. На VPS инфраструктуру можно построить под проект.
Но собственный сервер — это не бесплатная свобода.
Кто-то должен его администрировать.
Нужно обновлять операционную систему и пакеты, закрывать ненужные порты, настраивать firewall, следить за журналами, контролировать свободное место, делать резервные копии и реагировать на сбои.
Если разработчик умеет это делать, VPS дает отличную гибкость.
Если нет, дешевый неуправляемый сервер способен создать больше проблем, чем специализированный Node.js-хостинг.
Для коммерческого проекта можно рассмотреть управляемый VPS, где часть системного администрирования берет на себя провайдер.
VPS нужен не из-за самого Node.js
Иногда можно встретить утверждение, что для Node.js обязательно нужен VPS. Это слишком категорично.
Сервер нужен не технологии как таковой, а конкретному приложению.
Простому Express-сайту может хватить специализированного виртуального хостинга. Сложному сервису с несколькими процессами и собственной инфраструктурой VPS действительно будет намного удобнее.
Поэтому выбирать тип размещения нужно по архитектуре проекта.
Если все необходимые функции доступны на обычном хостинге и приложение укладывается в его лимиты, переплачивать и заниматься серверным администрированием необязательно.
Если ограничения платформы начинают определять архитектуру приложения, это уже хороший повод рассмотреть VPS.
Как обычно запускают Node.js-приложение на VPS
После аренды чистого VPS одного копирования исходного кода недостаточно.
Сначала необходимо подготовить серверное окружение.
На сервер устанавливается Node.js подходящей версии. Затем проект загружается через Git, SFTP или другим способом, устанавливаются зависимости и задаются необходимые переменные окружения.
После этого приложение можно запустить.
Но оставлять производственный сервис в виде обычной команды вроде node app.js не лучшая идея.
Если процесс завершится из-за ошибки или сервер перезагрузится, приложение должно автоматически восстановить работу.
Для управления Node.js-процессами часто используют PM2 или системный менеджер systemd.
Их задача — контролировать процесс и при необходимости запускать его снова.
Снаружи приложение обычно не выставляют напрямую на произвольном порту.
Перед ним может находиться Nginx, который принимает запросы пользователей и передает их Node.js-приложению.
Такую схему называют reverse proxy.
Например, пользователь открывает обычный адрес сайта по HTTPS. Nginx принимает соединение на стандартном порту и внутри сервера передает запрос приложению, работающему на своем локальном порту.
Это позволяет централизованно работать с HTTPS, доменами, заголовками и другими функциями веб-сервера.
Конкретная архитектура может отличаться. Современные платформы иногда полностью скрывают этот слой от пользователя. Но для владельца VPS полезно понимать общую логику.
PM2 не является обязательной частью Node.js
PM2 часто упоминают в инструкциях по размещению Node.js, поэтому у новичка может возникнуть ощущение, что без него приложение не работает.
Это не так.
Node.js способен запускать программу самостоятельно. PM2 решает другую задачу — помогает управлять работающими процессами, перезапускать их и следить за состоянием.
Альтернативой может быть systemd или другая система управления процессами.
Для специализированного хостинга пользователь вообще может не видеть ни PM2, ни systemd: платформа сама занимается жизненным циклом приложения.
Поэтому наличие PM2 не стоит использовать как главный критерий выбора хостинга. Важнее конечный результат: приложение должно стабильно работать и автоматически восстанавливаться после перезапуска инфраструктуры или сбоя процесса.
Сколько процессора и оперативной памяти нужно Node.js
Ответ зависит от приложения.
Сам Node.js не определяет необходимую конфигурацию сервера.
Можно написать небольшой API, который использует очень мало памяти и практически не нагружает процессор. А можно создать на Node.js тяжелый сервис обработки данных, которому потребуется значительно больше ресурсов.
Поэтому универсальные таблицы вида «сайт на Node.js — 2 ГБ, магазин — 4 ГБ, большой проект — 8 ГБ» мало полезны.
Нужно смотреть на то, что делает программа.
Node.js особенно хорошо известен событийной моделью и неблокирующим вводом-выводом. Это делает его удобным для приложений, которые обрабатывают большое количество сетевых операций.
Но это не означает бесконечную производительность.
Если приложение выполняет тяжелые вычисления непосредственно в основном потоке, процессор становится очень важным ограничением.
Если хранит большие объемы данных в памяти, возрастает потребность в RAM.
Если постоянно взаимодействует с базой, производительность СУБД может стать главным узким местом, хотя сам Node.js будет использовать относительно немного ресурсов.
Если приложение активно работает с диском, важна производительность хранилища.
Именно поэтому для существующего проекта лучший способ определить требования — измерять фактическое потребление.
Смотрите среднюю и пиковую загрузку CPU, память, время ответа, состояние базы данных и количество одновременных соединений.
После этого сервер можно увеличивать осмысленно, а не покупать ресурсы наугад.
База данных для Node.js-приложения
Node.js не привязан к одной конкретной базе данных.
Проект может использовать PostgreSQL, MySQL, MariaDB, MongoDB, Redis и другие системы в зависимости от задачи.
База может находиться на том же VPS, что и приложение, на отдельном сервере или предоставляться как управляемая услуга.
Для небольшого проекта размещение приложения и базы на одной виртуальной машине часто является самым простым вариантом.
Но нужно помнить, что они будут делить ресурсы.
Если VPS имеет определенный объем оперативной памяти, она нужна не только Node.js. Ее используют операционная система, база данных, Nginx и другие службы.
Поэтому нельзя выбирать конфигурацию, считая, что вся RAM достанется приложению.
По мере роста проекта базу можно вынести отдельно. Это позволяет масштабировать ее независимо от веб-приложения и лучше изолировать разные виды нагрузки.
Но усложнять инфраструктуру заранее тоже нет необходимости.
Для маленького сайта несколько отдельных серверов чаще создадут дополнительные расходы и точки отказа, чем дадут практическую пользу.
Главное — не забывать о резервном копировании данных.
Копия исходного кода не является резервной копией приложения, если важные пользовательские данные находятся в базе.
Express, NestJS, Next.js и другие Node.js-проекты требуют разного подхода
Фраза «сайт на Node.js» может скрывать совершенно разные приложения.
Простой сервер на Express может принимать HTTP-запросы и работать как небольшой API.
NestJS часто используется для более структурированных backend-приложений.
Next.js способен работать в разных режимах. Часть проекта может быть статической, а часть требовать серверного выполнения Node.js.
Поэтому нельзя выбирать хостинг только по названию фреймворка.
Нужно понимать способ развертывания конкретного проекта.
Если после сборки получается набор статических HTML, CSS и JavaScript-файлов, требования к размещению могут быть очень простыми.
Если используется серверный рендеринг, API-маршруты и другая серверная логика, понадобится полноценное Node.js-окружение.
То же самое относится к другим современным фреймворкам.
Перед покупкой хостинга полезно открыть документацию проекта и понять, какой именно deployment предполагается.
Это защищает от ситуации, когда тариф формально «поддерживает JavaScript», но не способен запустить нужный режим приложения.
WebSocket, боты и фоновые задачи требуют отдельной проверки
Обычный веб-сайт получает запрос, отвечает и завершает взаимодействие. Некоторые Node.js-приложения работают иначе.
WebSocket позволяет поддерживать длительное двустороннее соединение между клиентом и сервером. Это используется в чатах, системах уведомлений, совместной работе, онлайн-панелях и других интерактивных сервисах.
Если проект использует WebSocket, поддержку таких соединений нужно проверять у хостинга отдельно.
На собственном VPS необходимые параметры можно настроить самостоятельно. На виртуальном хостинге или платформе пользователь зависит от возможностей провайдера.
Похожая ситуация с ботами.
Например, программа может постоянно ожидать новые события или периодически выполнять определенную работу. Для нее нужен стабильный процесс или подходящий механизм запуска.
Обычный тариф, рассчитанный преимущественно на обработку коротких PHP-запросов, не всегда позволяет держать произвольный процесс постоянно запущенным.
Фоновые задачи также бывают разными.
Простую периодическую операцию иногда достаточно запускать через Cron. Более сложному приложению могут понадобиться отдельные worker-процессы и очередь задач.
Если архитектура проекта предполагает несколько постоянно работающих компонентов, VPS или подходящая облачная платформа обычно дают больше свободы.
Что важнее для Node.js скорость диска или процессора
Зависит от характера нагрузки.
Это звучит менее эффектно, чем универсальный совет «берите только NVMe», зато ближе к реальности.
Для приложения, которое в основном принимает запросы и обращается к внешнему API, локальный диск может играть сравнительно небольшую роль.
Для сервиса, который интенсивно работает с локальной базой или большим количеством файлов, дисковая подсистема становится гораздо важнее.
Современный SSD или NVMe в любом случае предпочтительнее старых медленных накопителей для большинства серверных задач.
Но одна характеристика не определяет качество всего сервера.
Очень быстрый диск не компенсирует слабый процессор в вычислительно тяжелом приложении. Большое количество CPU не исправит медленный внешний API. Огромный объем RAM не ускорит плохо написанный запрос к базе данных.
Поэтому сервер нужно рассматривать как систему.
Для VPS имеет значение и то, как провайдер распределяет физические ресурсы между виртуальными машинами. Красивые характеристики на бумаге еще не всегда означают одинаковую фактическую производительность.
Если проект важен для бизнеса, реальное тестирование на выбранной инфраструктуре полезнее попыток сравнить серверы исключительно по рекламным таблицам.
Как организовать HTTPS и домен для Node.js
Пользователь не должен вводить адрес вроде example.ru:3000 только потому, что приложение работает на определенном внутреннем порту.
Нормальный сайт открывается через стандартный домен по HTTPS.
На специализированном Node.js-хостинге привязка домена и выпуск SSL обычно выполняются через панель.
Пользователь указывает домен, настраивает DNS, а платформа сама направляет запросы к приложению.
На VPS этим занимается администратор.
Часто используется Nginx, который принимает внешние запросы и передает их Node.js-процессу.
SSL-сертификат сегодня не должен быть существенной статьей расходов для обычного проекта. Бесплатные сертификаты позволяют организовать HTTPS без покупки коммерческого сертификата, если у сайта нет специфических требований.
Гораздо важнее автоматическое продление.
Сертификат, который однажды настроили и забыли продлить, способен неожиданно сделать сайт недоступным для нормальной работы пользователей.
Поэтому процесс обновления сертификата лучше автоматизировать.
Развертывание через Git и автоматическое обновление приложения
Загружать файлы Node.js-проекта вручную через файловый менеджер можно, но для разработки это далеко не самый удобный процесс.
Код обычно хранится в Git-репозитории.
На простом VPS разработчик может подключиться по SSH, получить новую версию проекта, установить изменившиеся зависимости, выполнить сборку и перезапустить приложение.
Это уже значительно удобнее ручного копирования файлов.
Следующий уровень — автоматизация развертывания.
После внесения изменений в основную ветку система сама запускает необходимые проверки, собирает проект и развертывает новую версию.
Для маленького личного сайта полноценный CI/CD может быть избыточен. Для команды и регулярно обновляемого приложения автоматизированный процесс снижает количество ручных действий и вероятность ошибок.
Некоторые специализированные платформы предоставляют Git deployment сразу. Пользователь подключает репозиторий, а сервис самостоятельно собирает и запускает приложение.
Это одно из преимуществ платформенного хостинга перед чистым VPS: меньше системного администрирования.
Но за удобство обычно приходится платить либо более высокой ценой, либо меньшей свободой конфигурации.
Нужен ли Docker для Node.js
Docker полезен, но не обязателен.
Небольшое приложение прекрасно может работать непосредственно на VPS без контейнеризации.
Docker становится интереснее, когда нужно обеспечить воспроизводимое окружение, приложение состоит из нескольких сервисов или разработчики хотят одинаково запускать проект локально и на сервере.
Контейнер может включать приложение и необходимые зависимости, что упрощает перенос между окружениями.
Но Docker добавляет собственный уровень сложности.
Его нужно понимать, обновлять образы, контролировать контейнеры, сети, volumes и хранение данных.
Поэтому использовать контейнеризацию только потому, что она популярна, необязательно.
Для простого Node.js-сайта связка Node.js, systemd или PM2 и Nginx может быть понятнее и легче в обслуживании.
Если приложение уже разработано под Docker или инфраструктура состоит из нескольких связанных сервисов, поддержка контейнеров становится важным критерием выбора площадки.
На обычном виртуальном хостинге возможность самостоятельно запускать Docker обычно ограничена. VPS предоставляет гораздо больше свободы.
Безопасность Node.js-сервера
Если используется специализированный хостинг, значительную часть безопасности инфраструктуры обеспечивает провайдер.
На собственном VPS ответственность заметно возрастает.
Сервер нужно регулярно обновлять.
Ненужные сетевые службы лучше не оставлять доступными из интернета. Для SSH стоит использовать надежную аутентификацию и ограничить возможности входа.
Секретные ключи, пароли баз данных и токены нельзя хранить в публичном Git-репозитории.
Для этого и используются переменные окружения или специализированные системы управления секретами.
Следить нужно и за npm-зависимостями.
Современное Node.js-приложение может использовать большое дерево сторонних пакетов. Их необходимо обновлять осмысленно и контролировать известные проблемы безопасности.
При этом автоматическое обновление всех зависимостей до любых новых версий без тестирования тоже может сломать приложение.
Правильнее сочетать контроль уязвимостей с тестированием обновлений.
Отдельная тема — права приложения.
Node.js-процессу не нужно предоставлять больше системных возможностей, чем требуется для работы. Запускать веб-приложение с максимальными правами просто ради удобства — плохая практика.
И конечно, HTTPS защищает передачу данных между пользователем и сервером, но не заменяет безопасность самого приложения. Уязвимый API не станет безопасным только благодаря SSL-сертификату.
Резервные копии для Node.js нужно продумывать заранее
Backup Node.js-приложения зависит от его архитектуры.
Если весь исходный код хранится в Git, потеря копии файлов на сервере может быть не самой серьезной проблемой. Код можно снова развернуть из репозитория.
Гораздо важнее пользовательские данные.
Если приложение использует базу данных, нужна ее резервная копия.
Если пользователи загружают фотографии, документы или другие файлы непосредственно на сервер, их тоже необходимо сохранять.
Если данные находятся во внешнем объектном хранилище, стратегия резервирования будет другой.
Поэтому кнопка «ежедневный backup VPS» полезна, но не освобождает разработчика от понимания того, где находятся критичные данные.
Для важного проекта желательно иметь резервную копию за пределами самого сервера.
Если основной VPS потерян полностью, архив на том же виртуальном диске мало поможет.
Полезно периодически проверять и восстановление.
Сам факт существования файла backup еще не доказывает, что из него получится быстро вернуть приложение в рабочее состояние.
Когда Node.js-приложению становится мало одного сервера
Большинство проектов никогда не столкнутся с этой проблемой. И это нормально.
Один хороший VPS способен обслуживать значительную нагрузку, особенно если приложение оптимизировано.
Не нужно строить кластер из нескольких серверов для проекта, у которого несколько десятков посетителей в день.
Но по мере роста может возникнуть ситуация, когда вертикального масштабирования становится недостаточно или оно становится слишком дорогим.
Тогда приложение можно запускать в нескольких экземплярах и распределять запросы между ними.
Появляется балансировщик нагрузки.
База данных может переехать на отдельную инфраструктуру. Статические файлы — в объектное хранилище. Изображения и другой контент — раздаваться через CDN.
Фоновые задачи можно вынести в отдельные worker-процессы.
Но это уже архитектура высоконагруженного проекта, а не обязательный стандарт для Node.js.
Одна из распространенных ошибок — проектировать инфраструктуру под воображаемые миллионы пользователей, которых пока нет.
Каждый дополнительный сервис нужно обслуживать, контролировать и оплачивать.
Гораздо разумнее иметь понятную возможность масштабирования и использовать ее тогда, когда реальные показатели покажут необходимость.
Что проверить перед покупкой хостинга для Node.js
Для начала определите тип проекта.
Это обычный сайт? REST API? Backend мобильного приложения? Telegram-бот? WebSocket-сервис? Серверный рендеринг? Несколько фоновых процессов?
После этого требования становятся гораздо понятнее.
Если рассматривается виртуальный или специализированный Node.js-хостинг, я бы проверила следующее:
- какие версии Node.js доступны;
- можно ли самостоятельно переключать версию;
- есть ли SSH-доступ;
- можно ли устанавливать npm-зависимости;
- как запускается приложение;
- как выполняется автоматический перезапуск процесса;
- можно ли задавать переменные окружения;
- поддерживаются ли собственные домены;
- как подключается HTTPS;
- поддерживается ли WebSocket, если он нужен;
- можно ли запускать фоновые процессы;
- доступен ли Cron;
- какие ограничения CPU и памяти действуют;
- какие базы данных доступны;
- можно ли подключаться к внешней базе данных;
- есть ли Git deployment;
- как создаются резервные копии;
- можно ли скачать backup;
- что происходит при превышении ресурсов;
- как перейти на более мощный тариф.
При выборе VPS список немного меняется.
Здесь Node.js практически наверняка можно установить самостоятельно, поэтому на первый план выходят процессор, RAM, диск, сеть, виртуализация, резервные копии, масштабирование и качество инфраструктуры провайдера.
Не забудьте учесть администрирование.
Цена VPS в месяц — еще не полная стоимость владения сервером, если для его обслуживания приходится нанимать специалиста.
Какой хостинг для Node.js выбрать в итоге
Начинать выбор стоит не с вопроса «сколько гигабайт нужно Node.js», а с архитектуры приложения.
Если проект небольшой и провайдер предоставляет полноценную поддержку Node.js на виртуальном хостинге, такой вариант может оказаться самым простым. Не нужно администрировать операционную систему, настраивать веб-сервер и самостоятельно следить за всей инфраструктурой.
Главное — проверить, что поддержка Node.js реальная, а не формальная.
Нужны подходящая версия среды выполнения, установка зависимостей, постоянный запуск приложения, переменные окружения, домен, HTTPS и необходимые именно вашему проекту функции.
Для нестандартного или растущего приложения VPS дает намного больше свободы.
На нем можно самостоятельно настроить Node.js, Nginx, PM2 или systemd, базу данных, Redis, Docker и другие компоненты. Но одновременно появляется ответственность за безопасность и обслуживание сервера.
Не существует универсального минимального объема RAM для любого Node.js-проекта.
Смотрите на фактическую нагрузку. Для существующего приложения измеряйте процессор, память, время ответа, состояние базы и пиковые периоды.
Не забывайте, что узким местом может быть не Node.js. Приложение способно ждать медленную базу данных, сторонний API или дисковую операцию. Увеличение CPU в таком случае не обязательно даст заметный результат.
Если используются WebSocket, постоянно работающие боты, очереди или отдельные worker-процессы, проверяйте поддержку этих сценариев заранее. Именно на них чаще проявляются ограничения простого виртуального хостинга.
Для коммерческого проекта обязательно продумайте резервное копирование. Исходный код можно повторно получить из Git, а потерянную пользовательскую базу данных восстановить намного сложнее.
И не усложняйте инфраструктуру раньше времени.
Небольшому приложению не нужны пять серверов, Kubernetes и отдельный кластер базы данных только потому, что теоретически когда-нибудь появится большая аудитория.
Хорошая инфраструктура для Node.js — не самая сложная, а та, которая соответствует текущей нагрузке и позволяет без болезненной переделки расти дальше.
Для одного проекта это будет виртуальный хостинг с полноценной поддержкой Node.js. Для другого — VPS. Для быстро растущего сервиса — облачная платформа и несколько отдельных компонентов.
Главное, чтобы площадка не заставляла приложение бороться с ограничениями хостинга и при этом не заставляла владельца оплачивать и обслуживать инфраструктуру, которая ему пока совершенно не нужна.
