MacBook Air 2014 saya (lungsuran dari TEDDY/bukan teddy yang itu, Pak TED idolaQu) sudah dua tahun lebih cuma jadi pemberat meja. Baterainya masih hidup, layarnya masih nyala, tapi buat kerjaan sehari-hari sudah kalah jauh sama laptop yang lebih baru. Daripada dijual murah atau terus nganggur di sudut ruangan, saya coba satu eksperimen: jadiin dia server beneran bukan buat coba-coba doang, tapi buat nanggung situs WordPress yang orang beneran kunjungin setiap hari.
Hasil akhirnya: enam situs WordPress termasuk satu jaringan multisite hasil gabungan dua situs yang sebelumnya berdiri sendiri-sendiri sekarang jalan di laptop itu, 24 jam, tanpa saya bayar sepeser pun buat hosting. Tulisan ini catatan prosesnya: apa yang saya pakai, di mana saya kejeblos, dan apa yang saya pelajari sepanjang jalan.
Kenapa Nggak Beli Hosting Biasa Aja?
Pertanyaan yang wajar. Jawabannya sederhana: saya udah bayar hosting/VPS buat situs-situs ini bertahun-tahun (walaupun beberapa bulan terakhir nebeng IdolaQu yang Lain.. Koh WISNU) yang dikenal dimana-mana X AppVerse, dan laptop yang bagus-bagus spesifikasinya justru nganggur di rumah. Kalau ada cara buat manfaatin hardware yang sudah ada, kenapa nggak dicoba?
Masalahnya, internet rumahan itu nggak didesain buat jadi server. IP publiknya dinamis (bisa ganti-ganti), dan kemungkinan besar ada di belakang CGNAT artinya nggak ada cara langsung buat orang luar mengakses laptop saya lewat internet, apalagi buka port di router segala macam.
Di sinilah dua alat jadi kunci: Tailscale buat akses saya sendiri, dan Cloudflare Tunnel buat lalu lintas publik. Keduanya sama-sama nggak butuh IP publik atau port forwarding.
Langkah Pertama: Bisa Diakses dari Mana Aja
Sebelum instal apa-apa, saya perlu cara buat masuk ke laptop itu dari jarak jauh termasuk pas saya nggak lagi di rumah yang sama, atau router-nya ganti-ganti. Tailscale menyelesaikan ini dengan bikin jaringan privat sendiri (mesh VPN) antar perangkat saya, apapun jaringan fisiknya. Begitu terpasang, laptop itu punya alamat tetap di jaringan privat itu nggak peduli router rumah saya ganti IP berapa kali.
Setelah itu, tinggal SSH pakai kunci (bukan password) biar aksesnya konsisten dan aman.
Package Manager yang Bikin Kaget
Rencana awal saya pakai Homebrew buat instal semua yang dibutuhkan PHP, MariaDB, dan seterusnya. Ternyata Homebrew sudah berhenti nyediain paket biner (bottle) buat macOS Monterey, versi yang jalan di laptop ini. Kalau dipaksa, semuanya harus di-compile dari source di CPU dual-core 1.7GHz bisa berjam-jam buat satu paket saja.
Solusinya pindah ke MacPorts, yang untungnya masih nyediain instalasi resmi buat Monterey. Dari sana saya pasang PHP 8.3 (plus ekstensi-ekstensi yang dibutuhkan WordPress), dan MariaDB buat databasenya.
Menyalakan Server Web Tanpa Server Web Beneran
Buat ngelayanin situsnya, saya pakai Caddy web server modern yang konfigurasinya jauh lebih ringkas dibanding Nginx atau Apache, dan otomatis ngurusin HTTPS. Caddy yang nerima request, terus nerusinnya ke PHP-FPM buat ngejalanin WordPress, sama kayak setup LEMP pada umumnya, cuma “E”-nya (Nginx) diganti Caddy.
Dan biar lalu lintas dari internet bisa nyampe ke Caddy yang jalan di 127.0.0.1 tanpa IP publik? Itu kerjaan Cloudflare Tunnel. Tunnel-nya jalan sebagai proses kecil di laptop, bikin koneksi keluar ke Cloudflare, dan Cloudflare yang nerusin traffic dari domain publik ke laptop saya lewat koneksi itu. Nggak ada port yang perlu dibuka sama sekali — dari sudut pandang router rumah, nggak ada bedanya sama browsing biasa.
Ujian Sebenarnya: Migrasi Situs yang Beneran Hidup
Server kosong itu gampang. Yang susah itu mindahin situs yang udah ada isinya database bertahun-tahun, ribuan gambar, plugin yang saling gantung, dan yang paling penting: nggak boleh ada downtime yang kelamaan, apalagi kehilangan data.
Situs pertama yang saya pindah, kupass.com, nggak sekali jalan mulus. mysqldump di server lama ternyata cuma symlink rusak, jadi saya bikin sendiri script dump database pakai PHP dan sempat dua kali gagal gara-gara cara encoding value-nya salah (angka negatif yang di-hex-encode malah kebaca aneh sama MySQL). Begitu itu kelar, sisanya jadi pola yang bisa diulang: dump database, transfer wp-content, pasang WordPress versi baru, tempelin wp-content yang lama, benerin permission, atur Caddy dan Cloudflare Tunnel.
Setelah kupass.com jalan, saya lanjut pdmgk.org (situs organisasi dengan 19 sub-situs multisite pertama saya di sini) dan pcmponjong.id.
Pekerjaan Paling Rumit: Menggabungkan Dua Situs Jadi Satu
Bagian yang paling saya nikmatin justru yang paling rumit: www.jauhari.net dan nurudin.jauhari.net dua situs WordPress yang sebelumnya berdiri sendiri-sendiri saya gabung jadi satu jaringan multisite, dengan jauhari.net sebagai induk dan nurudin.jauhari.net sebagai sub-situs.
Masalahnya, WordPress multisite itu satu database bersama, dan tabel akun pengguna (wp_users) itu global dipakai bareng semua sub-situs. Dua situs yang tadinya independen sama-sama punya tabel wp_users sendiri-sendiri. Kalau digabung mentah-mentah, isinya bakal tabrakan.
Saya cek dulu satu-satu: ternyata cuma ada satu akun yang sama persis di kedua situs username dan emailnya identik jelas orang yang sama (saya sendiri). Akun itu digabung jadi satu, bukan diduplikat. Sisanya, satu akun penulis yang cuma ada di situs kedua, dapat ID baru di database gabungan dan setiap post, komentar, sama metadata yang tadinya nempel ke ID lama, saya remap satu-satu ke ID yang benar. Nggak ada satupun tulisan yang salah atribusi penulisnya.
Setelah database, giliran filenya: plugin dan tema yang sama nggak perlu digandakan, tinggal ambil yang unik dari situs kedua. Foto-foto dan file upload dari sub-situs dipindah ke struktur folder yang memang dipakai WordPress multisite buat non-situs-utama.
Bug yang Justru Bikin Saya Lega Ketemu
Ada satu momen yang bikin saya berhenti sejenak. Pas ngetes keamanan folder upload situs hasil gabungan tadi, saya nemu: file .php yang sengaja saya taruh di folder upload sub-situs (wp-content/uploads/sites/2/...) ternyata bisa dieksekusi padahal aturan yang saya pasang harusnya ngeblokir itu.
Ternyata pola pencocokan * di konfigurasi Caddy nggak nembus ke subfolder yang lebih dalam. Aturan blokirnya cuma jalan buat folder upload level atas, nggak sampai ke folder bersarang macam struktur multisite. Dan begitu saya cek ulang, celah yang sama juga ada di dua situs multisite lain yang sudah lebih dulu online bukan cuma yang baru.
Saya benerin sekali, di satu tempat, buat semua situs sekaligus — dan verifikasi ulang satu-satu, termasuk yang sudah lama jalan. Rasanya campur aduk: kesel karena celahnya sempat ada, tapi juga lega karena ketauan dan ketutup sebelum ada yang manfaatin.
Nggak Berhenti di “Sudah Jalan” Audit Keamanan
Situs-situs ini dulunya numpang di hosting bersama yang isinya puluhan domain orang lain. Ada risiko nyata satu situs kena serang lalu menular ke situs lain yang satu server. Jadi setelah semuanya online, saya audit ulang semuanya: cari file mencurigakan, cek akun admin yang nggak dikenal, cek apa ada yang nyusup ke database.
Sebagian besar hasilnya alarm palsu yang lucu kalau diinget lagi satu situs sempat kelihatan kena serangan gara-gara kata “cialis” muncul di kontennya, ternyata cuma potongan dari kata “specialising” (ejaan Inggris British). Tapi satu temuan beneran nyata: di salah satu situs, ada referensi ke tiga “plugin” di database yang nama file utamanya aneh dua di antaranya, meski nama foldernya beda, sama-sama pakai nama file EchoLayer.php. Plugin asli nggak pernah begitu. File aslinya sendiri sudah nggak ada (kemungkinan sempat dibersihkan sebagian di server lama), tapi jejaknya masih nyangkut di database. Saya bersihkan referensinya, dan pastikan pola yang sama nggak ada di situs lain.
Kondisinya Sekarang
Enam situs jalan stabil. Cek kesehatan server yang saya lakuin belakangan nunjukin CPU-nya masih santai (nggak ada thermal throttling sama sekali), disknya masih longgar. Yang mulai ketat justru RAM-nya dari 8GB, biasanya cuma sisa sekitar 1GB bebas pas jam sibuk. Itu jadi PR berikutnya: bukan nambah kekuatan CPU, tapi ngatur ulang berapa banyak proses PHP yang boleh jalan bersamaan, biar nggak keseringan nyentuh swap.
Kalau Kamu Mau Coba Sendiri
Nggak perlu laptop mahal buat mulai. Inti dari semua ini cuma beberapa komponen:
- Tailscale — buat kamu sendiri bisa akses laptopnya dari mana aja
- Cloudflare Tunnel — buat orang lain bisa akses situsnya lewat internet, tanpa buka port
- Caddy — web server yang ngurusin HTTPS otomatis
- MacPorts atau Homebrew — buat masang PHP dan database, sesuaikan versi macOS-nya
Yang paling penting sebenarnya bukan alatnya, tapi disiplin pas migrasi: selalu backup sebelum ubah apapun, selalu tes ulang pakai request beneran (bukan cuma asumsi “harusnya jalan”), dan jangan berhenti di titik “kelihatannya udah beres” kayak bug folder upload tadi, yang baru ketauan pas benar-benar dites, bukan cuma dibaca konfigurasinya.
Laptop yang tadinya cuma pemberat meja itu sekarang beneran kerja tiap hari. Lumayan, buat barang yang hampir saya jual murah dua tahun lalu.
