Выгруженный из Roboweb проект — обычное приложение на Next.js с Prisma и PostgreSQL, без привязки к платформе. Хостить его можно где угодно, и как раз поэтому встаёт вопрос, где именно. Экспорт кода доступен на платном тарифе, на пробном его нет. В статье — требования проекта к площадке, три варианта размещения с их плюсами и ценой обслуживания, честный ответ про GitHub Pages и чек-лист переезда, который стоит пройти до первого реального пользователя.
Что нужно выгруженному проекту
Экспорт — это проект Next.js (App Router) с Prisma и PostgreSQL. Из этого следуют требования к площадке:
- Node.js в версии, которую поддерживает Next.js 15: в package.json указаны next ^15, react ^19, prisma и @prisma/client ^6.
- PostgreSQL. Один экспорт — одна база данных.
- Переменная окружения DATABASE_URL. Шаблон лежит в файле .env.example.
- Скрипты сборки и запуска. build выполняет prisma generate и next build, start запускает сервер, db:push разворачивает схему через prisma db push.
Серверная часть живёт в маршрутах app/api: регистрация и сессии посетителей, запись и чтение данных по таблицам с правами доступа, серверные функции, оформление заказа. Сессии хранятся в базе, их токен — в httpOnly-cookie; попытки регистрации и входа ограничены по частоте. Подробный разбор файлов — в статье что внутри экспорта.
Важная оговорка из README: безопасность «из коробки» — это каркас, а не production-grade. Перед продом нужны HTTPS, доверенный reverse-proxy и периодическая чистка просроченных сессий. Это требования к самостоятельному размещению, то есть к вариантам 2 и 3 ниже.
Вариант 1: оставить проект в облаке сервиса
Самый простой путь — не переезжать. Облачный хостинг с SSL и публикация по ссылке есть уже на пробном тарифе, свой домен подключается на платных тарифах. Когда выбирать между адресом по ссылке и своим доменом, разобрано в статье про свой домен и публикацию по ссылке.
Плюсы: не нужно администрировать сервер, продукт продолжает развиваться правками в редакторе.
Минусы: меньше контроля над инфраструктурой; если разработчику нужно менять код руками, делать это придётся в выгруженном проекте.
Кому подходит: MVP, лендингам, каталогам и порталам на этапе, когда продукт ещё активно меняется словами. Если вы уже выгрузили код и дорабатываете его руками, договоритесь в команде, где теперь источник истины — в редакторе или в репозитории. Две параллельные линии изменений неизбежно разойдутся.
Вариант 2: собственный виртуальный сервер
VPS — классический вариант для команды, где есть разработчик или администратор. На сервере разворачиваются Node.js и PostgreSQL (или база подключается внешняя), перед приложением ставится reverse-proxy с HTTPS, процесс next start держит менеджер процессов, чтобы приложение поднималось после сбоя и перезагрузки.
Что вы получаете: полный контроль, предсказуемый ежемесячный счёт, свободу выбора площадки и страны размещения — последнее важно для персональных данных.
Что берёте на себя: обновления системы и зависимостей, настройку файрвола, мониторинг, резервные копии и проверку восстановления. Если никто в команде за это не отвечает, VPS быстро превращается в риск, а не в экономию.
Вариант 3: управляемая PostgreSQL и контейнеры
Промежуточный вариант: базу держит провайдер управляемой PostgreSQL — резервные копии и обновления на его стороне, вы получаете строку подключения для DATABASE_URL. Приложение упаковывается в контейнер и запускается на платформе контейнеров.
Dockerfile в экспорт не входит — его пишет разработчик: установка зависимостей, скрипт build, запуск через start. На что обратить внимание:
- Несколько экземпляров приложения. Сессии и счётчики ограничения частоты хранятся в PostgreSQL (таблицы site_sessions и rate_limits), поэтому состояние общее для всех экземпляров. Но адрес клиента для лимита берётся из последнего значения заголовка x-forwarded-for: балансировщик должен записывать туда реальный адрес посетителя последним, иначе все посетители окажутся под одним общим лимитом на вход и регистрацию.
- Соединения с базой. На бессерверных площадках каждый экземпляр открывает свои соединения с PostgreSQL, поэтому, скорее всего, понадобится пул соединений.
- Стоимость. Управляемые сервисы обычно дороже голого сервера, зато часть ночных дежурств уходит провайдеру.
| Вариант | Кто администрирует | Контроль | Кому подходит |
|---|---|---|---|
| Облако сервиса | сервис | базовый | MVP, правки в редакторе |
| VPS | ваша команда | полный | есть админ или разработчик |
| Управляемая база и контейнеры | провайдер и вы | высокий | растущая нагрузка, команда |
Когда хватит GitHub Pages, а когда нет
На тарифе Премиум есть публикация в GitHub Pages. Но GitHub Pages сам по себе — статический хостинг: он отдаёт файлы, но не выполняет серверный код и не держит базу данных.
Всё, что в выгруженном проекте опирается на серверную часть — запись заявок в PostgreSQL, аккаунты посетителей, личный кабинет, чтение каталога с сервера, оформление заказа с расчётом суммы на сервере, — требует площадки, где работают Node.js и база. Статическая публикация этого не выполнит.
Поэтому GitHub Pages уместен для витринных страниц без серверной логики. Для фуллстек-продукта с заявками, кабинетами и корзиной нужен один из трёх вариантов выше.
Персональные данные и выбор площадки
Заявка с именем и телефоном — уже персональные данные. Для компаний, работающих в России, закон о персональных данных (152-ФЗ) требует, чтобы запись, накопление и хранение данных граждан России велись с использованием баз данных на территории страны.
Поэтому, выбирая хостинг для Next.js в России, смотрят не только на цену, но и на то, где физически стоит база. Практический вывод в общих чертах: PostgreSQL, куда пишутся заявки и аккаунты, разумно размещать у провайдера с площадкой в России. Если проект остаётся в облаке сервиса, уточните место хранения данных до того, как начнёте собирать реальные заявки. Где окажутся резервные копии и какие ещё обязанности оператора на вас лежат — вопрос к юристу. Что учесть в самих формах, разобрано в статье про персональные данные в формах заявок.
Экспорт — функционально полный каркас, а не готовая к продакшену сборка. Миграции, HTTPS, резервные копии и ревью кода становятся вашей зоной ответственности в момент переезда.
Чек-лист переезда
- Сохраните код в свой Git-репозиторий: архив можно залить в GitFlic, GitHub или внутренний сервер компании.
- Создайте базу PostgreSQL и отдельного пользователя для приложения, не используйте суперпользователя.
- Заполните переменные окружения по .env.example и убедитесь, что файл с секретами не попадает в репозиторий — .gitignore в комплекте.
- Разверните схему. В комплекте есть db:push, миграций нет; для прода подготовьте миграции Prisma до появления реальных данных — как это сделать безопасно, описано в статье про Prisma-миграции.
- Решите, что делать с данными из облака: заявки можно выгрузить в CSV из кабинета, перенос остального спланируйте отдельно.
- Соберите проект скриптом build и запустите start за reverse-proxy.
- Включите HTTPS и перенаправление с http — без этого сессионные cookie и формы выпускать нельзя.
- Настройте резервное копирование базы и один раз восстановите копию в отдельную базу, чтобы убедиться, что она рабочая.
- Поставьте по расписанию чистку просроченных сессий.
- Пройдите сценарии руками: регистрация, заявка, каталог, кабинет, оформление заказа.
- Переключайте трафик только после проверки и держите предыдущую версию доступной на случай отката.
Общие принципы защиты данных — отдельная тема; базовый разбор есть в статье про безопасность данных бизнеса.
Следующий шаг: решите, кто в вашей команде отвечает за сервер. Если такого человека нет, оставайтесь в облаке сервиса, пока он не появится.
