Усередині Lovable все виглядає готовим. Прев’ю відкривається, кнопки працюють, демо сподобалось партнеру. А потім ви підключаєте свій домен, вивантажуєте код у GitHub або деплоїте на Vercel чи Netlify — і отримуєте білу сторінку, 404 після оновлення або користувачів, які логіняться й опиняються нікуди.
Це найчастіша ситуація, з якою до нас приходять власники Lovable-проєктів. Добра новина: причини передбачувані. Нижче вісім, які ми виправляємо найчастіше, приблизно в тому порядку, в якому їх варто перевіряти.
Прев’ю Lovable працює в середовищі, яке Lovable налаштовує за вас: маршрутизація, змінні середовища, підключення до Supabase і редіректи авторизації там уже працюють. Щойно застосунок запускається деінде, кожне з цих припущень треба відтворити вручну. Код, який ви бачили, не «зламаний» — він просто залежав від середовища, якого більше немає.
Lovable-застосунки — це односторінкові застосунки на React і Vite. Реальний файл один — index.html, а React Router вирішує, що показати, за адресою. Коли хтось відкриває yoursite.com/pricing напряму, сервер шукає файл /pricing, не знаходить його і повертає 404.
Рішення: додати правило rewrite, яке відправляє всі маршрути на index.html. На Vercel це запис rewrites у vercel.json, на Netlify — файл _redirects із правилом для всіх шляхів. Дві хвилини роботи, але про це ніхто не попереджає.
У Lovable URL Supabase, публічний anon key та інші налаштування підставляються автоматично. На Vercel чи Netlify збірка запускається без них, тож застосунок або не збирається, або збирається і падає в браузері з помилкою «supabaseUrl is required».
Рішення: перенести всі змінні в панель хостингу. У Vite-проєкті кожна змінна, потрібна браузеру, має починатися з VITE_ — без префікса вона на клієнті просто undefined. Ніколи не кладіть секретні ключі (service role key Supabase, секретний ключ Stripe) у VITE_-змінні: вони потрапляють у публічний JavaScript.
Magic link, вхід через Google і скидання пароля повертають користувача на певну адресу. У Supabase її визначають Site URL і список дозволених Redirect URLs. Якщо там досі домен прев’ю Lovable, користувачів з вашого справжнього домену відправляє не туди — або вони бачать помилку про недозволений редірект.
Рішення: у Supabase → Authentication → URL Configuration вказати продакшн-домен як Site URL і додати в дозволені редіректи всі домени, які ви використовуєте (з www і без, staging). Для входу через Google — також додати домен у Google Cloud Console.
Зазвичай це одне з двох. Або продакшн підключено до іншого проєкту Supabase, ніж той, який ви наповнювали в прев’ю, або політики Row Level Security (RLS) блокують запити від реальних залогінених користувачів.
Другий випадок часто гірший, ніж здається. Багато Lovable-проєктів колись «полагодили», вимкнувши RLS або додавши політику, що дозволяє все. Застосунок запрацював — а кожен рядок таблиці став доступним будь-кому, хто має ваш публічний anon key, який лежить у вашому JavaScript.
Рішення: перевірити, який проєкт Supabase використовує кожне середовище, і пройтися по RLS таблиця за таблицею. Кожна таблиця з даними користувачів має мати увімкнений RLS і політики, прив’язані до auth.uid(). Це єдиний пункт у списку, який є проблемою безпеки, а не просто багом.
Клієнт заплатив, Stripe бачить платіж, а акаунт не оновився. Статус оплати має підтверджувати вебхук — запит, який Stripe надсилає на ваш бекенд, — а не браузер. У Lovable-проєктах цей бекенд зазвичай Supabase Edge Function.
Типові збої: вебхук у Stripe досі вказує на тестову адресу, у секретах функції немає signing secret, функцію так і не задеплоїли в продакшн-проєкт, або тестові ключі змішані з бойовими.
Рішення: спершу відкрити журнал доставки вебхуків у кабінеті Stripe — там видно, які запити впали і чому. Потім узгодити ключі й секрети для кожного середовища.
Дві класичні причини. Перша — регістр у назвах файлів: macOS байдуже, імпортуєте ви ./components/Header чи ./components/header, а Linux-серверам Vercel і Netlify — ні. Друга — помилки TypeScript або ESLint, які Lovable пропускав, а суворіша збірка вважає фатальними.
Рішення: перед деплоєм запустити npm run build локально з репозиторію GitHub. Кожна помилка, яку ви там побачите, з’явиться і на хостингу.
Коли фронтенд переїжджає на новий домен, Edge Functions, які дозволяли запити лише з адреси прев’ю, починають відхиляти запити браузера. У консолі це виглядає як загальна помилка CORS, і люди шукають проблему не там.
Рішення: у кожній функції обробляти preflight-запит OPTIONS і повертати правильний заголовок Access-Control-Allow-Origin для продакшн-домену.
Це нічого видимо не ламає, тому виявляється пізно. Lovable-застосунок малюється в браузері, тож початковий HTML майже порожній, а всі сторінки мають однаковий title і description. Google вміє виконувати JavaScript, але повільніше й менш надійно, а прев’ю посилань у LinkedIn, Telegram чи Viber зазвичай нічого корисного не показують.
Рішення: щонайменше — унікальні title і description для кожного маршруту та sitemap. Якщо пошуковий трафік важливий для бізнесу, справжнє рішення — пререндеринг або перенесення публічних сторінок на фреймворк із серверним рендерингом, наприклад Next.js.
Коли щось ламається після деплою, природно вставити помилку назад у Lovable. Але більшість цих причин не в коді, який бачить Lovable: вони в налаштуваннях Vercel, Supabase, Stripe і Google Cloud. AI змінює код, щоб це компенсувати, часто в кількох місцях — і ви отримуєте новий баг і менше кредитів. Якщо три промпти поспіль не допомогли, проблема майже напевно поза кодом.
Якщо ви пройшли список, а застосунок і далі поводиться дивно, або знайшли вимкнений RLS на таблицях з персональними даними — час для нормального аудиту. Ми працюємо з Lovable-проєктами через синхронізацію з GitHub, тож після виправлень можна й далі будувати в Lovable — або переїхати на власний стек, якщо проєкт його переріс.
Дивіться, як ми доопрацьовуємо проєкти після AI-інструментів — перший аудит коду безкоштовний.
Відповімо протягом 1 години в робочий час. Безкоштовна консультація.