Nyoba Deploy Website ke Cloudflare Pages, Gratis dan Nggak Ribet

Ceritanya lagi bikin satu halaman sederhana berisi kumpulan tautan kantor. Satu file, isinya daftar link layanan yang sering dipakai, biar tidak usah mencari satu-satu lagi. Halaman ini saya sebut saja halaman portal.

Halaman itu saya taruh di GitHub dan saya tayangkan pakai GitHub Pages. Selama repo-nya publik, semua aman-aman saja. Alamatnya memang masih alamat bawaan GitHub, tapi yang penting bisa dibuka.

Masalahnya muncul dari keinginan yang kedengarannya sepele: saya pengin repo-nya saya privat saja. Ternyata keputusan kecil itu membuat websitenya mati. Catatan ini tentang bagaimana saya memindahkannya ke Cloudflare Pages, memasang domain sendiri, dan akhirnya repo bisa privat tanpa mematikan situsnya.

Daftar Isi

• 1. Pas Diprivat, Malah Mati
• 2. Bedanya Workers dan Pages
• 3. Urutan Pindah yang Benar
• 4. Langkah-langkah Pindahnya
• 5. Pasang Domain Sendiri
• 6. Baru Privat, Lalu Tes Ulang
• 7. Setelah Pindah: Commit Langsung Tayang
• 8. Hal yang Saya Pelajari
• 9. Penutup

1. Pas Diprivat, Malah Mati

Suatu hari saya mengubah repo portal ini dari publik menjadi privat. Saya pikir urusannya selesai di situ, tinggal pengaturan tampil atau tidak tampilnya kode.

Ternyata tidak. Beberapa saat setelah saya privat, alamat GitHub Pages-nya tidak bisa dibuka lagi. Situsnya ikut mati.

Setelah saya cari tahu, sebabnya begini: di akun GitHub gratis, GitHub Pages hanya menerbitkan situs dari repo yang publik. Repo privat yang bisa ditayangkan itu fasilitas berbayar, masuknya ke paket Pro.

Jadi pilihannya waktu itu ada tiga. Repo tetap publik, atau bayar, atau pindah hosting ke tempat yang memperbolehkan repo privat. Saya pilih yang ketiga: pindah ke Cloudflare Pages. Gratisnya dapat, repo tetap bisa privat, dan domain sendiri juga bisa dipasang di tempat yang sama.

Pelajaran pertama dari kejadian ini: jangan privat dulu sebelum rumah barunya siap. Urutannya kebalik sedikit saja, situsnya mati beneran.

2. Bedanya Workers dan Pages

Sebelum lanjut, bagian ini yang sempat membuat saya bingung lumayan lama. Di Cloudflare ada dua nama yang mirip-mirip: Workers dan Pages. Keduanya ada di menu yang sama, tapi kerjaannya beda.

Cara gampang saya mengingatnya begini:

• Pages itu etalase. Tempat menaruh file yang sudah jadi: HTML, CSS, JavaScript, gambar. Ada pengunjung datang, file itu diberikan apa adanya. Tidak ada yang berpikir, tidak ada yang mengolah.
• Workers itu petugas yang berpikir dulu. Ini kode atau program yang berjalan setiap ada permintaan datang. Dia bisa meneruskan permintaan ke tempat lain, memeriksa sesuatu, mengubah jawaban, atau memanggil layanan lain sebelum menjawab.

Kalau dibuat tabel, kira-kira begini:

Pembanding	Cloudflare Pages	Cloudflare Workers
Isinya	File statis yang sudah jadi	Kode yang berjalan tiap ada permintaan
Bisa mengolah / meneruskan permintaan?	Tidak, hanya mengirim file	Bisa, termasuk jadi proxy atau perantara
Cocok untuk	Halaman profil, landing page, kumpulan link, blog statis	API, proxy ke Apps Script, aturan redirect, pemeriksaan akses
Contoh punya saya	Halaman portal kantor di catatan ini	Sistem antrean konsultasi di catatan saya yang lain

Dari tabel itu kesimpulannya jadi jelas buat saya. Halaman portal isinya cuma daftar link, file-nya sudah jadi, tidak ada yang perlu diolah di tengah jalan. Jadi Pages saja sudah cukup, memakai Workers malah berlebihan.

Sebaliknya, sistem antrean konsultasi saya yang lain memang butuh Workers, karena di sana ada perantara yang meneruskan data ke Apps Script. Beda kebutuhan, beda alatnya.

3. Urutan Pindah yang Benar

Ini bagian terpenting dari seluruh catatan ini. Urutannya tidak boleh ditukar:

1. Pindah hosting dulu ke Cloudflare Pages (repo masih publik)
↓
2. Tes alamat sementara dari Pages sampai benar-benar hidup
↓
3. Pasang domain sendiri dan tes lagi
↓
4. BARU privat-kan repo GitHub
↓
5. Tes ulang semuanya

Intinya satu: privat itu langkah terakhir. Kalau dilakukan di awal, yang terjadi ya seperti pengalaman saya sebelumnya, situsnya mati sebelum rumah barunya jadi.

4. Langkah-langkah Pindahnya

Langkah 1: Kasih Izin ke Repo Portal

Waktu pertama mencoba, repo portal saya tidak muncul di daftar pilihan Cloudflare. Sempat bingung, ternyata sebabnya sederhana: aplikasi GitHub milik Cloudflare itu hanya diizinkan mengakses repo tertentu saja.

Di GitHub, saya buka pengaturan aplikasi Cloudflare Workers and Pages, lalu di bagian akses repository saya pilih Only select repositories. Di daftarnya waktu itu baru ada repo konsultasi saya. Repo portalnya saya tambahkan di situ, sampai daftarnya jadi dua repo, lalu saya simpan.

Repo konsultasi jangan dicabut dari daftar. Kalau dicabut, proyek yang lama bisa ikut terganggu. Menambah saja, bukan mengganti.

Langkah 2: Masuk ke Jalur Pages

Di dashboard Cloudflare, menunya sekarang ada di Compute → Workers & Pages, lalu klik Create application.

Di halaman itu ada tombol besar bertuliskan Continue with GitHub. Nah, tombol besar itu bukan yang saya klik. Tombol itu jalur Workers yang baru, nanti langkah-langkah di dalamnya berbeda.

Yang saya klik adalah tautan kecil di bagian bawah halaman: Continue to Pages. Di dekatnya ada tulisan tentang legacy Pages workflow. Memang kecil dan gampang terlewat, saya sendiri awalnya hampir salah klik yang besar.

Setelah itu pilih Import an existing Git repository, lalu pilih repo portalnya dan klik Begin setup.

Langkah 3: Isi Build Settings

Karena halaman portal ini file statis polos tanpa framework apa pun, isiannya sangat sederhana:

Project name	portal-kantor (sesuai nama repo)
Production branch	main
Framework preset	None
Build command	(kosong, tidak diisi apa pun)
Build output directory	(kosong / root, karena file HTML ada di folder utama repo)

Bagian lanjutan seperti root directory dan environment variables saya biarkan saja, tidak saya buka-buka. Setelah sama semua, klik Save and Deploy dan tunggu satu sampai tiga menit.

Kalau berhasil, muncul tulisan Success dan satu alamat sementara berakhiran .pages.dev. Punya saya alamatnya tidak persis sama dengan nama proyek, ada tambahan huruf acak di belakangnya, karena nama polosnya ternyata sudah dipakai orang lain lebih dulu. Tidak masalah, itu wajar dan memang bukan alamat utamanya. Alamat itu cuma buat ngetes.

Alamat sementara itu saya klik dan saya buka. Halamannya muncul lengkap, judul dan daftar link-nya sama seperti aslinya. Berarti pindahan hostingnya sah, bukan cuma tulisan sukses saja.

5. Pasang Domain Sendiri

Masih di halaman proyek Pages yang sama, saya masuk ke tab Custom domains, lalu klik Set up a custom domain.

Di kolom domain saya isi subdomain yang saya mau, polos saja tanpa awalan apa pun. Contohnya di catatan ini saya tulis portal.contohdomain.my.id.

Setelah klik Continue, Cloudflare menampilkan satu record DNS yang akan dibuatkan. Isinya saya periksa dulu baik-baik sebelum lanjut:

Type	CNAME
Name	portal
Content / Target	nama-project-abc.pages.dev
TTL	Auto

Karena domain induknya memang berada di akun Cloudflare yang sama, record itu dibuatkan otomatis. Saya tinggal klik Activate domain.

Statusnya awalnya tertulis Verifying. Saya tunggu beberapa menit, tidak saya utak-atik. Setelah itu statusnya berubah menjadi Active, dan alamat domain sendiri itu sudah bisa dibuka dengan HTTPS seperti website biasa.

Saran dari pengalaman saya: periksa target CNAME-nya sebelum klik Activate. Salah satu huruf saja di target itu, alamatnya bisa nyasar ke tempat lain.

6. Baru Privat, Lalu Tes Ulang

Sampai di titik ini rumah barunya sudah jadi dan alamat barunya sudah hidup. Barulah sekarang repo-nya saya privat, dengan hati yang jauh lebih tenang dibanding percobaan pertama.

Caranya: buka repo di GitHub, masuk ke Settings pada repo itu, gulir sampai paling bawah ke bagian Danger Zone, lalu di Change repository visibility pilih Make private dan ikuti konfirmasinya sampai selesai.

Habis itu langsung saya tes tiga alamat:

• Domain sendiri: hidup, terbuka normal. Ini yang paling penting.
• Alamat .pages.dev: hidup juga, isinya sama.
• Alamat lama .github.io: 404 alias mati.

Yang terakhir itu jangan panik. Justru 404 di alamat lama adalah bukti bahwa privatnya berhasil, dan alamat lama memang sudah tidak dipakai lagi. Bedanya dengan kejadian pertama: kali ini situs utamanya tidak ikut mati, karena yang menayangkan sudah Cloudflare Pages, bukan GitHub Pages.

7. Setelah Pindah: Commit Langsung Tayang

Satu hal yang saya tanyakan ke diri sendiri setelah pindah: kalau nanti saya mengubah isi link di repo, apakah saya harus deploy ulang secara manual?

Ternyata tidak. Setiap ada commit baru ke branch main, Cloudflare Pages langsung membangun dan menayangkan ulang secara otomatis. Biasanya satu sampai dua menit sudah berubah.

Enaknya jelas: edit file di GitHub, commit, selesai. Tapi konsekuensinya juga harus diingat: commit itu artinya langsung tayang ke publik. Jadi sebelum commit, periksa dulu isinya. Jangan sampai link yang belum jadi ikut terbit.

Data isi portalnya sendiri saya taruh di satu file data terpisah, isinya daftar link seperti ini. Ini contoh dummy:

{
  "links": [
    {
      "judul": "Contoh Layanan Satu",
      "url": "https://contoh-alamat-kantor.example",
      "keterangan": "Deskripsi singkat layanan"
    },
    {
      "judul": "Contoh Layanan Dua",
      "url": "https://contoh-alamat-lain.example",
      "keterangan": "Deskripsi singkat layanan"
    }
  ]
}

Dengan cara ini, kalau cuma mau menambah atau mengubah satu link, saya cukup mengubah file data itu saja. Tidak perlu mengutak-atik halaman utamanya.

8. Hal yang Saya Pelajari

• Privat dan publik pada repo itu bukan cuma soal terlihat atau tidak. Di GitHub gratis, pilihan itu ikut menentukan apakah situs GitHub Pages-nya bisa tayang.
• Urutan langkah sering lebih penting daripada langkahnya sendiri. Langkah yang sama, kalau urutannya ditukar, hasilnya bisa mati total.
• Workers dan Pages itu dua alat berbeda. Memilih yang paling sederhana dan sesuai kebutuhan biasanya lebih enak dirawat.
• Alamat sementara dari layanan hosting itu wajar kalau tidak persis sama dengan nama proyek. Alamat yang disebar ke orang tetap domain sendiri.
• Setelah pindah, selalu tes ulang semua alamat. Jangan menganggap berhasil hanya dari tulisan Success di dashboard.

9. Penutup

Sekarang halaman portal kantor ini sudah tayang dari alamatnya sendiri, repo-nya sudah privat, dan saya tidak perlu waswas lagi setiap mau mengubah pengaturan repo.

Semoga catatan ini bermanfaat, terutama buat saya sendiri kalau nanti lupa dan harus memindahkan halaman statis yang lain suatu hari nanti.

---

Disclaimer

Tulisan ini adalah catatan belajar pribadi tentang memindahkan hosting halaman portal ke Cloudflare Pages dan memasang domain sendiri, bukan tutorial resmi dan bukan panduan baku dari pihak mana pun. Saya menulis ulang pengalaman saya supaya tidak lupa, bukan karena bisa.

Prosesnya sendiri banyak dibantu AI dan diskusi bolak-balik, apalagi saat mencari sebab situsnya mati setelah repo diprivat dan saat membedakan jalur Pages dengan Workers itu. Jadi jangan dibayangkan saya sudah paham semuanya. Saya masih belajar, dan sangat mungkin ada bagian di catatan ini yang kurang tepat atau bisa diperbaiki dengan cara yang lebih baik.

Kalau ada yang membaca dan menemukan cara yang lebih rapi, saya justru senang. Yang penting bagi saya, langkahnya tercatat dan bisa dibaca lagi saat lupa, dan semoga bermanfaat juga buat yang sedang belajar hal yang sama.