Sebuah website hanya sekuat tempat ia berjalan. Topik ini mengumpulkan cara kami menyimpan dan melayani situs yang kami bangun di tbskit: di mana setiap bagian berada, bagaimana satu perubahan berjalan dari commit ke pengunjung Anda, apa yang terjadi ketika ada masalah, dan bagaimana kami menjaga biaya operasional tetap membosankan — dalam arti yang baik.
Apa arti “server” untuk situs modern
Dua puluh tahun lalu topik ini berisi mesin fisik (atau virtual) dengan web server, basis data, dan ritual menambal keamanan setiap bulan. Sebagian besar situs yang kami bangun hari ini tidak punya server untuk dimasuki sama sekali. Sisi server tetap ada, tetapi tersusun dari layanan terkelola: pipeline build, jaringan pengiriman konten (CDN), penyimpanan objek untuk media, DNS, dan TLS.
Pergeseran itu mengubah arti “operasional”. Daripada menjaga sebuah mesin tetap hidup, kami menjaga pipeline tetap bisa diprediksi: masukan sama, hasil sama, setiap kali, dengan salinan semua yang penting berada di version control.
Statis-dulu, dilayani dari edge
Selama sebuah proyek memungkinkan, kami mengirim HTML statis dan melayaninya dari jaringan edge (Cloudflare, dalam kasus kami). Untuk situs profil perusahaan atau situs konten, ini bukan kompromi — ini peningkatan:
- Tidak ada application server yang perlu ditambal, di-restart, atau di-scale. Tidak ada proses yang menunggu permintaan, jadi tidak ada yang bisa tumbang saat ramai.
- Cepat di mana pun. Halaman sudah tersimpan di dekat pengunjung, bukan dirakit per permintaan di satu mesin, di satu wilayah.
- Murah untuk tetap online. Situs yang sebagian besar mengirim berkas dari cache berbiaya beberapa dolar per bulan, bukan satu instance server per lingkungan.
Fitur dinamis tetap dibangun — formulir, pencarian, komentar, checkout — tetapi sebagai bagian kecil yang terpisah dan memanggil layanan, bukan sebagai monolit yang harus selalu hidup agar seluruh situs berfungsi.
Di mana setiap bagian berada
Setiap proyek mendapat satu dokumen singkat yang menjawab “apa berjalan di mana?”, karena tahun depan tidak ada yang ingat. Untuk situs kami, isinya biasanya seperti ini:
Build dan hosting
Sumber di Git, build pada setiap push, hasilnya dipublikasikan ke edge (Cloudflare Pages). Build adalah satu-satunya tempat situs dirakit, sehingga hanya ada satu jalur dari kode ke produksi — tanpa langkah “di laptop saya jalan, unggah folder ini secara manual”.
Media dan aset
Gambar berat disimpan di penyimpanan objek (Cloudflare R2) di belakang domain aset khusus, bukan di dalam repositori dan bukan di host yang sama dengan HTML. Repositori tetap kecil, deploy tetap cepat, dan gambar bisa di-cache ulang atau diganti tanpa menyentuh build.
DNS, TLS, dan email
DNS, sertifikat TLS, dan redirect dikonfigurasi secara deklaratif dan didokumentasikan bersama kodenya. Email sengaja dipisahkan dari hosting web: mengirim email adalah layanan dengan reputasi dan log sendiri, bukan sesuatu yang ditempelkan ke server website.
Deploy yang bisa dipercaya — dan dibatalkan
Deploy seharusnya jadi bagian paling tidak menarik dalam sepekan, jadi kami sengaja membuatnya membosankan:
- Setiap perubahan melewati pipeline yang sama, termasuk perubahan teks “kecil”. Kalau tidak melewati pipeline, ia tidak ada di produksi.
- Pratinjau sebelum produksi. Setiap branch mendapat URL sendiri, sehingga klien bisa mencoba perubahannya sebelum terbit.
- Rollback dalam satu langkah. Karena build sebelumnya masih ada, kembali ke versi lama hanya satu klik atau satu perintah — bukan kerja panik.
- Redirect hidup bersama kontennya. Halaman yang pindah mendapat 301 di dalam proyek, sehingga tautan yang sudah dikenal Google dan situs lain tetap bekerja.
Caching yang menghormati tim Anda
Caching adalah sumber sebagian besar keluhan “kok masih versi lama?”. Aturan kami:
- Berkas ber-fingerprint di-cache selamanya (
immutable), karena perubahan menghasilkan nama berkas baru, bukan versi baru dari nama lama. - HTML di-cache sebentar, sehingga pembaruan terlihat dalam hitungan menit tanpa perlu membersihkan cache.
- Media mendapat cache panjang dengan jendela stale-while-revalidate, menjaga kunjungan berulang tetap cepat sambil menyegarkan di latar belakang.
- Kami mengganti nama berkas, bukan membersihkan cache. Kalau sebuah gambar harus segera berubah, gambar diunggah dengan nama baru dan halaman diarahkan ke nama itu.
Bagian membosankan yang menjaga situs tetap online
- Pemantauan dan notifikasi untuk uptime dan build yang gagal: kalau deploy bermasalah, kami ingin tahu dari notifikasi, bukan dari email pelanggan.
- Backup dengan cerita pemulihan. Konten, redirect, dan konfigurasi ada di Git; media yang diunggah ada di penyimpanan objek. Kami menguji memulihkan halaman dari nol, karena backup yang belum pernah dipulihkan hanyalah kabar burung.
- Header keamanan dan HTTPS di semua tempat, dengan TLS dikelola dan diperbarui otomatis.
- Kredensial tetap di sisi server. API key tidak pernah masuk bundel sisi klien atau repositori publik; apa pun yang harus sampai ke browser dibatasi lingkupnya dan dirotasi.
- Dependensi ditambal sesuai jadwal, bukan hanya saat ada masalah.
Biaya dan skala tanpa kejutan
Dua pertanyaan menentukan infrastruktur: berapa biayanya saat sepi, dan apa yang terjadi pada hari trafik melonjak? Hosting edge menjawab keduanya: biaya diam hampir nol, dan hari yang ramai hanya berarti lebih banyak respons dari cache — bukan server yang lebih besar.
Kami juga mengawasi biaya yang lebih sunyi — menit build, penyimpanan gambar, layanan pihak ketiga per proyek — dan mencatatnya di dokumen serah terima, supaya situs yang tumbuh tidak diam-diam menjadi tagihan yang tumbuh.
Apa yang kami terbitkan di topik Server
Artikel di topik ini membahas satu keputusan pada satu waktu: memilih host, menyusun pipeline deploy, menangani redirect saat migrasi, strategi caching, mengirim formulir tanpa backend, dan apa yang benar-benar layak dipantau pada situs statis.
Kalau Anda ingin pendapat kedua tentang cara situs Anda berjalan sekarang — atau sedang memulai sesuatu yang baru — ceritakan proyek Anda dan kami akan memetakan apa yang sebaiknya berada di mana.
