WordOps Adalah: Cara Kerja, Stack LEMP & Pilihan Cache

Memasang satu situs WordPress di server kosong bukan pekerjaan satu perintah. Anda perlu memasang web server, menyiapkan PHP beserta puluhan modulnya, lalu memasang database. Setelah itu barulah menulis konfigurasi virtual host (blok konfigurasi yang menentukan domain mana dilayani berkas mana), membuat pengguna database, mengunduh WordPress, dan menerbitkan sertifikat SSL. Dikerjakan teliti, rangkaian itu memakan satu sampai dua jam. Dikerjakan sepuluh kali untuk sepuluh domain, hasilnya sepuluh server yang konfigurasinya sedikit berbeda.

Persoalan itulah yang melahirkan server stack automation — perangkat lunak yang memadatkan seluruh rangkaian tadi menjadi beberapa perintah baku. WordOps salah satu yang paling banyak dipakai untuk WordPress, dan pendekatannya berbeda dari panel hosting yang mungkin sudah Anda kenal.

Perbedaannya bukan soal tampilan. WordOps tidak menaruh lapisan pengelola apa pun di atas server Anda; ia menyusun ulang server itu sendiri memakai paket dari empat sumber di luar distribusi Linux yang Anda pakai. Konsekuensinya panjang, dan sebaiknya diketahui sebelum menjalankan perintah pemasangannya.

WordOps Adalah Alat Baris Perintah, Bukan Panel Berbasis Web

WordOps adalah alat baris perintah berlisensi MIT yang memasang dan mengelola stack LEMP — Linux, Nginx, MariaDB, PHP — yang sudah dioptimasi untuk WordPress. Perangkat lunaknya ditulis dalam bahasa Python, dipasang langsung di server, dan dijalankan lewat perintah wo. Susunan LEMP sendiri adalah varian dari LAMP dengan Apache diganti Nginx.

Proyek ini merupakan fork (turunan) dari EasyEngine v3, dengan repositori publik yang berjalan sejak 12 Februari 2018 dan mengumpulkan 1.568 bintang. Versi stabil terakhirnya v3.23.1, dirilis 7 Agustus 2026.

WordOps gratis sepenuhnya: tidak ada edisi berbayar, batas jumlah situs, maupun kunci lisensi. Sebagai proyek sumber terbuka, pendanaannya datang dari donasi dan satu sponsor korporat.

Satu hal perlu diluruskan sejak awal. WordOps bukan control panel seperti cPanel atau Plesk. Tidak ada halaman web tempat Anda membuat situs, menambah akun email, atau mengatur DNS — seluruh pengelolaan berlangsung di terminal. Alamat :22222 yang sering disebut memang ada, tetapi isinya perangkat pemantau dan pengelola database, bukan antarmuka pembuat situs.

Yang Terpasang di Server Setelah Instalasi WordOps Selesai

Pemasangan berjalan dua tahap. Tahap pertama memasang perintah wo itu sendiri:

wget -qO wo wops.cc && sudo bash wo

Tahap kedua memasang stack-nya. Tanpa argumen, perintah berikut memasang tiga kelompok paket sekaligus:

sudo wo stack install

Isinya terbagi tiga jenis, dan pembagian ini menentukan berapa banyak resource yang terpakai terus-menerus:

Versi yang terpasang saat ini phpMyAdmin 5.2.0, Adminer 4.8.1, dan eXtplorer 2.1.15. Di luar daftar itu ada komponen opsional yang dipasang terpisah kalau Anda butuh, misalnya server FTP lewat wo stack install --proftpd. Yang sehari-hari melayani situs Anda hanya empat: Nginx sebagai web server, PHP-FPM sebagai penjalan kode PHP, MariaDB sebagai database, dan Redis kalau Anda memilih stack cache berbasis Redis. MariaDB adalah turunan MySQL dengan perintah yang sama persis.

WP-CLI layak disebut terpisah. Perangkat itu dipakai WordOps di balik layar setiap kali Anda membuat situs baru — mengunduh inti WordPress, membuat wp-config.php, menjalankan instalasi — dan setelahnya tersedia untuk Anda pakai langsung.

Pemasangan itu bisa dibalikkan: wo stack purge --all mencopot paketnya, lalu skrip pemasang dengan opsi --purge menghapus perintah wo. Cadangkan database lebih dulu, karena MariaDB ikut terhapus.

Nginx WordOps dan Tiga Repositori Lain yang Ikut Masuk

Inilah bagian yang paling menentukan arah pemakaian jangka panjang. Nginx yang dipasang WordOps bukan paket Nginx bawaan Ubuntu atau Debian. Yang dipasang adalah dua paket bernama nginx-custom dan nginx-wo, hasil kompilasi proyek WordOps sendiri, dengan modul tambahan yang tidak ada di paket distribusi: Brotli untuk kompresi, ngx_vts_module untuk statistik lalu lintas per vhost, serta modul srcache dan redis2 yang menjadi tulang punggung stack cache Redis.

Untuk mendapatkan paket-paket itu, WordOps menambahkan repositori APT ke server Anda. Bukan satu, melainkan empat:

1. Nginx — PPA ppa:wordops/nginx-wo di Ubuntu, atau repositori openSUSE Build Service home:virtubox:WordOps di Debian. Versi saat ini 1.30.4.
2. PHP — PPA ppa:ondrej/php di Ubuntu, atau packages.sury.org di Debian. Dari sinilah tujuh versi PHP tersedia: 7.4 sampai 8.5. Sejak 5 Agustus 2026, bawaannya PHP 8.4.
3. MariaDB — deb.mariadb.org, versi 11.4 LTS.
4. Redis — packages.redis.io, versi 7.0.

Konsekuensinya untuk Pembaruan Keamanan

Konsekuensinya berlaku selama server itu hidup. Pembaruan keamanan untuk empat komponen paling kritis tidak lagi datang dari tim keamanan distribusi, melainkan dari jadwal masing-masing penyedia repositori. Untuk PHP, MariaDB, dan Redis hal itu justru menguntungkan — ketiganya dikelola pihak yang aktif, dan versinya lebih baru daripada paket distribusi.

WordOps menambahkan empat repositori APT: Nginx-wo buatannya sendiri, PHP Ondrej, MariaDB 11.4, dan Redis 7.0.

Untuk Nginx, ceritanya berbeda. Paket nginx-wo dibangun oleh proyek WordOps sendiri, jadi kecepatan Anda menerima perbaikan kerentanan bergantung pada kecepatan proyek itu membangun ulang paketnya. Bukan kemungkinan teoretis: isu #780 meminta pemutakhiran ke Nginx 1.30.1 atau lebih baru untuk menutup CVE-2026-42945, dan isu itu masih terbuka.

Kalau kebijakan keamanan organisasi Anda mengharuskan seluruh paket berasal dari repositori resmi distribusi, WordOps tidak akan lolos audit. Empat repositori pihak ketiga adalah syarat kerjanya, bukan opsi yang bisa dimatikan.

Satu Perintah untuk Situs, Database, dan Sertifikat SSL

Setelah stack terpasang, seluruh pekerjaan menyiapkan satu situs WordPress muat dalam satu baris:

sudo wo site create example.com --wp -le

Perintah itu mengerjakan tujuh hal berurutan. Ia membuat direktori di /var/www/example.com, menulis konfigurasi vhost Nginx, lalu membuat database beserta penggunanya. Berikutnya mengunduh inti WordPress dan menjalankan instalasi lewat WP-CLI. Terakhir menerbitkan sertifikat SSL dari Let's Encrypt dan memuat ulang Nginx.

Satu perintah wo site create di WordOps mengerjakan tujuh langkah, dari membuat direktori sampai menerbitkan SSL.

Kredensial admin WordPress ditampilkan di layar setelah selesai. Kalau terlewat, nama database, pengguna, dan kata sandinya tersimpan di berkas /var/www/example.com/wo-config.php.

Dua Cara Validasi Sertifikat Let's Encrypt

Bagian SSL-nya ditangani acme.sh, bukan Certbot, dengan dua cara validasi:

• Webroot (bawaan). Domain harus sudah mengarah ke IP server; cukup tambahkan -le seperti contoh di atas.
• DNS API. Validasi lewat catatan DNS, sehingga sertifikat terbit walau domain belum mengarah ke server. Wajib untuk sertifikat wildcard (satu sertifikat untuk domain dan seluruh subdomainnya). Contoh di bawah memakai DNS API Cloudflare lewat argumen dns_cf:

sudo wo site create example.com --wp \
  -le=wildcard --dns=dns_cf

Untuk situs non-WordPress tersedia --html, --php, --mysql, serta --proxy=127.0.0.1:3000 yang menjadikan Nginx sebagai reverse proxy di depan aplikasi Node.js atau Python.

Satu hal perlu diingat kalau Anda terbiasa di hosting berbasis Apache: Nginx tidak membaca berkas .htaccess sama sekali. Aturan pengalihan atau proteksi direktori di sana tidak berpengaruh, dan tidak ada pesan kesalahan yang memberitahu. Padanannya ditulis ulang di konfigurasi vhost, yang dibuka dengan wo site edit example.com.

Sembilan Perintah wo dan Fungsinya

Seluruh pengelolaan berlangsung lewat sembilan perintah. Daftar berikut cukup untuk 95% pekerjaan sehari-hari:

Dua di antaranya sering tertukar. wo update memperbarui WordOps saja, sedangkan wo maintenance menjalankan apt update, apt dist-upgrade, lalu apt autoremove pada seluruh paket sistem — termasuk Nginx, PHP, dan MariaDB. Pembaruan itu berjalan non-interaktif dengan kebijakan --force-confold, jadi berkas konfigurasi yang sudah Anda ubah tidak akan ditimpa.

Lima Pilihan Cache WordPress di WordOps dan Konsekuensinya

Saat membuat situs WordPress, Anda menentukan mekanisme cache lewat flag. Ada lima pilihan, dan keputusan ini menempel pada situs tersebut sejak awal:

Kecuali --wpfc, semuanya menumpang plugin. Nginx Helper tetap dibutuhkan --wpfc dan --wpredis, tetapi hanya sebagai pemicu pengosongan cache, bukan sebagai mesin cache-nya.

FastCGI Cache atau Redis, Mana yang Anda Pilih

Perbedaan yang paling terasa ada di antara dua pilihan pertama. FastCGI cache bekerja seluruhnya di Nginx: halaman jadi disimpan sebagai berkas dan dikirim tanpa menyentuh PHP maupun database. Redis melakukan hal yang sama di memori, dan bisa dibagi antar-server. Untuk satu VPS dengan satu situs selisih kecepatannya kecil, sementara FastCGI lebih mudah didiagnosis saat bermasalah.

Dua stack cache WordOps: Nginx menjawab dari berkas disk (--wpfc) atau memori Redis (--wpredis), PHP dilewati.

Ada catatan yang perlu Anda perhatikan sebelum memilih --wpredis hari ini. Isu #793 dilaporkan 2 September 2026 dan masih terbuka. Isinya: stack tersebut membuat proses pekerja Nginx 1.30.4 berhenti mendadak pada setiap permintaan, dengan konfigurasi bawaan di Ubuntu 24.04. Sampai ada rilis perbaikan, --wpfc adalah pilihan yang lebih aman untuk situs produksi baru.

Backend WordOps di Port 22222 dan Isinya

Setelah stack terpasang, WordOps menampilkan sepasang kredensial dan alamat https://IP-SERVER:22222. Di baliknya bukan panel pengelola situs, melainkan vhost Nginx terpisah berisi kumpulan perangkat:

• Dashboard — grafik metrik server dari Netdata plus pintasan ke perangkat lain. Sifatnya memantau, bukan mengelola.
• phpMyAdmin dan Adminer — dua antarmuka database, satu lengkap dan satu ringan.
• eXtplorer — pengelola berkas berbasis web. Kredensial bawaannya admin/admin dan wajib diganti pada login pertama.
• OpcacheGUI, phpRedisAdmin, Webgrind, Anemometer — pemantau opcache, Redis, profil PHP, dan kueri lambat.

Pengamanannya punya dua jalur masuk, dan cukup salah satu terpenuhi. Jalur pertama daftar IP yang diizinkan, yang bawaannya hanya berisi 127.0.0.1 dan ::1. Jalur kedua HTTP Basic Auth, untuk semua IP di luar daftar itu. Tiga perintah mengaturnya:

Backend WordOps di port 22222 terbuka lewat daftar IP bawaan 127.0.0.1 atau Basic Auth; isinya phpMyAdmin dan Adminer.

# ganti nama pengguna dan kata sandi
sudo wo secure --auth

# pindahkan dari 22222 ke port lain
sudo wo secure --port

# atur daftar IP yang diizinkan
sudo wo secure --ip

Sertifikat backend bersifat self-signed, sehingga peramban menampilkan peringatan. Peringatan itu hilang begitu Anda membuat satu situs dengan -le: WordOps otomatis memakai sertifikat sah pertama yang terbit.

Syarat Server, Sistem Operasi, dan Status Debian 13

WordOps sendiri ringan; yang berat adalah layanan yang dipasangnya. Dokumentasi resmi memisahkan dua angka:

• Minimum: RAM 512 MB dan penyimpanan sekitar 100 MB. Cukup untuk mencoba, tidak cukup untuk melayani pengunjung.
• Rekomendasi produksi: RAM 2 GB, penyimpanan SSD 20 GB, dan CPU multi-core.

Empat port perlu terbuka untuk lalu lintas masuk: 22 (SSH), 80, 443, dan 22222. Satu port keluar, 1137, dipakai GnuPG saat mengimpor kunci empat repositori APT tadi. Firewall UFW bisa disiapkan otomatis dengan wo stack install --ufw.

Karena menuntut hak root dan pemasangan paket sistem, WordOps hanya berjalan di server yang Anda kelola sendiri: VPS, dedicated server, atau mesin virtual di kantor. Hosting bersama tidak memungkinkan. Bagi yang belum punya, VPS Indonesia dengan RAM 2 GB sudah memenuhi angka rekomendasi di atas.

Daftar sistem operasi yang berlaku saat ini:

Kenapa Debian 13 Belum Aman Dipakai

Skrip pemasang WordOps sudah menerima nama kode trixie, dan pesan kesalahannya menyebut Debian 13 sebagai versi yang didukung. Namun pemetaan repositori Nginx per distribusi di berkas wo/core/variables.py baru memuat buster, bullseye, dan bookworm. Isu #789 berjudul "Problem installing Wordops Debian 13" dibuka 6 Agustus 2026 dan masih terbuka.

Sampai isu itu tertutup, pilih Ubuntu 24.04 LTS atau Debian 12. Memasang di Debian 13 sekarang berarti Anda yang menambal pemetaan repositorinya sendiri.

Cara Memeriksa Versi WordOps Sebelum Memasangnya

README resmi WordOps menyatakan rilis stabilnya terbit pada bulan Juni dan Desember. Riwayat rilis yang sesungguhnya menunjukkan pola yang berbeda:

Jeda 20 bulan itu penting bukan karena proyeknya berhenti — v3.23.0 justru membawa dukungan PHP 8.5, perbaikan repositori Debian, dan penyesuaian Ubuntu 24.04. Yang perlu diperhitungkan adalah pola pengembangannya: WordOps dikelola satu pengembang utama, dengan kontribusi sesekali dari komunitas. Delapan dari sepuluh commit terakhir atas nama orang yang sama.

Rilis stabil WordOps v3.22.0 ke v3.23.0 berjarak 20 bulan, meski README menjanjikan rilis tiap Juni dan Desember.

Dua Pemeriksaan Sebelum Anda Memasang

Karena itu, dua pemeriksaan berikut layak Anda jadikan kebiasaan sebelum memasang WordOps di server produksi baru:

1. Buka halaman rilis di GitHub. Di sana tercantum changelog tiap versi. Kalau jarak dari versi terakhir sudah lebih dari setahun, bandingkan versi Nginx dan PHP yang dibawanya dengan versi terbaru masing-masing.
2. Baca daftar isu terbuka, urutkan dari yang terbaru. Isu seperti #793 dan #789 di atas menentukan sistem operasi dan mekanisme cache mana yang aman dipilih minggu ini.

Untuk pertanyaan pemakaian sehari-hari, saluran resminya adalah forum komunitas WordOps, bukan halaman isu GitHub yang khusus untuk laporan bug.

Pemeriksaan yang sama menyelamatkan Anda dari angka yang keliru. Halaman F.A.Q. resmi WordOps masih menulis versi PHP bawaannya 8.2 dan sistem operasi yang didukung Ubuntu 18.04, 20.04, dan 22.04 — ketiganya sudah tidak berlaku di kode. Untuk WordOps, repositori lebih otoritatif daripada halaman dokumentasinya.

Kelemahan dan Pertimbangan Sebelum Memilih WordOps

Lima hal berikut bukan cacat, melainkan batas cakupan yang sengaja dipilih pengembangnya:

1. Tidak ada pencadangan terjadwal. Perintah wo site memiliki sepuluh subperintah, dan backup bukan salah satunya. Pencadangan hanya berjalan saat wo site update dijalankan: konfigurasi Nginx, isi htdocs, dan dump database disalin ke direktori terpisah sebelum perubahan diterapkan. Pencadangan harian tetap Anda siapkan sendiri, misalnya lewat cron job.
2. Tidak ada pengelolaan email. Stack mail dari EasyEngine v3 dihapus saat proyek di-fork. Sendmail memang ikut terpasang, tetapi hanya agar WordPress bisa mengirim notifikasi. Email berbasis domain memerlukan layanan terpisah.
3. Tidak ada antarmuka pengelola. Pembuatan situs, penggantian versi PHP, dan penerbitan sertifikat semuanya berlangsung di terminal lewat SSH. Kalau situs dikelola bergantian oleh orang yang tidak semuanya nyaman di baris perintah, ini hambatan nyata.
4. Tidak ada isolasi antar-pengguna. Semua situs berjalan sebagai pengguna sistem yang sama, www-data. Panel hosting multi-tenant memisahkan tiap akun; WordOps tidak. Wajar untuk sekumpulan situs milik satu pihak, tidak memadai untuk menampung klien berbeda-beda.
5. Dokumentasi tertinggal dari kode. Tabel sistem operasi di halaman prasyarat masih mencantumkan Debian 10 dan belum memuat Debian 13. Setiap angka yang menentukan keputusan sebaiknya Anda cocokkan ke repositori.

WordOps vs EasyEngine v4, Webinoly, dan Panel Grafis

Tiga kelompok alternatif, masing-masing mempertukarkan hal yang berbeda:

Perbandingan dengan EasyEngine paling sering ditanyakan, dan jawabannya kerap mengejutkan. WordOps di-fork dari EasyEngine v3, yang memasang paket langsung ke sistem. EasyEngine sendiri kemudian menempuh jalan berbeda: v4 dirancang ulang di atas Docker, sehingga tiap situs berjalan di container terpisah. Keduanya masih aktif — EasyEngine merilis v4.12.0 pada 8 Juli 2026 — tetapi bukan lagi dua versi dari barang yang sama. Memilihnya berarti memilih antara paket native yang langsung terlihat di sistem, atau isolasi container dengan lapisan tambahan.

Kalau server Anda masih menjalankan EasyEngine v3, migrasinya tidak menuntut instalasi ulang. Skrip pemasang WordOps mencadangkan konfigurasi lama ke /var/lib/wo-backup, menulis vhost baru, lalu tiap situs diperbarui dengan wo site update. Satu pengecualian: situs yang dulu dibuat dengan --w3tc harus pindah mekanisme cache, karena stack itu dibuang saat fork.

Terhadap panel berbayar seperti RunCloud, pemisahnya lebih sederhana. WordOps tidak memungut biaya dan tidak menaruh apa pun di luar server Anda. Konsekuensinya, Anda kehilangan dashboard, isolasi per aplikasi, dan dukungan berbayar.

Kapan WordOps Masuk Akal dan Kapan Sebaiknya Tidak

Masuk akal kalau keempatnya terpenuhi: Anda mengelola 1 sampai 20 situs WordPress milik sendiri atau satu organisasi, nyaman bekerja lewat SSH, memakai VPS dengan RAM minimal 2 GB, dan email sudah ditangani layanan lain. Waktu penyiapan satu situs turun dari sekitar dua jam menjadi kurang dari lima menit, dan konfigurasi seluruh situs menjadi seragam.

Sebaiknya tidak kalau salah satu dari ini berlaku: pengelolanya bergantian dan tidak semua terbiasa di terminal, server menampung situs milik klien berbeda-beda, kebijakan keamanan Anda melarang repositori luar, atau Anda butuh email berbasis domain di server yang sama.

Pertanyaan yang Sering Muncul Seputar WordOps

Apa bedanya WordOps dengan EasyEngine v4?

WordOps adalah turunan EasyEngine v3 yang memasang Nginx, PHP, dan MariaDB sebagai paket sistem biasa. EasyEngine v4 ditulis ulang di atas Docker, sehingga tiap situs berjalan di container sendiri. Arsitekturnya berbeda total — bukan sekadar selisih nomor versi.

Apakah sertifikat Let's Encrypt di WordOps diperpanjang otomatis?

Ya. WordOps memasang acme.sh dengan opsi pemutakhiran otomatis, dan acme.sh menambahkan tugas cron hariannya sendiri. Anda tidak perlu menyiapkan apa pun. Untuk memaksa perpanjangan lebih awal, jalankan wo site update example.com -le=renew.

Bagaimana memindahkan satu situs ke versi PHP yang berbeda?

Satu perintah, berlaku per situs sehingga situs lain di server yang sama tidak terpengaruh:

sudo wo site update example.com --php84

Versi yang tersedia --php74 sampai --php85. Pastikan tema dan plugin situs itu sudah mendukung versi tujuan sebelum berpindah.

Kenapa perubahan halaman tidak muncul padahal sudah disimpan?

Hampir selalu karena cache halaman belum dikosongkan. Pada stack --wpfc maupun --wpredis, pengosongan otomatis dikerjakan plugin Nginx Helper. Periksa tiga hal: plugin itu aktif, opsi purge cache menyala, dan metode cache di pengaturannya sesuai dengan stack situs Anda. Untuk mengosongkan langsung dari server, jalankan wo clean --fastcgi atau wo clean --redis.

Apakah WordOps sudah bisa dipasang di Debian 13?

Belum sepenuhnya. Skrip pemasangnya menerima Debian 13, tetapi pemetaan repositori Nginx di kode inti belum memuat nama kode trixie, dan isu instalasi gagal yang dibuka 6 Agustus 2026 masih terbuka. Pakai Ubuntu 24.04 LTS atau Debian 12.

Apakah WordOps punya antarmuka grafis seperti cPanel?

Tidak. Halaman di port 22222 memang berbasis web, tetapi isinya perangkat pemantau, pengelola database, dan pengelola berkas. Tidak ada tombol untuk membuat situs, menerbitkan sertifikat, atau mengganti versi PHP — semua itu dikerjakan lewat perintah wo di terminal.

Kesimpulan

WordOps adalah alat baris perintah gratis berlisensi MIT yang menyiapkan stack LEMP siap WordPress dalam hitungan menit, lengkap dengan sertifikat Let's Encrypt dan lima pilihan mekanisme cache. Harga dari kecepatan itu adalah empat repositori pihak ketiga yang menetap di server Anda, termasuk Nginx hasil kompilasi proyeknya sendiri. Tata kelola pembaruan pun berpindah dari distribusi Linux ke jadwal masing-masing penyedia.

Pakai WordOps kalau Anda mengelola sendiri sekumpulan situs WordPress di VPS dan nyaman bekerja di terminal. Pilih panel berbasis web kalau Anda membutuhkan antarmuka grafis, isolasi antar-akun, atau pengelolaan email di server yang sama. Apa pun pilihannya, luangkan satu menit membuka halaman rilis dan daftar isu terbuka sebelum memasang. Kebiasaan itu jauh lebih murah daripada memindahkan situs yang sudah tayang.

Semoga artikel ini membantu.