Aplikacja Replit działa w podglądzie, ale psuje się po publikacji? Lista kontrolna dla founderów

Testujesz aplikację w Replit, wysyłasz komuś link i od razu słyszysz, że logowanie, zapisywanie albo płatność nie działa. Zanim poprosisz Agenta o przebudowę tych funkcji, przejdź przez tę listę kontrolną wdrożenia produkcyjnego w Replit. Różnica między dwoma środowiskami może wyjaśnić błąd bez konieczności pisania nowej implementacji.

Dlaczego aplikacja może działać w podglądzie Replit, a na produkcji nie?

Podgląd w Replit i opublikowana aplikacja to osobne środowiska. Wersja live może mieć inny adres URL, konfigurację, dane i zachowanie w czasie działania niż projekt, który edytujesz.

Przewodnik po publikacji Replit wyjaśnia, że publikacja tworzy wdrożenie produkcyjne, a późniejsza edycja nie zmienia go aż do kolejnej publikacji. Najpierw upewnij się, że testujesz właściwe wydanie. Zapisz publiczny adres URL, czas ostatniej publikacji, akcję, która się nie udaje, oraz to, czy błąd występuje także w nowej sesji przeglądarki.

Nie zbieraj pięciu niepowiązanych zrzutów ekranu, prosząc Agenta o naprawę całej aplikacji. Wybierz jeden błąd: na przykład nowy klient dostaje komunikat o błędzie po kliknięciu Zapisz. Zanotuj oczekiwany wynik, faktyczny wynik i godzinę. Dzięki temu masz coś konkretnego do porównania z logami opublikowanej aplikacji.

Czy aplikacja używa właściwego typu wdrożenia?

Wdrożenie musi obsługiwać rodzaj programu, który uruchamia Twoja aplikacja. Zestaw plików statycznych i aplikacja full-stack mają różne wymagania hostingowe.

Według stanu na październik 2026 r. dokumentacja typów wdrożeń Replit rozróżnia wdrożenia Autoscale, Static, Reserved VM i Scheduled. Sprawdź typ wdrożenia w ustawieniach publikacji i porównaj go z rzeczywistymi potrzebami aplikacji.

Ta sama dokumentacja podaje, że typ Static nie jest zgodny z aplikacjami utworzonymi przez Replit Agent, ponieważ potrzebują one backendu. Jeśli aplikacja była modyfikowana, poproś developera o potwierdzenie komend build i run. Zakup mocniejszej maszyny nie naprawi brakującej trasy serwera ani błędnej komendy startowej.

Czy wymagane sekrety produkcyjne są faktycznie dostępne?

Sprawdź dane uwierzytelniające i konfigurację używaną przez opublikowaną aplikację, w tym ich nazwy i docelowe środowisko. Klucz dostępny podczas developmentu nie dowodzi, że integracja na produkcji jest poprawnie skonfigurowana.

Przewodnik po sekretach Replit kieruje do Publishing → Adjust settings → Production app secrets. Rozróżnia też wrażliwe sekrety od niewrażliwych wartości konfiguracyjnych. Przejrzyj tam wymagane wpisy, nie kopiując ich wartości do promptu diagnostycznego.

1. Poproś o listę nazw wymaganych zmiennych, miejsc, w których są odczytywane, oraz informację, czy są używane w czasie buildu, czy w czasie działania.
2. Sprawdź, czy wpisy produkcyjne dokładnie odpowiadają tym nazwom i należą do właściwych kont dostawców.
3. Trzymaj dane uwierzytelniające serwera na serwerze; zmienna frontendowa ani bundle przeglądarki nie są miejscem na sekrety.
4. Opublikuj ponownie, jeśli wymaga tego platforma lub proces buildu, a potem powtórz pierwotną akcję na publicznym adresie URL.

Czy opublikowana aplikacja odczytuje właściwą bazę danych?

Zanim uznasz brakujące rekordy produkcyjne za zepsuty interfejs, ustal, która baza danych jest używana na produkcji. Przykładowe dane widoczne w środowisku deweloperskim mogą nie być danymi, które odczytuje aplikacja Twoich klientów.

Przewodnik po bazach deweloperskich i produkcyjnych Replit opisuje osobne środowiska i różne ścieżki konfiguracji dla obecnej i starszej infrastruktury. Sprawdź wybór produkcyjny w narzędziu Database oraz ustawienia publikacji dotyczące Twojej aplikacji. Nie zakładaj, że tutorial dla innej generacji projektów pasuje do Twojego.

Weźmy hipotetyczną aplikację katalogową. Podgląd pokazuje dziesięć firm, a wersja live żadnej. Zanim przebudujesz komponent listy, sprawdź, czy produkcja zawiera jakiekolwiek zatwierdzone rekordy firm. Brakującym krokiem może być celowy import danych lub inicjalizacja. Kopiuj tylko dane nadające się do użytku produkcyjnego i zabezpiecz istniejące rekordy klientów przed każdym importem lub zmianą schematu.

W przypadku nieudanego zapisu zbierz informację o operacji i oczyszczony z poufnych danych komunikat błędu. Poproś developera, by odróżnił błąd połączenia od brakującej tabeli, naruszenia ograniczenia lub problemu z autoryzacją. Wielokrotna zmiana connection stringa może zamaskować pierwotny problem i przypadkiem skierować prace deweloperskie na niewłaściwe dane.

Czy pliki i zewnętrzne callbacki działają na publicznej domenie?

Sprawdź, gdzie przechowywane są przesyłane pliki i którą domenę wywołują usługi zewnętrzne. Oba elementy mogą wyglądać poprawnie w podglądzie, a jednocześnie nie nadawać się dla opublikowanej aplikacji.

Dla przesyłanych plików Replit App Storage zapewnia trwały object storage. Sprawdź obecną implementację, zamiast zakładać, że pliki zapisywane w folderze środowiska uruchomieniowego mają trwałość i kontrolę dostępu, jakich potrzebuje Twój produkt. Po kontrolowanym wydaniu przetestuj przesłanie pliku, jego pobranie i ograniczenie dostępu do niego.

W przypadku dostawców logowania, webhooków płatności i linków w e-mailach przejrzyj u danego dostawcy dozwolone originy, zarejestrowane endpointy i adresy powrotu. Tam, gdzie to wymagane, powinny wskazywać na docelową opublikowaną domenę. Przetestuj cały cykl: wyjście z aplikacji, wykonanie akcji u dostawcy i powrót na sensowny ekran.

Prowadź krótki spis integracji: usługa, środowisko, publiczna ścieżka callbacku, nazwa sekretu i osoba odpowiedzialna. Spis zawiera fakty konfiguracyjne, a nie wartości sekretów. Znacznie ułatwia on późniejsze przeglądy zmian domeny i przekazywanie projektu.

Jak zweryfikować poprawkę na produkcji?

Odtwórz pierwotną akcję na publicznym adresie URL, a następnie sprawdź odpowiadające jej dowody na produkcji. Udana publikacja oznacza, że wydanie się zakończyło; nie dowodzi, że każda ścieżka klienta działa.

Przewodnik po monitoringu Replit wyjaśnia statusy żądań, czas odpowiedzi, zużycie zasobów i logi aplikacji. Użyj znacznika czasu nieudanej akcji, aby zawęzić analizę. Wysokie zużycie zasobów i błąd aplikacji to różne ustalenia, więc najpierw zdiagnozuj problem, a dopiero potem zmieniaj moc obliczeniową.

1. Użyj nowego konta na opublikowanej domenie i powtórz dokładnie tę ścieżkę, która się nie udawała.
2. Po odświeżeniu strony potwierdź, że oczekiwany rekord lub efekt integracji istnieje.
3. Sprawdź odpowiadające żądanie serwera lub wpis w logach, a następnie bezpiecznie przetestuj pokrewny przypadek błędu.
4. Powtórz główną ścieżkę na telefonie i upewnij się, że to, co wcześniej działało, nadal działa.

Co, jeśli wdrożenie nadal wymaga prac deweloperskich?

Jeśli kontrola konfiguracji nie rozwiąże problemu, zaplanuj prace deweloperskie wokół konkretnej zepsutej granicy systemu. Przygotuj sposób odtworzenia błędu, ustawienia wdrożenia, oczyszczone komunikaty błędów i mapę zaangażowanych usług.

Zanim poszerzysz grono odbiorców, skorzystaj z szerszej listy kontrolnej produkcyjnej dla MVP zbudowanego z AI, a jeśli kolejne prompty powodują regresje, zajrzyj do przewodnika o pętli poprawek. Jeśli potrzebujesz pomocy w przeglądzie i wydaniu kolejnej wersji, umów rozmowę o swojej aplikacji Replit. Ustalimy, czy potrzebujesz naprawy konfiguracji, ukierunkowanej zmiany w kodzie, czy szerszego planu wydania.