Kapan Bisnis Butuh Headless CMS seperti Directus?

Tim marketing ingin mengubah harga promo. Harga itu tampil di website, di aplikasi Android, dan di layar menu digital di toko. Dengan sistem yang terpisah-pisah, satu perubahan berarti tiga kali kerja dan tiga kesempatan salah ketik. Di titik seperti inilah headless CMS mulai masuk akal: konten disimpan di satu tempat, lalu dikirim ke semua kanal yang membutuhkan.

Headless CMS adalah sistem pengelola konten yang tidak punya "kepala", yaitu lapisan tampilan. Ia menyimpan dan mengelola konten, lalu menyajikannya lewat API (REST atau GraphQL). Website, aplikasi, atau perangkat lain mengambil konten itu dan menampilkannya dengan caranya sendiri.

Bedanya dengan CMS tradisional

CMS tradisional seperti WordPress menyatukan tiga hal dalam satu sistem: tempat menulis konten, database, dan tema yang menampilkannya sebagai halaman web. Kamu menulis artikel, menekan terbitkan, dan halamannya langsung jadi. Untuk satu website, pola ini sangat praktis.

Headless CMS hanya mengambil dua bagian pertama. Tampilan dibuat terpisah oleh developer, misalnya dengan framework JavaScript seperti Next.js, Nuxt, atau Astro, atau langsung di aplikasi mobile. CMS tidak tahu dan tidak peduli konten akan tampil di mana.

Pemisahan ini membawa keuntungan dan beban sekaligus. Keuntungannya, frontend bebas dibangun dengan teknologi apa pun dan konten bisa dipakai ulang di banyak tempat. Bebannya, ada dua sistem yang harus dibangun, dihosting, dan dirawat, bukan satu.

WordPress sendiri juga bisa dipakai secara headless lewat REST API bawaannya. Jadi pilihannya bukan selalu "WordPress atau headless", melainkan pola mana yang dipakai.

Kapan sebuah bisnis benar-benar butuh headless?

Beberapa situasi yang biasanya jadi alasan kuat:

• Banyak kanal, satu sumber konten. Website, aplikasi mobile, kios, atau layar digital mengambil data produk, harga, dan artikel yang sama.
• Frontend khusus. Tim sudah punya developer yang ingin membangun tampilan dengan framework modern, dengan kontrol penuh atas performa dan desain.
• Konten sebagai data terstruktur. Kontennya bukan sekadar artikel, melainkan katalog, jadwal, lokasi cabang, atau data lain yang punya banyak relasi.
• Aplikasi internal. Panel admin untuk data operasional yang dipakai beberapa aplikasi sekaligus.

Sebaliknya, untuk website company profile, blog bisnis, atau landing page yang dikelola satu dua orang tanpa developer tetap, headless biasanya berlebihan. CMS tradisional atau bahkan website statis sudah cukup, seperti dibahas di static site generator dan blog bisnis Ghost vs WordPress.

Directus, Strapi, dan Payload sebagai contoh

Ketiganya bisa dipasang di server sendiri, tetapi gaya kerja dan lisensinya berbeda, jadi cocok untuk tim yang berbeda pula.

Directus menonjol untuk kasus "database dulu". Bila bisnismu sudah punya database PostgreSQL atau MySQL dengan data produk atau pelanggan, Directus bisa menampilkannya sebagai panel admin yang rapi dan API tanpa memindahkan data. Ini membuatnya sering dipakai sebagai back office, bukan hanya CMS website. Perbedaan dua database populer itu dibahas di PostgreSQL vs MySQL.

Strapi lebih dekat dengan cara kerja CMS pada umumnya: kamu membuat tipe konten seperti "Artikel" atau "Produk" lewat antarmuka, lalu API-nya tersedia otomatis. Payload cocok untuk tim yang lebih nyaman mendefinisikan semuanya di kode dan sudah memakai Next.js.

Perhatikan bahwa Directus bukan lisensi open source klasik seperti MIT. Ketentuannya untuk pemakaian komersial dan batas tier gratis bisa berubah, jadi baca file lisensi resmi masing-masing produk sebelum memilih.

Biaya tambahan yang sering tidak dihitung

Headless CMS yang bisa dipasang sendiri memang gratis diunduh (dengan ketentuan lisensi masing-masing), tetapi total biayanya biasanya lebih tinggi daripada CMS tradisional untuk website sederhana.

Pertama, frontend harus dibangun. Tidak ada tema siap pakai yang tinggal dipasang seperti di WordPress. Setiap halaman, formulir, dan tampilan pratinjau perlu dikerjakan developer.

Kedua, ada dua tempat hosting. CMS dan database berjalan di satu server, frontend di server atau layanan hosting lain. Keduanya perlu dipantau, diperbarui, dan di-backup.

Ketiga, fitur yang di CMS tradisional sudah ada harus dibuat atau dirangkai sendiri: pratinjau sebelum terbit, peta situs, pengaturan SEO per halaman, pencarian, dan formulir. Editor konten juga perlu waktu adaptasi karena yang mereka sunting adalah data, bukan halaman yang langsung terlihat.

Keempat, ketergantungan pada developer. Perubahan tampilan yang di WordPress bisa dilakukan lewat editor, di sistem headless sering berarti perubahan kode.

Memasang headless CMS di server sendiri

Bila kebutuhannya memang ada, memasang Directus atau Strapi di VPS adalah jalan yang umum. Caranya sedikit berbeda: dokumentasi Directus menyebut Directus disediakan sebagai image Docker, sedangkan dokumentasi Strapi menyatakan Strapi tidak membuat image container resmi, jadi kamu menyusun Dockerfile sendiri dengan panduan dari dokumentasinya. Pengetahuan dasar container membantu, dan pengantarnya ada di apa itu Docker. Yang perlu disiapkan: database, penyimpanan file untuk gambar dan dokumen, HTTPS, serta backup rutin database.

Mulailah dari satu kasus kecil, misalnya katalog produk yang dipakai website dan aplikasi, sebelum memindahkan semua konten. Dengan begitu tim bisa menilai apakah alur kerja baru benar-benar lebih ringan.

Headless CMS bukan versi "lebih canggih" dari CMS biasa. Ia jawaban untuk masalah tertentu: konten yang dipakai banyak kanal, dikelola tim yang punya developer. Untuk satu website yang dirawat tim kecil, CMS tradisional tetap lebih hemat.