Penyiapan domain kustom untuk aplikasi web dengan langkah-langkah DNS yang jelas, penerbitan SSL, aturan pengalihan, dan rencana pemindahan berisiko rendah untuk menghindari downtime dan masalah cookie.
Domain kustom bukan sekadar URL yang lebih rapi. Begitu Anda pindah dari alamat platform (misalnya aplikasi yang Anda buat di Koder.ai di subdomain platform) ke domain sendiri, browser dan jaringan memperlakukan itu sebagai situs berbeda. Itu memengaruhi routing, keamanan, dan cara sesi pengguna berperilaku.
Begitu Anda beralih ke domain kustom, beberapa hal langsung berubah:
www atau domain apex, dan perlu aturan konsisten dari HTTP ke HTTPS.old-platform.example tidak otomatis bekerja di app.yourdomain.com.Gangguan singkat biasanya terjadi karena timing. DNS bisa mulai mengirim lalu lintas ke host baru sebelum sertifikat SSL siap, yang menyebabkan peringatan browser. Atau sebaliknya: SSL siap, tapi banyak pengguna masih menuju tempat lama karena cache DNS mereka belum kadaluarsa.
Redirect juga bisa merusak login dengan cara halus. Redirect yang mengubah hostname (apex ke www, atau sebaliknya) bisa membuat cookie hilang jika cookie diatur untuk host lain. Penyedia otentikasi bisa gagal jika callback URL masih menunjuk domain lama.
Cutover berisiko rendah berarti Anda merencanakan overlap: biarkan URL lama bekerja, bangun domain baru secara paralel, alihkan lalu lintas pada momen yang bisa diprediksi, dan buat rollback semudah mengubah DNS kembali.
Sebelum mengubah apa pun, tuliskan nama-nama yang ingin pengguna ketik, dan nama mana yang harus mengalihkan diam-diam. Sebagian besar momen "kenapa ini setengah-berfungsi?" muncul karena tim belum sepakat pada satu hostname yang benar.
Mulailah dengan pilihan besar: apex (example.com) atau www (www.example.com) sebagai utama. Keduanya bisa bekerja, tapi pilih salah satu dan perlakukan yang lain sebagai redirect. Ini penting juga untuk cookie: sesi biasanya paling mudah saat aplikasi berada pada satu host yang konsisten.
Selanjutnya, tentukan subdomain mana yang Anda butuhkan sekarang, dan mana yang bisa ditunda. Pola umum adalah app.example.com untuk aplikasi web dan api.example.com untuk API, dengan admin.example.com atau assets.example.com ditambahkan kemudian. Jika Anda menyiapkan domain kustom pada platform seperti Koder.ai, pilihan ini langsung tercermin pada apa yang akan Anda validasi untuk SSL dan apa yang akan Anda tunjuk di DNS.
Banyak orang membeli domain di registrar, tetapi DNS mungkin dihosting di tempat lain. Konfirmasi di mana record diedit sekarang, siapa yang punya akses, dan apakah ada otomasi yang mengelola perubahan (IT perusahaan, agensi, atau penyedia DNS terkelola). Jika Anda tidak bisa login dan melihat record saat ini, hentikan dan perbaiki itu terlebih dahulu.
Audit juga apa yang sudah menggunakan domain tersebut. Email adalah jebakan klasik: Anda bisa merusak pengiriman email dengan menghapus atau menimpa record.
Sebelum melanjutkan, tangkap keputusan ini secara tertulis:
www) dan arah redirectJika tim marketing sudah menjalankan email di example.com, biarkan record terkait email tidak tersentuh saat Anda hanya menambahkan yang dibutuhkan aplikasi.
Sebagian besar risiko saat pindah domain kustom bukan dari aplikasi itu sendiri. Risiko itu datang dari satu perubahan DNS yang salah yang mengirim lalu lintas ke mana-mana, merusak email, atau membuat validasi SSL gagal.
A record menunjuk sebuah nama ke alamat IP. Dalam istilah sederhana: “kirim orang ke server ini.” Umum dipakai untuk apex (example.com) ketika penyedia memberi IP tetap.
CNAME record menunjuk satu nama ke nama lain. Dalam istilah sederhana: “anggap nama ini sebagai alias dari hostname itu.” Umum untuk www.example.com yang mengarah ke hostname platform.
Banyak penyedia DNS juga menawarkan ALIAS/ANAME pada apex. Itu berperilaku seperti CNAME tetapi bekerja untuk example.com. Jika penyedia Anda mendukungnya, bisa lebih mudah karena target bisa berubah tanpa Anda harus mengubah IP.
Model mental sederhana:
Anda sering menambahkan TXT untuk pemeriksaan kepemilikan domain (verifikasi platform) dan untuk validasi sertifikat SSL (beberapa CA memvalidasi lewat token TXT). TXT juga digunakan untuk kebijakan email seperti SPF. Menghapus atau mengganti SPF TXT yang ada dapat merusak pengiriman email.
TTL mengontrol berapa lama sistem lain menyimpan jawaban DNS Anda. Sehari sebelum cutover, turunkan TTL pada record yang akan Anda ubah (umumnya 300 sampai 600 detik). Setelah semuanya stabil, naikkan lagi untuk mengurangi beban query.
Sebelum mengedit, ekspor atau screenshot zona saat ini. Tuliskan setiap record yang akan Anda ubah, nilai lama, nilai baru, dan TTL. Jika sesuatu salah, rollback adalah mengembalikan nilai sebelumnya.
Ini paling penting ketika domain Anda sudah punya MX, DKIM, atau TXT lainnya untuk email.
SSL (ikon gembok) mengenkripsi lalu lintas antara browser dan aplikasi Anda. Browser modern dan banyak API mengharapkan HTTPS secara default. Tanpa itu, Anda bisa mendapat peringatan, permintaan diblokir, dan fitur seperti service worker, geolocation, dan beberapa alur pembayaran bisa berhenti bekerja.
Untuk menerbitkan sertifikat, otoritas sertifikat harus memverifikasi bahwa Anda mengontrol domain. Metode validasi umum adalah validasi HTTP dan validasi DNS TXT:
Validasi DNS sering lebih mudah ketika Anda menggunakan CDN atau ketika aplikasi Anda belum dapat dijangkau di domain baru.
Di mana sertifikat diterbitkan tergantung pada setup Anda. Beberapa tim menerbitkan sertifikat langsung di infrastruktur hosting, beberapa melakukannya di CDN, dan beberapa platform yang mendukung domain kustom menangani ini untuk Anda (misalnya, Koder.ai dapat mengelola sertifikat saat setup domain). Yang penting adalah tahu siapa yang mengelola siklus hidup sertifikat, termasuk pembaruan.
Penerbitan sertifikat tidak selalu instan. Propagasi DNS, pemeriksaan validasi, dan batasan rate dapat memperlambatnya. Rencanakan pengulangan dan hindari menjadwalkan cutover di menit terakhir.
Rencana waktu praktis:
Sertifikat harus mencakup setiap hostname yang akan diakses pengguna. Periksa daftar SAN (Subject Alternative Names). Jika aplikasi Anda akan tersedia di example.com dan www.example.com, sertifikat harus menyertakan keduanya.
Wildcard (seperti *.example.com) bisa membantu untuk banyak subdomain, tetapi tidak mencakup apex (example.com).
Contoh konkret: jika Anda hanya mengeluarkan sertifikat untuk www.example.com, pengguna yang mengetik example.com masih akan melihat peringatan kecuali Anda mengalihkan di lapisan yang sudah memiliki sertifikat valid untuk example.com.
Redirect terdengar sederhana, tetapi sebagian besar masalah domain muncul di sini: loop, konten campuran, dan pengguna yang keluar karena mereka bolak-balik antar host. Pilih satu host kanonik dan pertahankan: www.example.com atau example.com (apex). Titik masuk lainnya harus mengalihkan ke host kanonik Anda sehingga cookie, sesi, dan sinyal SEO tetap konsisten.
Default yang aman:
http:// ke https:// untuk setiap permintaanUntuk HTTP ke HTTPS, hindari aturan yang memantulkan pengguna bolak-balik. Cara termudah mencegah loop adalah mendasarkan keputusan pada apa yang sebenarnya diminta. Jika aplikasi Anda berada di belakang proxy atau CDN, konfigurasikan agar menghormati forwarded headers (misalnya header yang mengatakan skema asli adalah HTTP). Jika tidak, aplikasi Anda mungkin mengira setiap permintaan adalah HTTP dan terus melakukan redirect selamanya.
Selama perpindahan, biarkan path lama tetap aktif. Jika Anda mengubah rute (misalnya /login ke /sign-in), tambahkan redirect eksplisit untuk path tersebut. Jangan mengandalkan redirect umum ke halaman utama—itu merusak bookmark dan link yang dibagikan.
Tunda penerapan HSTS pada awalnya. Jika Anda mengaktifkannya terlalu cepat lalu perlu melayani HTTP untuk validasi atau troubleshooting, browser mungkin menolak. Tunggu sampai HTTPS stabil dan Anda telah memastikan cakupan subdomain.
Untuk menguji redirect tanpa memengaruhi semua orang, gunakan hostname uji sementara, coba beberapa deep link nyata (termasuk halaman otentikasi), dan jalankan permintaan baris perintah yang menunjukkan setiap langkah redirect dan tujuan akhirnya.
Cutover yang aman sebagian besar soal penjadwalan. Anda ingin domain baru siap dan diuji sebelum pengguna nyata dikirim ke sana, dan Anda ingin perubahan DNS menyebar cepat agar tidak terjebak menunggu saat insiden.
Turunkan TTL DNS (untuk record yang akan Anda ubah) jauh-jauh hari. Lakukan sehari sebelumnya jika bisa, lalu tunggu sampai jendela TTL lama berlalu sehingga cache punya waktu untuk mengambil nilai baru yang lebih pendek.
Selanjutnya, tambahkan domain kustom di hosting/penyedia Anda dan selesaikan verifikasi yang mereka minta. Jika Anda menggunakan platform seperti Koder.ai, tambahkan domain di sana dulu agar platform bisa mengonfirmasi kepemilikan dan menyiapkan routing.
Terbitkan SSL lebih awal. Sertifikat bisa memakan waktu menit atau lebih tergantung validasi, dan Anda tidak ingin penundaan itu saat perpindahan.
Sebelum mempublikasikan domain, lakukan uji privat: akses endpoint baru dengan cara yang tidak bergantung pada DNS publik (misalnya menggunakan entri host sementara di mesin Anda) dan pastikan situs dimuat lewat HTTPS dengan sertifikat yang benar.
Gunakan pendekatan bertahap sehingga Anda bisa menghentikan cepat jika ada yang tidak beres:
www) sebelum mengalihkan pengguna.Jika Anda tidak bisa melakukan canary di level DNS, Anda masih bisa bertahap dengan hanya mengganti satu hostname dulu (misalnya www) dan membiarkan apex tetap hingga Anda yakin.
Tuliskan tepat apa yang akan Anda kembalikan (record mana, nilai apa), dan siapa yang akan melakukannya. Rollback biasanya mengembalikan DNS ke kondisi semula.
Pastikan pengaturan lama masih valid (termasuk SSL pada domain lama) sehingga pengguna bisa kembali dengan mulus saat Anda memperbaiki jalur baru.
Perubahan domain bukan hanya soal DNS. Untuk banyak aplikasi, “tetap login” bergantung pada cookie yang diikat oleh browser ke hostname tertentu. Jika Anda berpindah host, browser mungkin berhenti mengirim cookie lama, dan aplikasi Anda tampak telah mengeluarkan semua orang.
Pengaturan cookie biasanya penyebabnya:
app.old.com tidak akan dikirim ke app.new.com. Cookie yang diset untuk .example.com bisa bekerja di app.example.com dan www.example.com./api), UI web Anda mungkin tidak melihatnya.Lax sering cukup, tapi beberapa SSO atau redirect pembayaran mungkin memerlukan None plus Secure.Untuk mengurangi risiko, rencanakan transisi singkat di mana kedua domain tetap berfungsi. Biarkan hostname lama menjawab permintaan dan redirect dengan hati-hati, tetapi izinkan sesi direfresh di domain baru. Jika bisa, gunakan store sesi bersama sehingga pengguna yang mengakses kedua hostname dapat dikenali.
Jika Anda menggunakan SSO atau OAuth, perbarui pengaturan sebelum cutover: callback URLs, allowed origins, dan daftar allowlist untuk redirect URI. Jika tidak, login bisa berhasil di penyedia identitas tetapi gagal saat kembali ke aplikasi Anda.
Uji alur yang biasa rusak dulu: pendaftaran (dan verifikasi email), login/logout, reset kata sandi, checkout atau pengembalian pembayaran, dan sesi multi-tab.
Contoh: jika Anda mengalihkan www.example.com ke example.com, pastikan cookie diset untuk .example.com (atau konsisten menggunakan satu hostname). Jika tidak, pengguna bolak-balik antar hostname dan kehilangan sesi.
Sebagian besar masalah domain bukan “misteri internet.” Mereka adalah ketidakcocokan kecil antara DNS, sertifikat, dan aturan redirect yang baru muncul setelah pengguna nyata mengakses situs.
Satu jebakan mudah adalah domain apex (example.com). Banyak penyedia DNS tidak mengizinkan CNAME sejati di apex. Jika Anda mencoba memaksakan CNAME di apex padahal tidak didukung, itu bisa gagal diam-diam, resolve tidak konsisten, atau hanya rusak di beberapa jaringan. Gunakan apa yang didukung penyedia DNS Anda (seringkali record A/AAAA, atau record ALIAS/ANAME).
Penyebab downtime lain yang sering adalah mengganti DNS sebelum SSL siap di endpoint baru. Pengguna datang, aplikasi dimuat, lalu browser memblokir karena sertifikat hilang atau hanya mencakup sebagian hostname Anda. Dalam praktiknya, biasanya Anda ingin sertifikat mencakup example.com dan www.example.com, bahkan jika Anda berencana mengalihkan salah satunya.
Kesalahan umum yang menimbulkan outage atau perilaku aneh:
www ke apex lalu apex kembali ke www), atau memaksa HTTP di satu tempat dan HTTPS di tempat lainhttp://, yang memicu peringatan browser dan fitur yang rusakPengecekan cepat: buka kedua hostname (www dan apex) lewat HTTPS, login, refresh, dan pastikan address bar tidak pernah kembali ke HTTP.
Jika Anda melakukan ini di platform seperti Koder.ai, pastikan domain kustom terhubung dan SSL diterbitkan sebelum Anda menyentuh DNS produksi, dan siapkan opsi rollback agar redirect atau perubahan record yang buruk tidak terus menerus menyebabkan masalah.
Cutover yang tenang sebagian besar adalah kerja persiapan. Tujuannya sederhana: pengguna tetap bisa login, cookie tetap bekerja, dan Anda bisa rollback cepat jika ada yang terlihat salah.
Lakukan ini saat lalu lintas masih menuju domain lama. Beri diri Anda sehari jika bisa, agar perubahan DNS punya waktu mereda.
www, api, dll.) dan pilih metode validasi SSL (DNS atau HTTP).www ke apex (atau sebaliknya), dan satu host kanonik.Saat Anda membalik DNS, perlakukan jam pertama seperti drill insiden. Pantau alur pengguna nyata, bukan hanya dashboard status.
Bahkan jika Koder.ai (atau platform lain) menangani domain kustom dan SSL untuk Anda, daftar periksa ini tetap penting. Sebagian besar masalah berasal dari DNS dan redirect, bukan kode aplikasi.
Aplikasi Anda berjalan di alamat platform sementara seperti myapp.koder.ai. Itu berfungsi, tetapi Anda ingin pelanggan menggunakan example.com, dengan www.example.com mengalihkan ke apex, dan semuanya dipaksa ke HTTPS.
Rencana DNS sederhana menjaga risiko rendah. Sebelum mengubah apa pun, catat keadaan kerja sekarang (ambil snapshot jika platform Anda mendukungnya, seperti Koder.ai) dan turunkan TTL DNS ke nilai pendek sehari sebelumnya.
Tambahkan record baru sambil membiarkan URL platform yang ada tetap:
example.com: record A/ALIAS yang menunjuk ke target hosting yang disediakan platform Andawww.example.com: CNAME menunjuk ke example.com (atau ke target platform, tergantung penyedia)myapp.koder.ai seperti semula supaya Anda selalu punya fallback yang diketahui bekerjaSetelah DNS siap, minta SSL untuk kedua hostname (example.com dan www.example.com). Jangan alihkan lalu lintas sampai sertifikat diterbitkan dan aktif, karena itu akan menyebabkan peringatan browser.
Timeline cutover dengan checkpoint jelas:
example.com di jendela incognito (halaman depan, asset statis, panggilan API)http ke https, dan www ke apex)Setelah pindah, validasi perilaku cookie. Login, refresh, dan periksa apakah Anda tetap masuk di www dan apex. Jika sesi terputus, biasanya pengaturan domain cookie atau SameSite masih mengasumsikan host lama.
Setelah cutover berhasil, pekerjaan belum selesai. Banyak perpindahan domain gagal kemudian karena tidak ada yang memperhatikan: sertifikat mendekati masa kadaluarsa, perubahan DNS terburu-buru, atau tweak redirect yang merusak alur login.
Buat rutinitas pemantauan kecil yang benar-benar akan Anda jalankan. Anda tidak perlu alat enterprise untuk mulai, tetapi Anda butuh beberapa sinyal yang dapat dipercaya: pemeriksaan ketersediaan untuk halaman kunci (home, login, dan satu halaman terotentikasi), peringatan kadaluarsa sertifikat (mis. 30 hari dan 7 hari), pelacakan tingkat error (pantau lonjakan 4xx/5xx, bukan hanya uptime), dan validasi redirect sesekali (HTTP ke HTTPS, dan hostname yang diinginkan menang).
Simpan jendela rollback singkat, meskipun semuanya terlihat baik. Selama 24 sampai 72 jam, siapkan setup sebelumnya (target DNS lama, konfigurasi hosting lama, pengaturan TLS lama) sehingga Anda bisa cepat mengembalikan jika muncul masalah tersembunyi, seperti callback pembayaran atau penyedia OAuth yang masih menunjuk domain lama.
Setelah Anda yakin, naikkan kembali nilai TTL DNS. TTL rendah berguna saat perubahan, tetapi menambah beban ke resolver dan meningkatkan dampak kesalahan kecil di masa mendatang. Pilih TTL normal yang sesuai seberapa sering Anda mengharapkan perubahan (banyak tim memilih 1 sampai 4 jam).
Akhirnya, dokumentasikan keadaan akhir selagi masih segar: record apa yang ada (tipe, nama, nilai, TTL), hostname mana yang didukung, dan aturan redirect tepatnya. Sertakan di mana sertifikat diterbitkan, apa yang dicakup (apex, www, subdomain), dan siapa yang mengelola pembaruan.
Jika Anda membangun dan menerapkan di platform, akan membantu jika domain diperlakukan sebagai fitur kelas pertama dan rollback mudah. Di Koder.ai, domain kustom berdampingan dengan snapshot dan rollback, yang dapat membuat perubahan domain dan redirect di masa depan kurang menegangkan ketika sesuatu perlu dibatalkan dengan cepat.
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.