Где разместить проект из Lovable

Lovable доводит идею до рабочего прототипа: вы описываете приложение словами, а на выходе получаете настоящий фронтенд на React, Vite и TypeScript. Но у прототипа есть срок годности — рано или поздно нужен адрес, который принадлежит вам, место рядом с другими проектами и деплой в тот момент, когда решите вы. Код из Lovable при этом забирается с собой: обычно через привязанный GitHub-репозиторий или экспорт папки проекта. Рассказываем по шагам, что проверить в исходниках и как получить постоянную HTTPS-ссылку.

Что на самом деле отдаёт Lovable

Два способа забрать код. Через привязанный GitHub-репозиторий — туда уходят коммиты — или архивом с папкой проекта. В обоих случаях вы получаете исходники, а не готовую сборку.

Типичный стек. React, Vite и TypeScript: package.json, vite.config.ts, tsconfig.json, компоненты на Tailwind, а также клиент Supabase, если в проекте были база и авторизация. Отдельно лежит index.html — на него опирается Vite при сборке.

Чего в архиве быть не должно. node_modules и папка dist — это артефакты. Зависимости ставятся заново при сборке, а старый dist только запутает. Зато package-lock.json оставьте: по нему сборка воспроизводима.

Шаг 1. Заберите проект из Lovable

Через GitHub. Если репозиторий уже привязан, подключите его или скачайте ZIP из интерфейса GitHub. Приватный репозиторий — не помеха, доступ выдаётся токеном.

Экспортом. Если Git не настроен, хватит архива с папкой проекта. Ни git, ни терминал на этом шаге не нужны.

Что проверить сразу. В корне должны лежать package.json и vite.config.ts. Если их нет — вы скачали только страницы, а не проект.

Шаг 2. Проверьте сборку одной командой

Соберите проект локально — это самый быстрый способ поймать проблему до переезда:

npm install
npm run build

Скрипт build у проектов из Lovable обычно выглядит так:

{
  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "preview": "vite preview"
  }
}

Результат складывается в dist/ — это статика, которую и отдаёт хостинг. Если сборка падает локально, она упадёт и на платформе: почините сейчас, иначе получите пустую страницу вместо внятной причины.

Шаг 3. Найдите ключи, которые уже видит браузер

Фронтенд отдаётся целиком. Браузеру нужен весь код, чтобы выполнить приложение, поэтому всё, что вписано прямо в страницу, читает любой, кто откроет исходники. Ключ платного API, сервиса рассылок или платёжки, найденный в коде, считайте утёкшим — независимо от того, где вы хостите сайт.

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

Особый случай — Supabase. Ключ anon публичный по замыслу, но безопасен он только вместе с правилами доступа (RLS) на таблицах. Ключ service_role — настоящий секрет: в браузерном коде ему не место.

Шаг 4. Разберитесь с переменными VITE_*

Это главная ловушка темы. Переменные с префиксом VITE_ Vite подставляет в бандл во время сборки, а не читает в рантайме. В коде они видны как import.meta.env:

const url = import.meta.env.VITE_SUPABASE_URL
const key = import.meta.env.VITE_SUPABASE_ANON_KEY

Следствие первое: секрет с префиксом VITE_ — это утечка. Он лежит в открытом JS, который скачал каждый посетитель. Настоящие секреты — на серверной стороне, в переменных без публичного префикса.

Следствие второе: смена значения требует пересборки. Поменяли переменную в панели — запустите деплой заново, иначе на сайте останется старое значение.

Шаг 5. Не переезжайте вместе с базой

Supabase остаётся на месте. База и вход по аккаунтам живут не в вашем коде, а на стороне сервиса, и продолжают работать со своими ключами. Проект остаётся фронтендом, который к ним обращается.

Что придётся поправить. Добавьте новый адрес сайта в список разрешённых (Redirect URLs) в настройках сервиса. Пока этого нет, вход молча не срабатывает — без внятной ошибки.

Если база нужна своя. Небольшую можно поднять рядом с приложением: docker-compose с PostgreSQL и именованным томом, а строку подключения хранить в секретах. Всё, что записано рядом с кодом, пересоздаётся при следующей публикации.

Шаг 6. Загрузите проект в Dockbox

Dockbox собирает проект из Git-репозитория или архива и превращает его в Docker-контейнер. Порядок такой: подключите репозиторий (приватный тоже) либо загрузите ZIP, добавьте переменные окружения — панель хранит их в зашифрованном виде, — и запустите сборку. Платформа выполнит npm install и npm run build, отдаст содержимое dist/ и выдаст публичный HTTPS-адрес: домен покупать и сертификат настраивать не нужно.

Логи сборки видны в панели в реальном времени, поэтому неудачный билд показывает причину, а не пустую страницу. Упал процесс — перезапустится сам. Новая версия выходит, когда вы загрузите обновлённый код, а адрес остаётся прежним.

Сколько это стоит и как работают контейнеры

Контейнер работает постоянно. Никакого засыпания при простое и лимита по часам работы у тарифа нет: ссылка отвечает в момент открытия, без «прогрева» после паузы. Отдельного счёта за сборки и трафик тоже нет.

• Starter — 990 ₽/мес, первый месяц бесплатно: 1 vCPU, 2 ГБ RAM, 20 ГБ SSD, один проект. Для визитки или лендинга сборки хватает с запасом.
• Pro — 2 490 ₽/мес: 2 vCPU, 4 ГБ RAM, до пяти проектов. Разумный выбор, если сборка тяжёлая или проектов несколько.
• Team — 4 990 ₽/мес: когда над проектом работает команда.

Тариф действует месяц и сам не продлевается. Код остаётся у вас: Dockbox не запирает проект внутри платформы.

Частые вопросы