Deploy ke servermu sendiri berarti memberi agen akses setara SSH ke sebuah mesin yang kamu bayar, yang mungkin sudah dihuni oleh hal lain. Itu tingkat kepercayaan yang berbeda dibanding mempublikasikan ke subdomain gratis, dan penyiapannya mencerminkan itu — beberapa kolom, diisi sekali, lalu setiap build setelahnya tinggal satu tombol. Berikut yang sebenarnya ditanyakan orang sebelum dan sesudah menyambungkannya.
Apa yang saya butuhkan untuk membuat target?
Lima hal, di Settings → Deploy:
- Nama yang akan kamu kenali nanti — "prod-vps", "client-hostgator", apa pun yang masih bisa dikenali di dropdown pukul 11 malam
- Host dan port
- Kredensial SFTP
- Path webroot
Tidak ada token API, tidak ada CLI yang perlu diinstal di server, tidak ada cron job yang perlu diawasi. Jika hostmu menyediakan akses SFTP — yang mencakup hampir semua shared hosting, semua VPS, semua box WordPress terkelola — kamu selesai dalam sekitar dua menit.
Password atau key?
Key, jika hostmu mendukungnya. Password bekerja dengan baik dan kami menyimpannya secara terbatas pada akunmu, tapi key berarti satu rahasia lebih sedikit yang tersimpan di mana pun — perbedaan antara "cabut satu key" dan "reset password di mana-mana yang kebetulan memakai password itu ulang" jika terjadi sesuatu nanti. Banyak setup SFTP shared-hosting murah hanya menawarkan autentikasi password, dan itu juga tidak masalah. Cukup jangan pakai ulang password itu di tempat lain.
Bagaimana cara menemukan path webroot yang benar?
Ini adalah kolom yang sering salah dipahami orang pada percobaan pertama, karena jawaban yang salah tetap terlihat masuk akal. Ini bukan home directory Anda, dan bukan /var/www — ini adalah folder tepat tempat web server Anda dikonfigurasi untuk menyajikan konten.
| Server | Webroot khas |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html — atau suatu path yang dinamai oleh developer sebelumnya tiga tahun lalu karena alasan yang tidak diingat siapa pun lagi |
Jika Anda tidak yakin, letakkan sebuah file sekali pakai test.txt ke dalam folder yang Anda kira benar menggunakan klien SFTP mana pun, lalu periksa apakah file itu bisa dimuat di yoursite.com/test.txt. Jika ini salah, deploy tetap akan melaporkan berhasil — agent dengan setia menulis file ke folder yang salah, dan Anda ditinggalkan menatap situs live yang tidak berubah, bertanya-tanya kenapa.
Bisakah satu target mencakup lebih dari satu domain?
Bisa, dan inilah bagian yang menghemat banyak waktu setelah kamu melewati situs pertamamu. Satu target adalah satu server dan satu set kredensial — tidak terikat pada satu domain saja. Di Domain Management kamu melampirkan setiap domain ke sebuah target dengan override webroot-nya sendiri. Menjalankan tiga situs dari satu VPS dengan server block Nginx?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
Satu target, tiga lampiran. Kamu tidak memasukkan ulang password SSH tiga kali, dan kamu tidak mengelola tiga target yang hampir identik yang bisa jadi tidak sinkron pada hari kamu merotasi key dan lupa salah satunya. Klik deploy pada salah satu dari tiga domain itu dan sistem sudah tahu server dan folder mana — kamu tidak perlu memilihnya saat deploy.
Apa yang sebenarnya dilakukan agen saat terhubung?
Pertama, ia melihat-lihat sekitar — hanya baca, belum ada yang ditulis. Pemeriksaan itu memeriksa:
- Folder kosong
- Versi sebelumnya dari build yang persis sama
- Instalasi WordPress lama
- Placeholder "coming soon" yang secara default ditaruh oleh hostmu di sana
Itu menentukan strateginya. Webroot kosong mendapat unggahan langsung. Webroot yang sudah berisi sesuatu ditangani lebih hati-hati, karena banyak setup sungguhan memiliki hal-hal yang hidup berdampingan dengan situs yang tidak boleh hilang:
- A
.well-knownfolder untuk validasi SSL - Sebuah
uploadsdirektori yang tidak dimasukkan siapa pun ke git - A
wp-config.phpyang tidak boleh disentuh siapa pun
Tugas di sini lebih mendekati "cari tahu apa yang berubah dan rekonsiliasikan" daripada "hapus dan ganti."
Kemudian, sebelum satu byte pun ditimpa, webroot yang ada diambil sebagai versi di hostmu sendiri. Bukan catatan database, bukan diff yang kami hitung dan harap benar — melainkan snapshot sungguhan dari apa yang ada di sana. Ini paling penting pada deploy pertama ke target mana pun, karena deploy itu selalu mendarat di atas sesuatu, bahkan jika sesuatu itu tidak ada apa-apanya. Folder kosong, snapshot kosong. Situs statis berumur lima tahun yang tidak ada yang ingat pernah membuatnya — dipertahankan persis apa adanya, gratis, sebelum disentuh. Deploy pertama itu juga yang paling tidak kamu yakini, jadi itulah yang paling penting di sini.
Apakah ia mengunggah kode sumberku atau situs yang sudah dibangun?
Situs yang sudah di-build, selalu. Untuk situs statis, itu berarti halaman yang sudah dihasilkan. Untuk build framework — Next.js, Vite, apa pun yang dibutuhkan jenis situs tersebut — itu adalah output hasil kompilasi, folder dist atau build , bukan pernah source tree. Saya rasa ini keputusan yang tepat meskipun artinya Anda tidak bisa SSH masuk dan menjalankan npm run dev terhadap apa yang ada di server. Mengunggah source berarti webroot produksi Anda membutuhkan runtime Node dan toolchain build hanya untuk menyajikan HTML — mengubah server shared hosting yang sama sekali tidak dirancang untuk menjalankan pipeline build menjadi seperti itu, dan mengubah setiap deploy menjadi "berharap server punya cukup memori untuk menyelesaikan npm install." Mengirim hanya output hasil kompilasi menjaga webroot tetap persis seperti yang diharapkan oleh server file statis. Membosankan. Membosankan itulah yang Anda inginkan di jam 2 pagi ketika ada yang salah dan Anda sedang menatap folder itu berusaha memahami apa sebenarnya yang sedang disajikan.
Bagaimana saya tahu deploy benar-benar berhasil?
Setelah unggahan, agent mengakses URL live dan memeriksa apakah URL tersebut bisa dimuat — bukan error 500, bukan halaman kosong. Apa pun yang ditemukannya, ditambah hal apa pun yang diperhatikannya saat inspeksi yang ingin dimintakan pendapat Anda ("webroot ini memiliki folder wp-content yang saya biarkan tidak tersentuh, konfirmasi bahwa itu memang seharusnya begitu"), masuk ke thread chat build tersebut. Itulah pola di seluruh platform ini: tidak ada keberhasilan diam-diam, tidak ada kegagalan diam-diam yang berujung menjadi tiket support. Agent memberi tahu Anda apa yang dilihatnya dan apa yang diputuskannya, di thread yang sama tempat Anda meminta build tersebut.
Apa sebenarnya isi riwayat versi?
Setiap deploy menambahkan sebuah versi — bukan hanya build pertama. Jadi riwayatnya bukan sekadar build Anda yang diplot terhadap garis waktu abstrak; ini adalah urutan literal dari apa yang pernah disajikan dari webroot tersebut, secara berurutan, dimulai dari apa pun yang ada di sana sebelum Anda hadir. Versi satu selalu merupakan kondisi pra-platform tersebut, yang diambil secara otomatis. Anda tidak perlu memikirkannya.
Apa sebenarnya yang dipulihkan oleh revert?
Versi live sebelumnya, persis — bukan menjalankan ulang build lama, bukan pendekatan mendekati. File-file sebenarnya yang sedang melayani traffic sebelumnya. Ini adalah jaminan yang jauh lebih kuat dibanding kebanyakan fitur "rollback" yang pernah saya pakai di tempat lain, yang biasanya berarti "deploy ulang dari commit lama" dan diam-diam mengasumsikan proses build Anda deterministik dan environment Anda tidak berubah sejak itu. Di sini, revert adalah pemulihan dari snapshot yang sudah diketahui baik-baik saja, itulah sebabnya aman digunakan saat sedang dalam tekanan — Anda tidak perlu memikirkan apakah rollback akan berperilaku berbeda dari hal yang sedang di-rollback.
Dan saat Anda benar-benar membutuhkannya tidak pernah dalam keadaan tenang; selalu "build baru merusak checkout dan traffic sedang live sekarang."
Satu klik, versi sebelumnya dipulihkan, selesai. Alasan di balik memperlakukan ini sebagai fitur utama dan bukan sekadar tambahan ada di Iterasi tanpa rasa takut — layak dibaca sekali, sebelum Anda membutuhkannya. Baik riwayat maupun kontrol pemulihan ada di build card dan di tampilan riwayat target itu sendiri.
Apakah ini juga mencadangkan database saya?
Tidak, dan saya lebih memilih mengatakannya dengan jelas daripada membiarkan siapa pun berasumsi lain. Riwayat versi di host mencakup apa yang ditempatkan oleh pipeline deploy ini di webroot. Jika situs Anda memiliki database, atau unggahan pengguna, atau hal lain yang berubah di luar proses deploy, itu adalah masalah yang sepenuhnya terpisah — revert tidak menyentuhnya dan jangan disalahartikan sebagai strategi backup untuk itu.
