Episode ini membahas deployment dan hosting untuk Gatsby: opsi Gatsby Cloud, Netlify, dan Vercel, build output dan deploy preview, manajemen domain dan CDN, serta cache invalidation dan workflow production.

Deployment adalah tahap di mana hasil build statis ditayangkan ke pengguna. Karena output Gatsby berupa file HTML, CSS, dan JavaScript murni, situs bisa di-host hampir di mana saja — dari platform managed hingga object storage murni.
Episode 20 membahas opsi deployment Gatsby Cloud, Netlify, dan Vercel, build output dan deploy preview, manajemen domain dan CDN, serta cache invalidation dan workflow production.
Gatsby Cloud, Netlify, dan Vercel menawarkan build terkelola: repositori dipantau, build dijalankan di cloud, dan hasilnya langsung didistribusikan melalui CDN. Ketiganya mendukung deploy preview per pull request serta environment variable per environment. Tidak ada server yang perlu dirawat — seluruh siklus deploy terjadi di infrastruktur platform.
Output public juga bisa diunggah ke bucket object storage seperti S3 atau Google Cloud Storage yang dipasangkan CDN. Opsi ini paling murah dan terkontrol, tetapi build harus dijalankan di tempat lain, misalnya CI milik kalian sendiri. Pilih jalur ini saat sudah punya infrastruktur cloud sendiri dan ingin memegang kendali penuh atas biaya. Konsekuensinya, kalian yang bertanggung jawab atas build, cache, dan pembaruan aset.
Pertimbangan memilih platform: kemudahan integrasi dengan repo, dukungan preview, kecepatan build (terutama untuk situs besar yang butuh incremental builds), dan cara menghitung biaya. Gatsby Cloud paling dekat dengan ekosistem Gatsby, sementara Netlify dan Vercel menawarkan layanan tambahan seperti forms dan edge functions. Buat daftar kebutuhan situs kalian lalu cocokkan dengan fitur tiap platform sebelum memutuskan.
Perhatikan juga biaya pindah: fitur eksklusif sebuah platform — misalnya incremental builds di Gatsby Cloud — mengikat project ke satu vendor. Pertimbangkan apakah fitur tersebut bisa diganti dengan kerja CI sendiri agar portabilitas project tetap terjaga.
gatsby build menghasilkan folder public yang berisi seluruh aset statis siap deploy:
npm run build
npx serve publicserve public menayangkan output secara lokal untuk pengujian. Folder public inilah yang diunggah ke hosting — bukan source project. Seluruh halaman, aset ber-hash, dan file penunjuk seperti 404.html sudah lengkap di dalam folder ini.
Hampir semua platform menyediakan URL preview untuk setiap pull request. Preview memungkinkan review visual sebelum perubahan di-merge, sekaligus memverifikasi bahwa build tetap sukses di cabang fitur. Biasanya URL preview muncul otomatis di halaman pull request setelah build selesai. Gunakan preview untuk mengecek konten, interaksi, dan performa dasar sebelum menyetujui merge.
Koneksikan repositori ke platform, lalu setiap push ke cabang memicu build otomatis. Ini konfigurasi yang umum di Netlify:
[build]
command = "npm run build"
publish = "public"
[build.environment]
NODE_VERSION = "20"Bagian command menjalankan build Gatsby, dan publish menunjuk ke folder public. Environment variable seperti NODE_VERSION ditentukan di sini agar versi Node konsisten.
Setelah deploy, arahkan custom domain dengan menambahkan record CNAME yang menunjuk ke domain platform. Beberapa platform menyediakan verifikasi otomatis; pastikan juga mengaktifkan HTTPS dengan sertifikat otomatis. Domain akar biasanya memakai record A atau layanan redirect platform ke versi www.
CDN menyimpan salinan aset di banyak lokasi geografis sehingga latensi mengecil. Platform managed sudah menyertakan CDN di depannya, sedangkan static hosting perlu CDN tambahan seperti CloudFront atau Cloudflare untuk performa maksimal. Efeknya terasa nyata untuk pengunjung lintas negara: konten disajikan dari edge server terdekat, bukan dari region asal. Ukur perbaikannya dengan membandingkan waktu muat dari beberapa lokasi sebelum dan sesudah CDN aktif.
Gatsby menamai aset bundle dengan hash konten, sehingga cache aset bisa bertahan lama tanpa risiko menayangkan versi lama. Halaman HTML dikirim dengan header yang tidak di-cache agar pembaruan langsung tampil.
Definisikan header cache secara eksplisit di platform. Contoh di Netlify melalui netlify.toml:
[[headers]]
for = "/*"
[headers.values]
Cache-Control = "public, max-age=0, must-revalidate"
[[headers]]
for = "/static/*"
[headers.values]
Cache-Control = "public, max-age=31536000, immutable"Cache-Control: max-age=31536000, immutable mengizinkan CDN menyimpan aset ber-hash selama satu tahun karena nama filenya berubah setiap kali konten berubah. Sementara itu, HTML memakai must-revalidate agar versi terbaru selalu diambil.
Setiap perubahan production melalui langkah yang sama: push ke cabang, build di CI, tes, deploy preview, lalu promote ke production. Otomatisasi langkah ini membuat rilis menjadi rutin, bukan momen menegangkan. Simpan catatan rilis dan pastikan setiap anggota tim tahu siapa yang boleh promote ke production. Tentukan juga strategi rollback — cara cepat mengembalikan ke versi sebelumnya bila ditemukan masalah setelah rilis.
Inti yang harus dibawa pulang:
public adalah hasil deploy Gatsby.Di episode 21 selanjutnya kita akan membahas headless CMS dan content platforms — mengintegrasikan banyak sumber konten, best practice headless setup, preview workflow, serta mengelola konten sebagai kode.