Deploy Website ke Cloudflare Pages: GitHub, Build, dan Custom Domain

Website warung punya tugas sederhana: pelanggan bisa melihat menu, menemukan lokasi, dan menyiapkan pesanan tanpa menunggu lama. Bagi kami, pindah hosting juga harus sederhana. Menu dan halaman order tetap berjalan, alamat website tetap sama, dan pembaruan bisa dilakukan dari repository GitHub yang sudah ada.

Kami memilih Cloudflare sebagai tempat deployment berikutnya. Salah satu pertimbangannya adalah fleksibilitas untuk menjadikan repository private, sambil menyimpan konfigurasi GitHub Pages sebagai cadangan. Artikel ini membahas cara menyiapkan Cloudflare Pages dan pelajaran dari migrasi website Mie Ayam Pak Dul.

Catatan implementasi: deployment Pak Dul yang kami gunakan saat artikel ini ditulis adalah Workers Static Assets, dengan alamat bawaan workers.dev. Cloudflare Pages memakai alur pengaturan yang berbeda. Panduan utama di bawah ditujukan untuk Pages; konfigurasi Workers kami jelaskan dalam bagian tersendiri agar perintah deployment keduanya tidak tertukar.

Kenapa kami pindah ke Cloudflare?

GitHub Pages sudah membantu kami menjalankan website statis tanpa mengurus server. Namun, kami ingin punya pilihan menyimpan source code di repository private tanpa harus mengganti susunan website.

Cloudflare Pages mendukung repository GitHub public maupun private melalui Git integration. Pada GitHub Free, Pages tersedia untuk repository public; penggunaan Pages dari repository private tersedia pada paket GitHub tertentu. Jadi, kebutuhan menyimpan repository private menjadi salah satu alasan kami memilih hosting Cloudflare. Dokumentasi Cloudflare, ketersediaan GitHub Pages.

Repository private tetap menghasilkan website yang bisa dikunjungi publik. Pilihan ini mengatur akses ke repository, bukan menyembunyikan HTML, CSS, JavaScript, atau foto yang dikirim ke browser pelanggan.

Siapkan hasil build sebelum menghubungkan repository

Proyek kami menggunakan Vite. Artikel blog dibuat dari Markdown, foto menu diproses menjadi beberapa ukuran WebP, lalu seluruh hasil website dikumpulkan dalam folder dist.

Sebelum mengatur hosting, jalankan dari folder proyek:

npm ci
npm run build

Pada repository kami, npm run build juga menjalankan proses persiapan gambar dan blog melalui script prebuild. Setelah selesai, periksa bahwa dist memuat halaman beranda, menu, order, blog, aset, dan 404.html.

Folder itulah yang akan dipublikasikan. Mengunggah root repository begitu saja dapat melewatkan hasil optimasi atau menghasilkan halaman dengan CSS yang tidak sesuai.

Hubungkan GitHub ke Cloudflare Pages

Di dashboard Cloudflare, buka Workers & Pages, lalu pilih alur pembuatan aplikasi Pages dan hubungkan GitHub. Berikan akses aplikasi Cloudflare ke repository yang ingin dipakai.

Untuk website ini, pengaturan Pages yang sesuai adalah:

• Production branch: main.
• Framework preset: None, karena proses build sudah diatur dalam package.json.
• Root directory: root repository; jika kolom bersifat opsional, biarkan kosong.
• Build command: npm run build.
• Build output directory: dist.
• Versi Node: 24, sesuai .node-version proyek; bila perlu, tetapkan NODE_VERSION=24 pada pengaturan build.

Cloudflare Pages mengambil isi folder output setelah build selesai. Untuk Git integration Pages, tidak perlu menambahkan npx wrangler deploy sebagai perintah deployment. Setelah integrasi aktif, push ke branch produksi akan memicu build dan deployment berikutnya. Git integration, pengaturan build.

Sebelum memindahkan domain, buka alamat pages.dev yang diberikan proyek. Coba beranda, menu, order, dan sebuah alamat yang memang tidak ada. Build sukses perlu diikuti pemeriksaan hasil website.

Jika dashboard meminta deploy command: cek apakah memakai Workers

Pada setup kami, dashboard memiliki kolom Deploy command dan menjalankan npx wrangler deploy. Itu adalah alur Workers Builds. Alamat bawaan deployment kami juga berakhiran workers.dev. Konfigurasi Workers Builds.

Contoh wrangler.jsonc berikut menjelaskan bahwa yang dipublikasikan adalah aset statis dari dist, tanpa script server. Nama Worker dan domain pada contoh di artikel ini memakai nilai pengganti; sesuaikan dengan proyek Anda:

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "nama-proyek-contoh",
  "compatibility_date": "2026-10-11",
  "assets": {
    "directory": "./dist",
    "html_handling": "auto-trailing-slash",
    "not_found_handling": "404-page"
  }
}

Ganti nama-proyek-contoh dengan nama Worker Anda. Dalam package.json, script deployment dapat ditulis seperti berikut:

{
  "scripts": {
    "deploy:cloudflare": "wrangler deploy --config wrangler.jsonc"
  }
}

Build command tetap npm run build, sedangkan deploy command untuk alur ini adalah npm run deploy:cloudflare. File konfigurasi disimpan di root repository. Aset di dist harus sudah selesai dibangun sebelum deploy. Workers Static Assets.

Kami sempat mendapat pesan Error parsing file: vite.config.js pada tahap deploy, padahal build Vite berhasil. Dalam kasus kami, konfigurasi Wrangler belum ikut terkirim ke repository. Menambahkan file tersebut dan menunjuknya secara eksplisit menyelesaikan masalah. Ini pengalaman setup kami; pesan serupa di proyek lain tetap perlu diperiksa melalui lognya.

Pasang custom domain setelah alamat bawaan berfungsi

Gunakan custom domain milik sendiri, misalnya website.example.com, agar pelanggan tetap memakai alamat yang sama saat hosting berpindah.

Pada Pages, buka proyek lalu Custom domains, dan tambahkan domain yang akan dipakai. Untuk subdomain, ikuti instruksi CNAME yang diberikan Cloudflare. Kaitkan domain ke proyek terlebih dahulu; membuat CNAME saja tanpa pengaturan custom domain belum cukup. Jika DNS dikelola Cloudflare, proses pengaitan dapat membuat record yang diperlukan. Custom domain Pages.

Pada Worker yang kami gunakan, pengaitan dilakukan melalui Settings → Domains & Routes → Custom Domain. Cloudflare menyiapkan DNS dan sertifikat untuk domain yang terhubung. Custom Domain Workers.

Saat migrasi, catat konfigurasi DNS lama sebelum menggantinya. Setelah record hosting lama dilepas, pastikan domain sudah terdaftar pada proyek Cloudflare yang benar dan record baru tersedia. Periksa HTTPS sebelum menganggap pemindahan selesai.

Domain belum bisa dibuka? Bandingkan hasil DNS

Kami sempat mengalami situasi yang membingungkan: alamat bawaan Cloudflare bisa dibuka, tetapi domain utama gagal ditemukan dari jaringan tertentu.

Pemeriksaan saat itu menunjukkan DNS publik sudah menemukan domain, sementara resolver lokal masih mengembalikan hasil kosong. Ketika HTTPS diperiksa menggunakan IP dari DNS publik, beranda dan order merespons normal dengan sertifikat valid. Temuan ini mengarah ke cache hasil DNS lama setelah record sempat dihapus.

Di Windows, dua pemeriksaan berikut bisa membantu membandingkan resolver yang digunakan:

Resolve-DnsName website.example.com -Type A
Resolve-DnsName website.example.com -Type A -Server 1.1.1.1

Untuk membersihkan cache DNS Windows:

ipconfig /flushdns

Jika perbedaannya tetap ada, coba jaringan lain. Cache pada router atau resolver ISP tidak selalu ikut bersih ketika cache Windows dibersihkan. Dalam kondisi ini, mengubah kode website atau menjalankan build berulang kali tidak menyelesaikan penyebabnya.

Bawa halaman 404 dan periksa cache

Kami menambahkan public/404.html yang ikut disalin ke dist/404.html. Halaman ini memberi pelanggan jalan kembali ke menu atau beranda ketika membuka alamat yang salah.

Pages memakai file 404.html untuk respons halaman yang tidak ditemukan. Tanpa file 404 di root, Pages dapat memperlakukan proyek sebagai aplikasi satu halaman dan mengirim halaman utama untuk path yang tidak cocok. Website Pak Dul memiliki beberapa halaman HTML, sehingga respons 404 yang jelas sesuai dengan susunannya. Perilaku halaman Pages.

Kami juga menyimpan aturan header di public/_headers. HTML dapat diperiksa ulang, sedangkan CSS dan JavaScript dengan nama berbasis hash bisa disimpan lebih lama. Foto yang belum memakai nama berbasis hash memiliki kebijakan cache tersendiri.

Ketika ada konten lama setelah deploy, periksa juga Cache Rules pada domain. Aturan yang memaksa HTML disimpan terlalu lama dapat menutupi versi baru. Purge cache bila diperlukan, lalu pastikan browser memuat aset dari deployment yang dimaksud. Cache dan penyajian Pages.

Ukur pengalaman pelanggan setelah migrasi

Pada pengujian mobile tanggal 12 Oktober 2026, domain utama kami mendapat Performance 98, dengan Accessibility, Best Practices, dan SEO masing-masing 100. FCP tercatat 1,5 detik, LCP 2,3 detik, blocking JavaScript 0 ms, dan pergeseran layout 0. Anda dapat menguji website sendiri melalui PageSpeed Insights.

Angka tersebut adalah hasil satu pengujian. Kami juga mendapat hasil berbeda pada pengujian sebelumnya, sehingga skor itu bukan jaminan bahwa setiap kunjungan akan sama cepatnya. Migrasi hosting berjalan bersama optimasi gambar dan animasi; kami tidak menganggap seluruh perubahan skor berasal dari Cloudflare saja.

Pemeriksaan yang lebih dekat dengan kebutuhan pelanggan tetap penting: foto menu muncul, catatan pesanan tersimpan, total mudah ditemukan, dan tombol pemesanan menyiapkan pesan WhatsApp yang benar.

Simpan jalur kembali ke GitHub Pages

Kami mempertahankan workflow GitHub Pages dan file CNAME di repository sebagai cadangan. Pengaturan hosting di dashboard dapat dinonaktifkan sementara tanpa menghapus file konfigurasi tersebut.

Jika ingin kembali, aktifkan Pages dengan sumber GitHub Actions, pastikan paket akun mendukung visibilitas repository yang dipakai, lalu jalankan workflow build dan deployment. Setelah hasilnya siap, pindahkan pengaitan domain serta DNS dari Cloudflare hosting ke GitHub Pages.

Konfigurasi yang tersimpan tetap memerlukan pengaktifan hosting dan pengaturan domain ketika dipakai lagi. Dengan begitu, keputusan pindah hosting punya jalan kembali yang jelas, sementara pelanggan tetap menggunakan alamat website yang sama.