Lovable не запирает проект внутри платформы. Код можно синхронизировать с GitHub и развернуть на внешнем хостинге, а backend переносить отдельно или оставить в Lovable Cloud.
Это важно не только для тех, кто уже решил уехать. Переносимость — нормальная страховка: проект может вырасти, появятся требования к инфраструктуре, стоимости, data residency или внутренним правилам компании.
Первый шаг почти всегда один и тот же — подключить Lovable к GitHub.
Что можно перенести отдельно
У приложения есть несколько слоёв:
- frontend и исходный код;
- production hosting;
- база данных;
- storage;
- authentication;
- edge/server functions;
- секреты и environment variables.
Не обязательно переносить всё сразу. Самый простой сценарий — вынести frontend на Vercel или Netlify, а backend временно оставить в Lovable Cloud.
Шаг 1. Синхронизируйте GitHub
Внешние deployment-сценарии Lovable строятся вокруг репозитория. После подключения GitHub код проекта постоянно синхронизируется, а hosting-платформа может автоматически собирать новую версию после push.
Перед миграцией создайте стабильный commit и проверьте, что репозиторий содержит актуальную версию.
Шаг 2. Выберите хостинг
Для frontend подходят Git-based платформы: Vercel, Netlify, Cloudflare Pages, AWS Amplify, Azure Static Web Apps и другие.
В большинстве случаев достаточно подключить репозиторий, выбрать branch и дать платформе определить build-настройки.
Для старых Vite-проектов типовая сборка использует npm run build и папку dist. Для TanStack Start схема может отличаться в зависимости от deployment target, поэтому ориентируйтесь на реальную структуру вашего проекта, а не на универсальную инструкцию из старого гайда.
Шаг 3. Перенесите environment variables
Локальный .env из репозитория не должен автоматически становиться публичным. Добавьте необходимые переменные в настройках нового хостинга.
Если frontend продолжает работать с Lovable Cloud или Supabase, ему понадобятся публичные URL и publishable key. Секретные API-ключи переносите только в server-side environment.
Шаг 4. Настройте routing
У SPA-проектов прямой переход на /dashboard или другую внутреннюю страницу может дать 404, если хостинг не знает, что нужно отдать index.html.
Для таких приложений настройте fallback rewrite. У SSR/TanStack-проектов маршрутизация зависит от адаптера и платформы, поэтому проверяйте deployment по конкретному шаблону.
Шаг 5. Обновите OAuth
Новый домен означает новый production URL. Если приложение использует Google, Apple или другой OAuth, добавьте новый redirect URI у провайдера.
Это одна из самых частых причин ситуации «сайт открылся, а войти нельзя». Подробно про Google есть в гайде Google Auth в Lovable.
Шаг 6. Решите, что делать с backend
Есть три основных варианта:
Оставить Lovable Cloud. Самый простой путь. Меняется только frontend hosting.
Использовать собственный Supabase. Подходит, если вы заранее строили проект на внешнем Supabase.
Перенести backend полностью. Самый сложный вариант: нужно переносить данные, storage, функции, auth и секреты.
Если вы сейчас только выбираете архитектуру, сравните Lovable Cloud и Supabase до запуска.
Как не потерять данные
Код и база — разные вещи. GitHub не содержит автоматически пользовательские записи из database и файлы из storage.
Перед переносом backend сделайте экспорт данных, инвентаризацию buckets и список секретов. Отдельно проверьте user accounts и механизм авторизации: перенос таблицы profiles ещё не означает перенос всех auth identities.
Домен
Когда новый deployment уже протестирован на временном URL, переключайте production DNS. Не меняйте домен в самом начале миграции — иначе будете одновременно отлаживать инфраструктуру и боевой трафик.
После переключения проверьте HTTPS, canonical, sitemap и Search Console. Для поискового проекта используйте чек-лист SEO в Lovable.
Что перестанет делать Lovable
Lovable не может полноценно контролировать production-инфраструктуру, которую вы перенесли наружу. Логи, rollback, CDN, uptime и настройки deployment становятся вашей ответственностью или ответственностью нового провайдера.
При этом сам Lovable можно продолжать использовать как среду разработки, синхронизируя изменения через GitHub.
Практический dry run перед сменой DNS
Самая безопасная миграция — когда новый хостинг уже полностью работает на временном URL, а старый production ещё не тронут.
До переключения домена пройдите по контрольному списку:
- главная и внутренние страницы открываются напрямую;
- регистрация, вход и выход работают;
- данные читаются и сохраняются;
- файлы загружаются и открываются;
- платежи работают в test mode;
- 404 и редиректы ведут куда нужно;
- секреты не попали во frontend;
- есть понятный способ вернуться на старый deployment.
Только после такого dry run меняйте DNS. Если после переключения появляется ошибка, вы уже знаете, что код и backend работали на временном адресе — значит, круг поиска резко сужается до домена, HTTPS, OAuth или production-переменных.
FAQ
Можно перенести только frontend?
Да. Backend может остаться в Cloud.
Можно уйти из Lovable полностью?
Код принадлежит владельцу проекта, а данные можно экспортировать, но полная миграция backend требует отдельной работы.
Достаточно ли GitHub для резервной копии?
Для кода — да. Для базы и storage — нет.
Итог
Самый безопасный перенос Lovable — постепенный: сначала GitHub, затем новый frontend hosting, потом при необходимости backend и данные.
Не пытайтесь менять код, базу, домен и OAuth в один день. Разделённая миграция легче тестируется и даёт понятную точку отката на каждом этапе.