Как увести проект из Lovable, Bolt или Replit к себе

Рано или поздно проекту, собранному в Lovable, Bolt или Replit, становится тесно. Нужен нормальный код-ревью, свой сервер для фоновых задач, доступ к логам, второй разработчик, который работает в своём редакторе. Переезд выглядит как «скачать код и залить куда-нибудь», но код — это только видимая часть. Остальное разбросано по панелям управления, и о нём вспоминают, когда что-то перестаёт работать.

Сначала опись

Прежде чем что-то выгружать, составь список всего, из чего проект состоит на самом деле. Обычно туда входит:

• код фронтенда и серверных функций;
• база данных — часто это проект в Supabase или встроенная база платформы;
• авторизация: где хранятся пользователи и как они входят;
• загруженные файлы;
• переменные окружения и ключи сторонних сервисов;
• домен и DNS;
• всё, что знает адрес твоего приложения снаружи: вебхуки оплаты, адреса возврата OAuth, ссылки в письмах.

Отдельно выясни, на кого оформлены внешние аккаунты. Бывает, что проект в Supabase создан платформой или подрядчиком, и у владельца продукта к нему нет прав администратора. Это стоит исправить до переезда, а не в его середине.

Что выгружать

Код — в собственный репозиторий. У Lovable и Bolt есть синхронизация с GitHub, в Replit можно подключить git или скачать архив. Сразу проверь, что проект собирается локально с нуля: npm ci, затем сборка. Если не собирается, значит, платформа что-то подставляла за тебя, и это надо найти сейчас.

База — полным дампом через pg_dump: схема, данные, функции, триггеры и политики доступа. Политики RLS — это часть безопасности, а не оформление, и если они потеряются при переносе, данные останутся открытыми.

Файлы — отдельно от базы. В базе обычно лежат только пути к ним, и после переезда стоит проверить, что каждая ссылка ведёт на существующий файл.

Пользователей лучше на первом этапе вообще не трогать. Перенос авторизации к другому провайдеру часто означает, что все должны заново задать пароль, и это отдельный проект, а не шаг переезда.

Что обычно ломается

• Переменные окружения. Платформа подставляла их сама, а у нового хостинга их нет. Проверь и префиксы: в Vite в браузер попадают только переменные с VITE_.
• Адреса, зашитые в код: превью-домен платформы, ссылки на её CDN, абсолютные URL в письмах.
• Вход через Google или GitHub. Новый домен надо добавить в список разрешённых адресов возврата, иначе кнопка входа будет отвечать ошибкой.
• Вебхуки. Платёжная система продолжит слать события на старый адрес.
• Пакеты, которые работают только внутри платформы: её база, её авторизация, её хранилище.
• Версия Node и команда сборки, которые раньше выбирала платформа.

Порядок шагов

Не переноси всё за один вечер. Надёжнее так:

1. Репозиторий и локальная сборка, которая повторяет то, что работает сейчас.
2. Деплой на новый хостинг на временном домене, но со старым бэкендом. Прогони основные сценарии руками.
3. Перенос базы и файлов, если он нужен, — отдельным шагом, с коротким окном и заранее отрепетированным дампом.
4. За день до переключения уменьши TTL у DNS-записей, затем переключи домен.
5. Обнови вебхуки и адреса возврата OAuth в тот же час.
6. Неделю держи старую версию живой, чтобы было куда откатиться.

Где теперь правда

Самый частый источник путаницы после переезда — двусторонняя синхронизация. Кто-то продолжает править проект в Lovable, кто-то в редакторе, и изменения перезаписывают друг друга. Договорись, что источник правды — репозиторий. Если платформа нужна для быстрых прототипов, работай в ней в отдельной ветке и вливай изменения через обычный пул-реквест.

Если хочется переехать без простоя и без недели разбирательств, SUBXCAT может провести переезд вместе с твоей командой.