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

> Что выгрузить, что сломается при переезде и в каком порядке переносить код, базу, файлы и домен, чтобы пользователи ничего не заметили.

Published: 2026-03-14 · Source: https://subxcat.com/ru/articles/leaving-lovable · Author: SUBXCAT

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