Replit-застосунок працює в preview, але ламається після публікації? Чекліст для засновника

Ви тестуєте застосунок у Replit, надсилаєте комусь посилання — і одразу чуєте, що вхід, збереження чи оплата не працюють. Перш ніж просити Agent перебудувати ці функції, пройдіть цей чекліст продакшн-деплою Replit. Відмінність між двома середовищами може пояснити збій без жодної нової реалізації.

Чому застосунок може працювати в preview Replit і ламатися наживо?

Preview у Replit і опублікований застосунок — окремі середовища. Живий застосунок може мати інший URL, конфігурацію, дані та поведінку під час виконання, ніж проєкт, який ви редагуєте.

Посібник Replit із публікації пояснює, що публікація створює продакшн-деплой, і подальше редагування не змінює його до наступної публікації. Спершу переконайтеся, що тестуєте потрібний реліз. Запишіть публічний URL, час останньої публікації, дію, яка не спрацьовує, і чи відтворюється збій у новій сесії браузера.

Не збирайте п’ять непов’язаних скриншотів із проханням до Agent виправити весь застосунок. Оберіть один збій: наприклад, новий клієнт отримує помилку після натискання Save. Запишіть очікуваний результат, фактичний результат і час. Так у вас з’явиться щось конкретне, що можна порівняти з логами опублікованого застосунку.

Чи використовує застосунок правильний тип деплою?

Деплой має підтримувати той тип програми, який запускає ваш застосунок. Набір статичних файлів і повноцінний full-stack застосунок мають різні вимоги до хостингу.

Станом на жовтень 2026 року документація Replit щодо типів деплою розрізняє деплої Autoscale, Static, Reserved VM і Scheduled. Перевірте тип деплою в налаштуваннях Publishing і порівняйте його з реальними потребами застосунку.

У тій самій документації сказано, що Static несумісний із застосунками, створеними за допомогою Replit Agent, бо їм потрібен бекенд. Якщо застосунок доопрацьовувався, попросіть розробника перевірити команди збірки та запуску. Потужніша машина не виправить відсутній серверний маршрут чи неправильну команду запуску.

Чи справді доступні потрібні продакшн-секрети?

Перевірте облікові дані та конфігурацію, які використовує опублікований застосунок, зокрема їхні назви та цільове середовище. Ключ, доступний під час розробки, ще не доводить, що інтеграція в живому застосунку налаштована правильно.

Посібник Replit про Secrets вказує шлях Publishing → Adjust settings → Production app secrets. Він також розрізняє чутливі секрети та нечутливі значення конфігурації. Перегляньте там потрібні записи, не копіюючи їхніх значень у промпт для діагностики.

1. Попросіть список назв обов’язкових змінних: де кожна зчитується і чи використовується вона під час збірки чи під час виконання.
2. Перевірте, що продакшн-записи точно збігаються з цими назвами й належать до потрібних облікових записів провайдерів.
3. Тримайте серверні облікові дані на сервері; змінна фронтенду чи браузерний бандл не є сховищем секретів.
4. Повторно опублікуйте застосунок, якщо цього вимагає платформа або процес збірки, а потім повторіть початкову дію на публічному URL.

Чи читає опублікований застосунок потрібну базу даних?

Перш ніж вважати відсутні продакшн-записи зламаним інтерфейсом, з’ясуйте, яка база даних є живою. Тестові дані, видимі в розробці, можуть не бути тими даними, які читає застосунок ваших клієнтів.

Посібник Replit щодо баз даних для розробки та продакшну описує окремі середовища та різні способи налаштування для поточної й застарілої інфраструктури. Перевірте вибір продакшн-бази в інструменті Database і налаштування публікації, що стосуються вашого застосунку. Не припускайте, що туторіал для проєкту іншого покоління відповідає вашому.

Візьмімо гіпотетичний застосунок-каталог. У preview показано десять компаній, а на живому сайті — жодної. Перш ніж перебудовувати компонент списку, перевірте, чи є в продакшні бодай один схвалений запис компанії. Можливо, бракує саме навмисного імпорту даних або кроку ініціалізації. Копіюйте лише дані, придатні для живого використання, і захистіть наявні записи клієнтів перед будь-яким імпортом чи зміною схеми.

Для невдалого запису зберіть операцію та очищене від чутливих даних повідомлення про помилку. Попросіть розробника відрізнити збій підключення від відсутньої таблиці, порушення обмеження чи проблеми з авторизацією. Багаторазова зміна рядка підключення може приховати початкову проблему й випадково спрямувати роботу з розробки на не ті дані.

Чи працюють файли та зовнішні колбеки на публічному домені?

Перевірте, де зберігаються завантажені файли і який домен викликають зовнішні сервіси. І те, й інше може виглядати правильно в preview, але не підходити для опублікованого застосунку.

Для завантажень Replit App Storage надає постійне об’єктне сховище. Перевірте поточну реалізацію, а не припускайте, що файли, записані в runtime-папку, мають потрібні вашому продукту постійність і контроль доступу. Після контрольованого релізу протестуйте завантаження, отримання та обмеження доступу до файлу.

Для провайдерів входу, платіжних вебхуків і посилань в електронних листах перегляньте у відповідного провайдера дозволені origins, зареєстровані ендпоінти та URL повернення. Там, де це потрібно, вони мають вказувати на цільовий опублікований домен. Протестуйте повний цикл: вихід із вашого застосунку, виконання дії у провайдера та повернення на корисний екран.

Ведіть невеликий реєстр інтеграцій: сервіс, середовище, публічний callback-шлях, назва секрету та відповідальна особа. Реєстр містить факти конфігурації, а не значення секретів. Він значно спрощує перевірку майбутніх змін домену та передачу проєкту.

Як перевірити виправлення на живому застосунку?

Відтворіть початкову дію на публічному URL, а потім перегляньте відповідні продакшн-дані. Успішна публікація означає, що реліз завершився; вона не доводить, що кожен сценарій клієнта спрацював.

Посібник Replit із моніторингу пояснює статуси запитів, тривалість відповіді, використання ресурсів і логи застосунку. Використовуйте час невдалої дії, щоб звузити пошук. Високе навантаження на ресурси та помилка застосунку — різні висновки, тож спершу діагностуйте, а потім змінюйте потужності.

1. Використайте новий обліковий запис на опублікованому домені й повторіть саме той сценарій, що не спрацьовував.
2. Після оновлення сторінки переконайтеся, що потрібний запис або результат інтеграції існує.
3. Перевірте відповідний серверний запит або лог, а потім безпечно протестуйте суміжний випадок помилки.
4. Повторіть основний сценарій на телефоні й переконайтеся, що поведінка, яка працювала раніше, досі працює.

Що робити, якщо деплой усе ще потребує розробки?

Якщо перевірки конфігурації не усунули збій, сплануйте розробку навколо конкретної зламаної ділянки. Підготуйте відтворення, налаштування деплою, очищені від чутливих даних помилки та схему задіяних сервісів.

Перш ніж розширювати аудиторію, скористайтеся ширшим чеклістом готовності AI MVP до продакшну, а якщо повторні промпти створюють регресії — посібником про цикл виправлень. Якщо потрібна допомога з перевіркою та випуском наступної версії, забронюйте дзвінок щодо вашого Replit-застосунку. Ми визначимо, що вам потрібно: виправлення конфігурації, точкова зміна коду чи ширший план релізу.