РАЗБОР
Cloud
Статья
Как отвязать проект от Lovable Cloud и перенести его на облако и среду ИИ разработки от ProTalk в РФ
[ обложка статьи ]
Режим чтения
Прежде чем переносить базу и backend, важно полностью отвязать от Lovable и сам исходный код проекта. Стандартный путь — экспорт репозитория на GitHub: в редакторе Lovable нажмите Edit Code → Transfer Repository, авторизуйтесь через OAuth и выберите свой аккаунт GitHub. После этого код принадлежит вам, и его можно продолжать разрабатывать в любой среде — от Cursor до собственной инфраструктуры. Ниже разобран перенос данных и серверной логики на ProTalk PostgreSQL и Lubanya Cloud, чтобы от Lovable Cloud не зависела ни одна часть production-проекта.
Lovable позволяет быстро создавать frontend, базу данных и серверную логику. Для прототипов это удобно, но в production могут появиться проблемы:
Lovable → ProTalk PostgreSQL → Lubanya Cloud → собственный API-домен
Lovable при этом можно оставить как инструмент быстрой разработки frontend, а production-инфраструктуру контролировать самостоятельно.
│
▼
Frontend-приложение
│
▼
api.ВАШ_ПРОЕКТ.ru
│
▼
Backend на Lubanya Cloud
│
├── PostgreSQL в ProTalk
├── API проекта
├── авторизация
├── Edge Functions
└── бизнес-логика
Создайте базу с именем проекта, например: my-ai-service
После этого скопируйте строку подключения PostgreSQL: postgres://u_my-ai-service
assword@host:5432/my-ai-service
Не публикуйте её в репозитории, frontend-коде, статьях или чатах. Если строка подключения стала доступна третьим лицам, пароль необходимо заменить.
Создай полноценное Node.js-приложение, предназначенное для переноса проекта с Lovable Cloud в независимую инфраструктуру ProTalk PostgreSQL.
Приложение будет развернуто на Lubanya Cloud по адресу:
Не используй Express, Fastify, Koa или другие npm-пакеты, если они не гарантированно предустановлены. Используй встроенные модули Node.js:
{
"name": "protalk-migration-tool",
"version": "1.0.0",
"type": "module",
"scripts": {
"start": "node server.js"
}
}
Сервер обязан:
1. Читать порт только из process.env.PORT:
const PORT = Number(process.env.PORT) || 3000;
2. Слушать на адресе 0.0.0.0:
server.listen(PORT, '0.0.0.0');
3. Корректно работать за reverse proxy.
4. Учитывать заголовки:
GET /health
Ответ:
{
"ok": true
}
6. Раздавать статические файлы из каталога public.
7. Иметь SPA fallback для неизвестных frontend-маршрутов.
8. Защищаться от path traversal.
Функциональность приложения:
1. При открытии приложения показывать административную форму авторизации.
2. Форма должна принимать:
- имя пользователя базы данных;
- пароль пользователя базы данных;
- строку подключения PostgreSQL либо host, port, database, username и password;
- архив миграции в формате ZIP.
3. Не сохраняй пароль и строку подключения в исходном коде, frontend, localStorage, URL или логах.
4. Не передавай секреты обратно в браузер после отправки формы.
5. Для работы используй HTTPS и серверные POST-запросы.
6. Не записывай в логи:
- пароль;
- полную строку подключения;
- JWT;
- секретные ключи;
- содержимое дампа.
7. Добавь CSRF-защиту или одноразовый токен сессии.
8. Административная сессия должна иметь ограниченный срок действия и завершаться после миграции.
9. Добавь подтверждение перед началом миграции:
«Перед продолжением убедитесь, что у вас есть резервная копия целевой базы данных».
10. Архив должен проверяться до распаковки:
- ограничение размера;
- запрет абсолютных путей;
- запрет путей с ..;
- проверка расширений;
- запрет выполнения произвольных файлов;
- ограничение количества файлов.
11. Не выполняй произвольный shell-код из ZIP-архива.
12. Миграцию выполняй только после явного подтверждения пользователя.
13. Добавь этапы миграции:
- загрузка архива;
- проверка архива;
- распаковка во временный каталог;
- поиск SQL-дампа и миграций;
- проверка подключения к PostgreSQL;
- выполнение миграции;
- проверка количества таблиц;
- проверка основных индексов;
- формирование итогового отчёта;
- удаление временных файлов.
14. Если в архиве используется database.sql, обработай его безопасно и показывай прогресс операции.
15. Не удаляй существующие таблицы без отдельного предупреждения и подтверждения.
16. По умолчанию используй безопасный режим:
- CREATE TABLE IF NOT EXISTS;
- CREATE INDEX IF NOT EXISTS;
- транзакции там, где это возможно;
- остановка при критической ошибке.
17. Добавь режимы:
- dry-run;
- import;
- verify.
18. Реализуй API:
GET /health
POST /api/auth
POST /api/migration/inspect
POST /api/migration/run
GET /api/migration/status
POST /api/logout
19. Все API-ответы должны быть JSON.
20. Для ошибок используй единый формат:
{
"ok": false,
"error": "Описание ошибки без секретных данных"
}
21. После успешной миграции отобрази:
- количество обработанных файлов;
- количество найденных SQL-файлов;
- количество применённых миграций;
- количество ошибок;
- список предупреждений;
- итоговый статус.
22. Добавь защиту от:
- brute force;
- повторной отправки формы;
- слишком больших архивов;
- параллельного запуска двух миграций;
- доступа к чужой сессии;
- подмены имени файла;
- скачивания временных файлов.
23. Все секреты должны задаваться через переменные окружения Lubanya Cloud. Не вставляй пароли в исходный код.
24. Добавь README.md с инструкцией:
- как запустить приложение;
- какие переменные окружения нужны;
- как настроить домен;
- как выполнить health-check;
- как сделать резервную копию;
- как откатить миграцию.
25. Не заявляй, что миграция гарантированно совместима с любой базой. Если структура базы неизвестна, показывай предупреждение и требуй предварительной проверки.
Перед завершением проверь:
В код приложения встрой все функции из node server.js
приложение при старте должно просить ввести имя и пароль базы данных db.pro-talk.ru которые зашиты в серверную часть и при успешной авторизации открывать администраторскую панель в которой можно загрузить дамп базы в одном .zip архиве и провести миграцию данных
Само это приложение будет развернуто по адресу: api.ai-from.ru и должно быть полной альтернативой для текущего облака Lovable Cloud
Доступ к базе данных:
postgres://u_my-ai-serviceassword@host:5432/my-ai-service
Авторизуйтесь в личном кабинете и заполните форму "Новый деплой" как на скриншоте:
В поле "Свой домен" впишите адрес: api.ВАШ_ПРОЕКТ.ru
Затем:
Также обновите:
Новый сервер приложения:
https://api.ВАШ_ПРОЕКТ.ru
Перенастрой проект так, чтобы все backend-запросы, авторизация, загрузка файлов, webhook-и и серверные функции использовали новый API-домен.
Требования:
1. Найди все обращения к старому Lovable Cloud backend.
2. Замени их на:
https://api.ВАШ_ПРОЕКТ.ru
3. Не переноси секреты в frontend-код.
4. Все приватные ключи и токены оставь на серверной стороне.
5. Обнови CORS-настройки и callback URL.
6. Проверь авторизацию пользователя.
7. Проверь регистрацию и вход.
8. Проверь чтение и запись данных.
9. Проверь загрузку файлов.
10. Проверь все Edge Functions через новые API-маршруты.
11. Удали неиспользуемые зависимости от Lovable Cloud только после проверки.
12. Добавь обработку ошибок API и отображение понятного сообщения пользователю.
13. Не удаляй старые интеграции до завершения тестирования.
14. Подготовь список оставшихся зависимостей от Lovable Cloud.
После изменений выполни полный тест проекта и сообщи:
После миграции дальнейшую разработку можно вести в собственной среде:
Любаня: Облако
1. Создать базу в ProTalk.
2. Получить PostgreSQL connection string.
3. Экспортировать данные и серверную логику.
4. Создать миграционное приложение через Lovable.
5. Развернуть его в Lubanya Cloud.
6. Подключить API-домен.
7. Загрузить архив и выполнить миграцию.
8. Переключить frontend на новый API.
9. Проверить все функции.
10. Продолжить разработку в dev.pro-talk.ru.
В результате Lovable можно использовать для быстрой разработки интерфейса, а базу данных, backend и production-логику разместить в независимой инфраструктуре ProTalk и Lubanya Cloud.
Lovable позволяет быстро создавать frontend, базу данных и серверную логику. Для прототипов это удобно, но в production могут появиться проблемы:
- зависимость от инфраструктуры Lovable Cloud;
- ошибки 502 и недоступность сервисов;
- сложность переноса Edge Functions;
- рост расходов при увеличении трафика;
- ограниченный контроль над базой и серверными ключами;
- трудности с самостоятельным масштабированием и резервированием.
Lovable → ProTalk PostgreSQL → Lubanya Cloud → собственный API-домен
Lovable при этом можно оставить как инструмент быстрой разработки frontend, а production-инфраструктуру контролировать самостоятельно.
Итоговая архитектура
Пользователь│
▼
Frontend-приложение
│
▼
api.ВАШ_ПРОЕКТ.ru
│
▼
Backend на Lubanya Cloud
│
├── PostgreSQL в ProTalk
├── API проекта
├── авторизация
├── Edge Functions
└── бизнес-логика
Шаг 1. Создайте базу в ProTalk
Откройте сайт: Любаня DB - облачный PostgreSQL для ваших ботовСоздайте базу с именем проекта, например: my-ai-service
После этого скопируйте строку подключения PostgreSQL: postgres://u_my-ai-service
assword@host:5432/my-ai-serviceНе публикуйте её в репозитории, frontend-коде, статьях или чатах. Если строка подключения стала доступна третьим лицам, пароль необходимо заменить.
Шаг 2. Попросите Lovable создать миграционное приложение которое включает в себя все облачные функции и актуальную копию базы данных в Lovable
Ниже приведена системная инструкция для Lovable. Она описывает приложение, которое можно развернуть в Lubanya Cloud и использовать для переноса проекта.Пример системной инструкции для Lovable
Ты - senior backend-разработчик и архитектор миграционных приложений.Создай полноценное Node.js-приложение, предназначенное для переноса проекта с Lovable Cloud в независимую инфраструктуру ProTalk PostgreSQL.
Приложение будет развернуто на Lubanya Cloud по адресу:
Не используй Express, Fastify, Koa или другие npm-пакеты, если они не гарантированно предустановлены. Используй встроенные модули Node.js:
- node:http
- node:fs/promises
- nodeath
- node:url
- node:crypto
- node:child_process
- package.json;
- server.js;
- public/index.html;
- public/app.js;
- public/style.css.
{
"name": "protalk-migration-tool",
"version": "1.0.0",
"type": "module",
"scripts": {
"start": "node server.js"
}
}
Сервер обязан:
1. Читать порт только из process.env.PORT:
const PORT = Number(process.env.PORT) || 3000;
2. Слушать на адресе 0.0.0.0:
server.listen(PORT, '0.0.0.0');
3. Корректно работать за reverse proxy.
4. Учитывать заголовки:
- x-forwarded-for;
- x-forwarded-proto;
- x-forwarded-host.
GET /health
Ответ:
{
"ok": true
}
6. Раздавать статические файлы из каталога public.
7. Иметь SPA fallback для неизвестных frontend-маршрутов.
8. Защищаться от path traversal.
Функциональность приложения:
1. При открытии приложения показывать административную форму авторизации.
2. Форма должна принимать:
- имя пользователя базы данных;
- пароль пользователя базы данных;
- строку подключения PostgreSQL либо host, port, database, username и password;
- архив миграции в формате ZIP.
3. Не сохраняй пароль и строку подключения в исходном коде, frontend, localStorage, URL или логах.
4. Не передавай секреты обратно в браузер после отправки формы.
5. Для работы используй HTTPS и серверные POST-запросы.
6. Не записывай в логи:
- пароль;
- полную строку подключения;
- JWT;
- секретные ключи;
- содержимое дампа.
7. Добавь CSRF-защиту или одноразовый токен сессии.
8. Административная сессия должна иметь ограниченный срок действия и завершаться после миграции.
9. Добавь подтверждение перед началом миграции:
«Перед продолжением убедитесь, что у вас есть резервная копия целевой базы данных».
10. Архив должен проверяться до распаковки:
- ограничение размера;
- запрет абсолютных путей;
- запрет путей с ..;
- проверка расширений;
- запрет выполнения произвольных файлов;
- ограничение количества файлов.
11. Не выполняй произвольный shell-код из ZIP-архива.
12. Миграцию выполняй только после явного подтверждения пользователя.
13. Добавь этапы миграции:
- загрузка архива;
- проверка архива;
- распаковка во временный каталог;
- поиск SQL-дампа и миграций;
- проверка подключения к PostgreSQL;
- выполнение миграции;
- проверка количества таблиц;
- проверка основных индексов;
- формирование итогового отчёта;
- удаление временных файлов.
14. Если в архиве используется database.sql, обработай его безопасно и показывай прогресс операции.
15. Не удаляй существующие таблицы без отдельного предупреждения и подтверждения.
16. По умолчанию используй безопасный режим:
- CREATE TABLE IF NOT EXISTS;
- CREATE INDEX IF NOT EXISTS;
- транзакции там, где это возможно;
- остановка при критической ошибке.
17. Добавь режимы:
- dry-run;
- import;
- verify.
18. Реализуй API:
GET /health
POST /api/auth
POST /api/migration/inspect
POST /api/migration/run
GET /api/migration/status
POST /api/logout
19. Все API-ответы должны быть JSON.
20. Для ошибок используй единый формат:
{
"ok": false,
"error": "Описание ошибки без секретных данных"
}
21. После успешной миграции отобрази:
- количество обработанных файлов;
- количество найденных SQL-файлов;
- количество применённых миграций;
- количество ошибок;
- список предупреждений;
- итоговый статус.
22. Добавь защиту от:
- brute force;
- повторной отправки формы;
- слишком больших архивов;
- параллельного запуска двух миграций;
- доступа к чужой сессии;
- подмены имени файла;
- скачивания временных файлов.
23. Все секреты должны задаваться через переменные окружения Lubanya Cloud. Не вставляй пароли в исходный код.
24. Добавь README.md с инструкцией:
- как запустить приложение;
- какие переменные окружения нужны;
- как настроить домен;
- как выполнить health-check;
- как сделать резервную копию;
- как откатить миграцию.
25. Не заявляй, что миграция гарантированно совместима с любой базой. Если структура базы неизвестна, показывай предупреждение и требуй предварительной проверки.
Перед завершением проверь:
- package.json существует;
- server.js существует;
- используется process.env.PORT;
- сервер слушает 0.0.0.0;
- public/index.html существует;
- API-роуты объявлены до статики;
- нет хардкодных паролей;
- нет вывода секретов в лог;
- нет зависимостей, требующих npm install;
- неизвестные frontend-маршруты возвращают index.html.
В код приложения встрой все функции из node server.js
приложение при старте должно просить ввести имя и пароль базы данных db.pro-talk.ru которые зашиты в серверную часть и при успешной авторизации открывать администраторскую панель в которой можно загрузить дамп базы в одном .zip архиве и провести миграцию данных
Само это приложение будет развернуто по адресу: api.ai-from.ru и должно быть полной альтернативой для текущего облака Lovable Cloud
Доступ к базе данных:
postgres://u_my-ai-service
assword@host:5432/my-ai-serviceШаг 3. Разверните приложение в Lubanya Cloud
Зайдите на этот адрес: https://account.lubanyacloud.ru
Авторизуйтесь в личном кабинете и заполните форму "Новый деплой" как на скриншоте:
В поле "Свой домен" впишите адрес: api.ВАШ_ПРОЕКТ.ru
Шаг 4. Выполните миграцию
Откройте: https://api.ВАШ_ПРОЕКТ.ruЗатем:
- Введите данные базы.
- Загрузите ZIP-архив.
- Запустите проверку архива.
- Просмотрите найденные файлы и предупреждения.
- Выполните dry-run.
- Подтвердите миграцию.
- Дождитесь завершения.
- Проверьте итоговый отчёт.
Шаг 5. Переключите frontend на новый API
После миграции замените старые адреса API на: https://api.ВАШ_ПРОЕКТ.ruТакже обновите:
- переменные окружения;
- авторизацию;
- callback URL;
- OAuth redirect URL;
- CORS;
- webhook-и;
- загрузку файлов;
- платежные уведомления.
Пример финальной инструкции для Lovable
Миграция backend завершена.Новый сервер приложения:
https://api.ВАШ_ПРОЕКТ.ru
Перенастрой проект так, чтобы все backend-запросы, авторизация, загрузка файлов, webhook-и и серверные функции использовали новый API-домен.
Требования:
1. Найди все обращения к старому Lovable Cloud backend.
2. Замени их на:
https://api.ВАШ_ПРОЕКТ.ru
3. Не переноси секреты в frontend-код.
4. Все приватные ключи и токены оставь на серверной стороне.
5. Обнови CORS-настройки и callback URL.
6. Проверь авторизацию пользователя.
7. Проверь регистрацию и вход.
8. Проверь чтение и запись данных.
9. Проверь загрузку файлов.
10. Проверь все Edge Functions через новые API-маршруты.
11. Удали неиспользуемые зависимости от Lovable Cloud только после проверки.
12. Добавь обработку ошибок API и отображение понятного сообщения пользователю.
13. Не удаляй старые интеграции до завершения тестирования.
14. Подготовь список оставшихся зависимостей от Lovable Cloud.
После изменений выполни полный тест проекта и сообщи:
- какие файлы изменены;
- какие API-маршруты переключены;
- какие интеграции требуют ручной проверки;
- остались ли обращения к старому backend.
Шаг 6. Продолжайте разработку в dev.pro-talk.ru
После миграции дальнейшую разработку можно вести в собственной среде:
Любаня: Облако
Итог
Миграция выполняется по следующей схеме:1. Создать базу в ProTalk.
2. Получить PostgreSQL connection string.
3. Экспортировать данные и серверную логику.
4. Создать миграционное приложение через Lovable.
5. Развернуть его в Lubanya Cloud.
6. Подключить API-домен.
7. Загрузить архив и выполнить миграцию.
8. Переключить frontend на новый API.
9. Проверить все функции.
10. Продолжить разработку в dev.pro-talk.ru.
В результате Lovable можно использовать для быстрой разработки интерфейса, а базу данных, backend и production-логику разместить в независимой инфраструктуре ProTalk и Lubanya Cloud.
AI-выжимка
сгенерировано ИИ
Тезисы статьи скоро
Статья читается полностью. Тезисы со ссылками на разделы появятся позже.
Содержание
Codeby Academy
Практика и мастерство
От основ до продвинутого — программы для практиков Codeby.
Перейти к курсу →
Комментарии
1