Aplikasi Replit jalan di preview tapi error setelah dipublikasikan? Checklist untuk founder

Anda menguji aplikasi di Replit, mengirim tautannya ke seseorang, lalu langsung mendapat kabar bahwa login, penyimpanan, atau checkout tidak berfungsi. Sebelum meminta Agent membangun ulang fitur-fitur tersebut, gunakan checklist deployment produksi Replit ini. Perbedaan antara kedua lingkungan bisa jadi menjelaskan kegagalannya tanpa perlu implementasi baru.

Mengapa aplikasi bisa berjalan di preview Replit tetapi gagal saat live?

Preview Replit dan aplikasi yang dipublikasikan adalah lingkungan yang terpisah. Aplikasi live dapat memiliki URL, konfigurasi, data, dan perilaku runtime yang berbeda dari proyek yang sedang Anda edit.

Panduan publikasi Replit menjelaskan bahwa publikasi membuat deployment produksi, dan pengeditan setelahnya tidak mengubah deployment tersebut sampai Anda mempublikasikan lagi. Pertama, pastikan Anda menguji rilis yang dimaksud. Catat URL publik, waktu publikasi terakhir, aksi yang gagal, dan apakah kegagalan juga terjadi di sesi browser yang baru.

Jangan mengumpulkan lima screenshot yang tidak berkaitan lalu meminta Agent memperbaiki seluruh aplikasi. Pilih satu kegagalan: misalnya, pelanggan baru mendapat error setelah menekan Save. Catat hasil yang diharapkan, hasil sebenarnya, dan waktunya. Dengan begitu Anda punya sesuatu yang spesifik untuk dibandingkan dengan log aplikasi yang dipublikasikan.

Apakah aplikasi menggunakan tipe deployment yang tepat?

Deployment harus mendukung jenis program yang dijalankan aplikasi Anda. Sekumpulan file statis dan aplikasi full-stack memiliki kebutuhan hosting yang berbeda.

Per Oktober 2026, dokumentasi tipe deployment Replit membedakan deployment Autoscale, Static, Reserved VM, dan Scheduled. Periksa tipe deployment di pengaturan Publishing dan bandingkan dengan kebutuhan aplikasi yang sebenarnya.

Dokumentasi yang sama menyebutkan bahwa Static tidak kompatibel dengan aplikasi yang dibuat menggunakan Replit Agent karena aplikasi tersebut memerlukan backend. Mintalah developer untuk memastikan perintah build dan run jika aplikasi sudah dikustomisasi. Membeli mesin yang lebih besar tidak akan memperbaiki route server yang hilang atau perintah startup yang salah.

Apakah secret produksi yang dibutuhkan benar-benar tersedia?

Periksa kredensial dan konfigurasi yang digunakan aplikasi yang dipublikasikan, termasuk nama dan lingkungan yang dimaksud. Key yang tersedia saat development bukan bukti bahwa integrasi live sudah dikonfigurasi dengan benar.

Panduan Secrets Replit mengarahkan Anda ke Publishing → Adjust settings → Production app secrets. Panduan itu juga membedakan secret yang sensitif dari nilai konfigurasi yang tidak sensitif. Tinjau entri yang dibutuhkan di sana, tanpa menyalin nilainya ke prompt troubleshooting.

1. Minta daftar nama variabel yang dibutuhkan, di mana masing-masing dibaca, dan apakah digunakan saat build time atau runtime.
2. Pastikan entri produksi sama persis dengan nama-nama tersebut dan berasal dari akun penyedia yang dimaksud.
3. Simpan kredensial server di server; variabel frontend atau bundle browser bukan tempat penyimpanan secret.
4. Publikasikan ulang jika platform atau proses build mengharuskannya, lalu ulangi aksi awal di URL publik.

Apakah aplikasi yang dipublikasikan membaca database yang dimaksud?

Identifikasi database live sebelum menganggap data produksi yang hilang sebagai antarmuka yang rusak. Data contoh yang terlihat di development mungkin bukan data yang dibaca aplikasi pelanggan Anda.

Panduan database development dan produksi Replit menjelaskan lingkungan yang terpisah serta jalur penyiapan yang berbeda untuk infrastruktur saat ini dan infrastruktur lama. Periksa pilihan produksi di alat Database dan pengaturan publikasi yang berlaku untuk aplikasi Anda. Jangan berasumsi bahwa tutorial untuk generasi proyek yang berbeda cocok dengan proyek Anda.

Bayangkan sebuah aplikasi direktori hipotetis. Preview menampilkan sepuluh bisnis, tetapi situs live tidak menampilkan satu pun. Sebelum membangun ulang komponen daftar, periksa apakah produksi berisi data bisnis yang sudah disetujui. Bisa jadi yang terlewat adalah langkah impor data atau inisialisasi yang disengaja. Salin hanya data yang layak untuk penggunaan live, dan lindungi data pelanggan yang sudah ada sebelum melakukan impor atau perubahan skema.

Untuk penulisan data yang gagal, kumpulkan operasinya dan pesan error yang sudah disanitasi. Mintalah developer membedakan kegagalan koneksi dari tabel yang hilang, constraint, atau masalah otorisasi. Mengganti connection string berulang kali dapat mengaburkan masalah aslinya dan tanpa sengaja mengarahkan pekerjaan development ke data yang salah.

Apakah file dan callback eksternal berfungsi di domain publik?

Periksa di mana file yang diunggah disimpan dan domain mana yang dipanggil oleh layanan eksternal. Keduanya bisa tampak benar di preview, tetapi tidak sesuai untuk aplikasi yang dipublikasikan.

Untuk unggahan, Replit App Storage menyediakan object storage yang persisten. Periksa implementasi saat ini alih-alih berasumsi bahwa file yang ditulis ke folder runtime memiliki persistensi dan kontrol akses yang dibutuhkan produk Anda. Uji proses mengunggah, mengambil, dan membatasi akses file setelah rilis yang terkontrol.

Untuk penyedia login, webhook pembayaran, dan tautan email, tinjau allowed origins, endpoint yang terdaftar, dan URL kembali (return URL) bersama penyedia terkait. Semuanya harus merujuk ke domain publikasi yang dimaksud bila diperlukan. Uji seluruh alurnya: keluar dari aplikasi Anda, menyelesaikan aksi di penyedia, lalu kembali ke layar yang berguna.

Simpan inventaris integrasi kecil: layanan, lingkungan, path callback publik, nama secret, dan penanggung jawab. Inventaris ini berisi fakta konfigurasi, bukan nilai secret. Inventaris ini membuat perubahan domain dan serah terima di kemudian hari jauh lebih mudah ditinjau.

Bagaimana cara memverifikasi perbaikan di lingkungan live?

Reproduksi aksi awal di URL publik, lalu periksa bukti produksi yang sesuai. Publikasi yang berhasil berarti rilis sudah selesai; itu tidak membuktikan bahwa setiap alur pelanggan berhasil.

Panduan Monitoring Replit menjelaskan status request, durasi respons, penggunaan sumber daya, dan log aplikasi. Gunakan timestamp aksi yang gagal untuk mempersempit investigasi. Penggunaan sumber daya yang tinggi dan error aplikasi adalah temuan yang berbeda, jadi diagnosis dulu sebelum mengubah kapasitas.

1. Gunakan akun baru di domain yang dipublikasikan dan ulangi alur yang gagal persis seperti sebelumnya.
2. Pastikan data atau hasil integrasi yang dimaksud ada setelah halaman di-refresh.
3. Periksa request server atau log yang sesuai, lalu uji kasus kegagalan terdekat dengan aman.
4. Ulangi alur utama di ponsel dan pastikan perilaku yang sebelumnya berfungsi masih berjalan.

Bagaimana jika deployment masih membutuhkan pekerjaan development?

Jika pemeriksaan konfigurasi tidak menyelesaikan kegagalan, tentukan lingkup pekerjaan development di sekitar batas spesifik yang rusak. Siapkan langkah reproduksi, pengaturan deployment, error yang sudah disanitasi, dan peta layanan yang terlibat.

Gunakan checklist produksi MVP AI yang lebih luas sebelum memperluas jangkauan pengguna, atau panduan fix-loop jika prompt yang berulang justru menimbulkan regresi. Untuk bantuan meninjau dan merilis versi berikutnya, jadwalkan panggilan tentang aplikasi Replit Anda. Kami dapat menentukan apakah Anda membutuhkan perbaikan konfigurasi, perubahan kode yang terfokus, atau rencana rilis yang lebih besar.