Приложение Replit работает в превью, но ломается после публикации? Чек-лист для основателя

Вы тестируете приложение в Replit, отправляете кому-то ссылку — и сразу слышите, что вход, сохранение или оплата не работают. Прежде чем просить Agent переписать эти функции, пройдите этот чек-лист продакшен-деплоя Replit. Сбой может объясняться разницей между двумя окружениями, и тогда новая реализация не понадобится.

Почему приложение может работать в превью Replit и ломаться в продакшене?

Превью Replit и опубликованное приложение — это отдельные окружения. У живого приложения могут быть другие URL, конфигурация, данные и поведение во время выполнения, чем у проекта, который вы редактируете.

В руководстве Replit по публикации объясняется, что публикация создаёт продакшен-деплой и последующие правки не меняют его до следующей публикации. Сначала убедитесь, что тестируете нужный релиз. Запишите публичный URL, время последней публикации, действие, которое не срабатывает, и воспроизводится ли сбой в новой сессии браузера.

Не собирайте пять несвязанных скриншотов с просьбой к Agent починить всё приложение. Выберите один сбой: например, новый клиент получает ошибку после нажатия «Сохранить». Запишите ожидаемый результат, фактический результат и время. Так у вас появится конкретная точка для сверки с логами опубликованного приложения.

Правильный ли тип деплоя использует приложение?

Деплой должен поддерживать тот тип программы, который запускает ваше приложение. У набора статических файлов и у full-stack-приложения разные требования к хостингу.

По состоянию на октябрь 2026 года документация Replit о типах деплоя различает деплои Autoscale, Static, Reserved VM и Scheduled. Проверьте тип деплоя в настройках публикации и сравните его с реальными потребностями приложения.

В той же документации сказано, что Static несовместим с приложениями, созданными с помощью Replit Agent, потому что им нужен бэкенд. Если приложение дорабатывали, попросите разработчика проверить команды сборки и запуска. Более мощная машина не исправит отсутствующий серверный маршрут или неверную команду запуска.

Действительно ли доступны нужные продакшен-секреты?

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

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

1. Запросите список имён обязательных переменных: где читается каждая и используется ли она при сборке или во время выполнения.
2. Убедитесь, что продакшен-записи точно совпадают с этими именами и относятся к нужным аккаунтам провайдеров.
3. Храните серверные учётные данные на сервере: переменная фронтенда или браузерный бандл — не хранилище секретов.
4. Опубликуйте заново, если этого требует платформа или процесс сборки, а затем повторите исходное действие на публичном URL.

Читает ли опубликованное приложение нужную базу данных?

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

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

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

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

Работают ли файлы и внешние обратные вызовы на публичном домене?

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

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

Для провайдеров входа, платёжных вебхуков и ссылок в письмах проверьте у соответствующего провайдера разрешённые источники (origins), зарегистрированные эндпоинты и URL возврата. Там, где это требуется, они должны указывать на нужный опубликованный домен. Протестируйте весь цикл: уход из приложения, выполнение действия у провайдера и возврат на полезный экран.

Ведите небольшой реестр интеграций: сервис, окружение, публичный путь обратного вызова, имя секрета и ответственный. В реестре хранятся факты о конфигурации, а не значения секретов. Он заметно упрощает проверку при будущей смене домена и передаче проекта.

Как проверить исправление в продакшене?

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

Руководство Replit по мониторингу объясняет статусы запросов, время ответа, использование ресурсов и логи приложения. Используйте время неудачного действия, чтобы сузить поиск. Высокая нагрузка на ресурсы и ошибка приложения — это разные выводы, поэтому сначала поставьте диагноз, а потом меняйте мощность.

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

Что делать, если деплою всё ещё нужна доработка?

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

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