VPS для сайта: какую схему подготовить перед первым запуском
Тем, кто собрал сайт и хочет понять, нужен ли отдельный сервер
Минимальную схему VPS и список проверок до выкладки
7 мин
Сайт готов локально, но непонятно, где разместить приложение, базу и файлы
Понятна роль каждого компонента, доступ извне ограничен, копия данных проверена
Как выбрать границы первого VPS, разместить сайт и базу, проверить доступные порты, копии и безопасный запуск.
VPS для сайта нужен, когда приложение требует работающего процесса: серверный код, база, очередь задач или собственный способ запуска. Простая статическая страница может обойтись более простым размещением. Поэтому сначала выпишите состав проекта. Next.js с серверной частью, FastAPI и PostgreSQL требуют другой схемы, чем набор готовых HTML-файлов. После составления схемы можно выбирать тариф по реальным потребностям проекта.
В моём проекте patrikkyn.ru приложение Next.js работает за веб‑сервером nginx. Сам процесс слушает только локальный адрес 127.0.0.1: запрос из интернета сначала попадает на nginx, а тот передаёт его приложению. Это разделение позволяет закрыть служебный порт. На странице о выкладке сайта описан перенос готовой сборки; здесь разбираю устройство площадки и проверку границ перед первым запуском.
С чего начинается выбор сервера
Составьте список процессов: веб‑приложение, API, база, фоновые задачи, загрузки пользователей. Рядом отметьте, что должно пережить перезапуск. Код можно снова собрать из репозитория; база заказов и загруженные файлы требуют отдельной копии. Если весь проект держится на одном сервере, это допустимая первая схема для небольшого продукта, но ежедневная копия должна храниться за его пределами. Иначе поломка диска унесёт вместе с сайтом его «резерв».
Не выбирайте VPS по средней посещаемости из чужой статьи. Проверяйте требования собственного приложения и базовые наблюдения: хватает ли памяти при сборке, сколько занимает база, растёт ли диск после загрузок, сколько времени отвечает страница. Для первого запуска полезнее возможность расширить ресурсы и получить понятный доступ к журналам и копиям. Нагрузку измеряйте после начала реальной работы.
Перед выбором тарифа соберите наблюдения:
- запишите, сколько памяти занято во время сборки;
- проверьте размер базы и пользовательских файлов;
- измерьте время ответа главной страницы;
- выясните, куда уходят копии и как их вернуть.
Для небольшого Next.js сайта с базой начните с измерения памяти приложения, сборки и базы. Чужой пример по числу ядер здесь не поможет. Если сборка вытесняет рабочий процесс, собирайте её отдельно или выбирайте больше памяти. Диск считайте вместе с журналами, резервами и пользовательскими файлами. При росте нагрузки сначала найдите узкое место по метрикам, затем меняйте тариф или разделяйте компоненты.
| Компонент | Где находится | Что открыто извне | Что сохранять отдельно |
|---|---|---|---|
| nginx | На VPS перед приложением | HTTPS и, при необходимости, HTTP | Конфигурацию |
| Приложение | Процесс отдельного пользователя | Только локальный адрес | Код и переменные окружения |
| База данных | За закрытым портом | Ничего публичного | Ежедневную копию вне VPS |
| Файлы клиентов | Выделенная папка или хранилище | Только через приложение | Версии и копии файлов |
Короткая проверка границ VPS
Перед запуском пройдите небольшой чек‑лист. Полная настройка защиты описана отдельно, а порядок переноса сборки и проверки живого сайта есть в инструкции по выкладке.
- Процесс Next.js или FastAPI слушает
127.0.0.1; снаружи доступны только задуманные входы. Команда ниже показывает публичные слушающие сокеты. Проверьте также адрес назначения у каждого найденного порта. - Доступ к
.envесть только у своего пользователя службы. В systemd для службы указаныUser=этого пользователя иNoNewPrivileges=true. Секреты не попадают в клиентские переменныеNEXT_PUBLIC_. Команды проверки файла, истории Git и службы собраны в статье о.env. - Зависимости проверены до выкладки. Для Node и Python команды разные; сообщения о найденных проблемах надо разобрать до запуска.
- Контейнер с базой, если он нужен приложению на этом VPS, публикует порт локально как
127.0.0.1:5432:5432. Не полагайтесь только на правилоufw: публикация порта Docker требует отдельной проверки.
chmod 600 .env
systemctl show malyshev -p User
npm audit --omit=dev --audit-level=high
pip‑audit
ss -ltnH | grep -vE "127.0.0.1|::1"Команды аудита выполняйте в проекте соответствующего языка, а chmod в каталоге с нужным .env. В systemctl show замените malyshev именем своей службы: вывод User должен указывать на отдельного пользователя, не root. Если pip‑audit отсутствует, сначала установите его в своё Python-окружение. Вывод ss проверьте для всех интерфейсов, включая IPv6. При работе через SSH меняйте сетевые правила только сохранив способ вернуть доступ.
Как проверить копию, пока она не понадобилась
Сам факт запуска команды резервирования ещё не означает, что данные можно вернуть. Посмотрите дату последнего успешного архива, место хранения и размер. Затем восстановите копию в отдельном окружении и откройте пару записей. Для файлов загрузок проведите тот же опыт отдельно от базы: запись в таблице может указывать на файл, которого уже нет.
| Риск | Проверка | Действие до запуска |
|---|---|---|
| Архив хранится на том же VPS | Посмотреть путь хранения | Вынести копию за пределы сервера |
| Архив пуст или стар | Сверить размер и дату | Настроить сигнал о пропуске |
| База восстановилась без файлов | Открыть запись с вложением | Копировать папку загрузок отдельно |
| Доступ только у одного человека | Проверить процедуру восстановления | Описать роли и способ доступа |
В Radomir CRM копия PostgreSQL создаётся каждую ночь в 03:00 по cron на сервере, а Caddy автоматически продлевает HTTPS-сертификат. Это две разные задачи сопровождения: для базы важно проверять свежесть и восстановление копии, для HTTPS нужно видеть действующий сертификат после продления. Схема показывает, какие процессы должны жить на VPS помимо приложения, но не задаёт универсальный размер сервера.
Как принять решение о первом тарифе
Запишите фактическое потребление памяти, свободное место после сборки, размер базы и скорость роста файлов. Проверьте, переживают ли приложение и база перезапуск службы, а копия восстанавливается ли в отдельной среде. Если ресурсов хватает с запасом под обычный пик, первый тариф годится для проверки продукта. Если памяти не хватает уже на сборку или диск близок к заполнению, увеличьте ресурс либо вынесите сборку и файлы прежде, чем звать пользователей.
Решение о тарифе запишите в трёх строках:
- укажите самый тяжёлый процесс и его потребление;
- назовите ресурс, который закончится первым;
- назначьте момент повторного измерения после запуска.
После размещения проверка по домену и тестовая заявка покажут, работает ли внешний путь. Подробный порядок этой проверки есть в статье о выкладке сайта. Здесь главное решение другое: какие процессы, данные и копии серверу предстоит удерживать постоянно.
Частые вопросы
VPS нужен для сайта из одного HTML-файла?
Обычно нет. Если серверный процесс и база отсутствуют, достаточно размещения статических файлов с HTTPS.
Можно ли держать базу на том же VPS?
Для первого небольшого проекта это возможно при закрытом порте, правах доступа и проверенной внешней копии. Решение о разделении принимают по нагрузке и последствиям сбоя.
Зачем nginx, если приложение само отвечает по HTTP?
Он принимает публичные запросы и передаёт их локальному процессу. Так служебный порт приложения остаётся закрытым, а публичный вход управляется в одном месте.
Что важнее, число ядер или память?
Смотрите профиль своего приложения и результаты измерения. Если процесс падает при сборке из‑за нехватки памяти, дополнительные ядра не решат проблему.
Как понять, что копия действительно работает?
Восстановите её в отдельной среде и откройте записи и файлы. Без пробы восстановления это лишь архив неизвестного качества.
На обучении мы разбираем схему именно вашего проекта: что должно работать постоянно, какие данные сохранять и как проверить первую безопасную выкладку.