Penyiapan domain kustom untuk aplikasi web: DNS, SSL, dan pemindahan

Apa yang berubah saat pakai domain kustom (dan apa yang bisa salah)

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:

• Routing DNS: pengguna berhenti menuju hostname lama dan mulai menuju target yang ditunjuk DNS Anda.
• TLS/SSL: sertifikat harus cocok dengan hostname baru, dan harus aktif sebelum pengguna nyata datang.
• Redirects: Anda menentukan apakah pengguna mendarat di www atau domain apex, dan perlu aturan konsisten dari HTTP ke HTTPS.
• Cookie dan sesi: cookie dibatasi per domain. Cookie login untuk old-platform.example tidak otomatis bekerja di app.yourdomain.com.
• Caching dan propagasi: resolver DNS dan browser menyimpan hasil, jadi tidak semua orang beralih pada saat yang sama.

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.

Tentukan domain dan hostname sebelum mengotak-atik DNS

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.

Ketahui siapa yang benar-benar mengontrol 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:

• Hostname utama (apex atau www) dan arah redirect
• Subdomain yang dibutuhkan sekarang (app, api, admin) vs ide untuk nanti
• Tempat DNS dihosting dan siapa yang bisa mempublikasikan perubahan
• Record penting yang ada (MX, SPF, DKIM, DMARC, TXT verifikasi)
• Ekspektasi cookie dan otentikasi (satu host vs berbagi antar subdomain)

Jika tim marketing sudah menjalankan email di example.com, biarkan record terkait email tidak tersentuh saat Anda hanya menambahkan yang dibutuhkan aplikasi.

Record DNS yang akan Anda gunakan dan kenapa penting

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.

Record inti (A, CNAME, dan lainnya)

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:

• A: name -> IP (langsung)
• CNAME: name -> name (alias)
• TXT: name -> text (bukti dan kebijakan)
• MX: name -> mail servers (jangan sentuh kecuali memang ingin)

TXT: verifikasi, SSL, dan keamanan email

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: kenop “kecepatan perubahan” Anda

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.

Hindari menimpa record yang ada, dan dokumentasikan rollback

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.

Penerbitan SSL: validasi, timing, dan cakupan

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 HTTP menempatkan file sementara atau respons pada URL tertentu di aplikasi Anda.
• Validasi DNS TXT menambahkan record TXT di zona DNS Anda.

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.

Timing dan pengulangan

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:

• Turunkan TTL sehari sebelumnya agar perubahan lebih cepat berlaku.
• Tambahkan record validasi lebih awal (DNS TXT atau token HTTP).
• Tunggu hingga sertifikat menunjukkan status diterbitkan untuk semua hostname.
• Baru kemudian arahkan lalu lintas ke target baru.

Cakupan: pastikan hostname yang tepat termasuk

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.

Aturan redirect: www, apex, HTTP ke HTTPS, dan default aman

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:

• Satu host kanonik, dengan satu redirect 301 dari host lainnya
• Redirect 301 dari http:// ke https:// untuk setiap permintaan
• Pertahankan path dan query string penuh saat redirect (deep link harus tetap bekerja)
• Redirect hanya sekali (hindari rantai seperti http -> https -> www)

Untuk 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.

Rencana cutover bertahap berisiko rendah (tanpa downtime)

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.

1) Persiapkan dan uji sebelum menyentuh DNS produksi

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.

2) Cutover dalam langkah kecil yang bisa dibalik

Gunakan pendekatan bertahap sehingga Anda bisa menghentikan cepat jika ada yang tidak beres:

• Turunkan TTL lebih awal, lalu tunggu sampai periode TTL sebelumnya benar-benar lewat.
• Selesaikan verifikasi domain di host Anda dan konfirmasi domain mengarah ke aplikasi yang benar secara internal.
• Konfirmasi SSL aktif untuk setiap hostname yang akan Anda layani (apex dan/atau www) sebelum mengalihkan pengguna.
• Ubah DNS secara terkendali: mulai dari subdomain, satu wilayah kecil, atau rute audiens terbatas jika memungkinkan.
• Biarkan domain lama online dan mengalihkan sementara Anda memantau lalu lintas dan tingkat error stabil.

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.

3) Rencanakan rollback saat Anda masih tenang

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.

Hindari cookie, sesi, dan otentikasi yang rusak setelah perpindahan

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:

• Domain menentukan hostname mana yang bisa menerima cookie. Cookie yang diset untuk 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.
• Path membatasi di mana cookie dikirim. Jika terlalu sempit (mis. /api), UI web Anda mungkin tidak melihatnya.
• Secure berarti cookie hanya dikirim lewat HTTPS. Setelah beralih ke HTTPS-only, permintaan HTTP tidak akan menyertakannya.
• SameSite memengaruhi redirect lintas situs dan alur ter-embedded. 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.

Kesalahan umum yang menyebabkan outage atau perilaku aneh

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:

• Mengubah DNS tanpa menurunkan TTL terlebih dahulu, lalu menunggu berjam-jam agar jawaban lama kadaluarsa
• Menjaga aturan redirect yang membuat loop (www ke apex lalu apex kembali ke www), atau memaksa HTTP di satu tempat dan HTTPS di tempat lain
• Mengirim konten campuran dengan meng-hardcode asset http://, yang memicu peringatan browser dan fitur yang rusak
• Lupa record DNS non-web, terutama MX dan TXT, yang dapat merusak email dan verifikasi domain
• Menguji hanya satu browser dan melewatkan cache HSTS atau keanehan cookie yang akan dialami pengguna lain

Pengecekan 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.

Daftar periksa cepat sebelum, selama, dan setelah cutover

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.

Sebelum cutover

Lakukan ini saat lalu lintas masih menuju domain lama. Beri diri Anda sehari jika bisa, agar perubahan DNS punya waktu mereda.

• Turunkan DNS TTL (untuk record yang akan diubah) dan tulis nilai sekarang agar bisa dipulihkan cepat.
• Dokumentasikan setiap hostname yang akan Anda layani (apex, www, api, dll.) dan pilih metode validasi SSL (DNS atau HTTP).
• Siapkan aturan redirect dan uji di staging: HTTP ke HTTPS, www ke apex (atau sebaliknya), dan satu host kanonik.
• Perbarui pengaturan auth yang tergantung URL tepat: callback OAuth, allowed origins, pengaturan domain cookie, dan konfigurasi SSO apa pun.
• Tentukan siapa yang memantau selama cutover (log, cek uptime, inbox support) dan tetapkan jendela perubahan singkat.

Saat dan setelah cutover

Saat Anda membalik DNS, perlakukan jam pertama seperti drill insiden. Pantau alur pengguna nyata, bukan hanya dashboard status.

• Saat: pantau lonjakan 4xx/5xx, loop redirect, dan kegagalan login (terutama "invalid redirect URI" atau penurunan sesi mendadak).
• Setelah: konfirmasi rantai sertifikat valid di beberapa browser dan bahwa halaman penting dimuat lewat HTTPS tanpa konten campuran.
• Setelah: verifikasi perilaku host kanonik (hanya satu host yang muncul di address bar) dan bahwa cookie kritis diset dan dikirim.
• Setelah: biarkan domain lama mengalihkan untuk sementara. Banyak pengguna akan kembali lewat bookmark lama, email, atau link yang tersimpan.

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.

Contoh skenario: pindah dari URL platform ke domain kustom

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 Anda
• www.example.com: CNAME menunjuk ke example.com (atau ke target platform, tergantung penyedia)
• Biarkan myapp.koder.ai seperti semula supaya Anda selalu punya fallback yang diketahui bekerja

Setelah 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:

• T-24h: turunkan TTL, konfirmasi Anda bisa rollback cepat
• T-0: aktifkan domain di host aplikasi, verifikasi SSL siap
• T+15m: uji example.com di jendela incognito (halaman depan, asset statis, panggilan API)
• T+30m: aktifkan redirect (http ke https, dan www ke apex)
• Momen rollback: jika login atau panggilan API gagal, kembalikan DNS ke target sebelumnya dan biarkan URL platform tetap hidup

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.

Langkah selanjutnya: pantau, dokumentasikan, dan buat perubahan masa depan lebih aman

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.