---
title: "Cara Deploy Tanpa Downtime dengan Blue-Green di VPS"
description: "Pola blue-green di satu VPS: dua salinan aplikasi, Nginx sebagai pengalih, cek kesehatan sebelum pindah, rollback instan, dan jebakan migrasi database."
url: "https://nivelva.com/insight/cara-deploy-downtime-blue-green-vps"
category: "Server \u0026 Infrastruktur"
tags: ["blue-green deployment","zero downtime","nginx","deploy","vps"]
author: "Lucas Tan"
published: "2026-11-11T12:51:00+07:00"
updated: "2026-11-11T12:51:00+07:00"
language: "id"
publisher: "Nivelva (https://nivelva.com)"
---

# Cara Deploy Tanpa Downtime dengan Blue-Green di VPS

> **Jawaban singkat:** Blue-green berarti menjalankan dua salinan aplikasi, satu melayani pengunjung dan satu menerima versi baru. Setelah versi baru lolos cek kesehatan, Nginx dialihkan ke salinan itu dengan reload yang tidak memutus koneksi. Salinan lama dibiarkan hidup untuk rollback cepat.

Bayangkan kamu baru selesai memperbaiki bug di aplikasi pemesanan, lalu menjalankan deploy jam dua siang. Selama aplikasi di-restart, beberapa pelanggan melihat halaman error 502. Lalu ternyata versi baru punya masalah lain, dan kamu harus mengulang semuanya ke versi lama sambil pelanggan menunggu. Deploy di jam sepi bisa mengurangi dampaknya, tapi tidak menghilangkannya.

Pola blue-green mengatasi dua masalah itu sekaligus. Kamu menjalankan dua salinan aplikasi: "blue" yang sedang melayani pengunjung dan "green" yang menerima versi baru. Pengunjung baru dipindahkan setelah green terbukti sehat. Kalau ada masalah, pindahkan kembali ke blue dalam hitungan detik. Pola ini tidak butuh Kubernetes atau load balancer mahal. Satu VPS dengan Nginx sudah cukup.

## Gambaran susunannya di satu VPS

Aplikasi dijalankan dua kali di port berbeda, misalnya blue di `127.0.0.1:8001` dan green di `127.0.0.1:8002`. Keduanya membaca kode dari folder berbeda, misalnya `/srv/app/blue` dan `/srv/app/green`. Nginx berdiri di depan dan hanya meneruskan trafik ke salah satunya.

Pola ini cocok untuk aplikasi yang berjalan sebagai proses sendiri: Node.js, Python dengan Gunicorn, Go, Java, atau aplikasi di container Docker. Masing-masing salinan bisa dijalankan sebagai layanan systemd terpisah, misalnya `app@blue.service` dan `app@green.service` dari satu template. Cara membuat layanan seperti itu dibahas di [panduan service systemd](https://nivelva.com/insight/membuat-service-systemd).

Untuk PHP biasa yang dilayani PHP-FPM, prinsipnya sama tapi bentuknya berbeda: biasanya dua folder rilis dan sebuah symlink `current` yang dialihkan, ditambah reload PHP-FPM.

Ada satu syarat yang mudah terlupa. RAM harus cukup untuk menjalankan dua salinan sekaligus, setidaknya selama proses perpindahan.

## Nginx sebagai sakelar

Buat file kecil yang isinya hanya alamat salinan yang aktif, misalnya `/etc/nginx/aktif.conf`:

```
server 127.0.0.1:8001;
```

Lalu di konfigurasi situs:

```
upstream app_aktif {
    include /etc/nginx/aktif.conf;
}

server {
    server_name app.domainkamu.com;
    location / {
        proxy_pass http://app_aktif;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}
```

Memindahkan trafik berarti mengubah satu baris di `aktif.conf`, lalu menjalankan `nginx -t` dan `systemctl reload nginx`. Dokumentasi Nginx menjelaskan bahwa saat reload, proses master menyalakan worker baru dengan konfigurasi baru, sementara worker lama menyelesaikan permintaan yang sedang berjalan sebelum berhenti. Karena itu pengunjung tidak melihat koneksi terputus. Kalau kamu belum terbiasa menyusun blok server, lihat [server block Nginx untuk banyak domain](https://nivelva.com/insight/cara-menyiapkan-server-block-nginx-banyak-domain).

## Urutan deploy yang aman

Misalkan blue sedang aktif. Urutan deploy versi baru:

1. Salin kode baru ke folder green dan pasang dependensinya.
2. Jalankan layanan green: `systemctl restart app@green`.
3. Cek kesehatan green langsung ke portnya, bukan lewat domain. Misalnya `curl -fsS http://127.0.0.1:8002/health`. Endpoint `/health` sebaiknya ikut memeriksa koneksi database dan layanan penting lain, bukan sekadar mengembalikan teks "ok".
4. Bila gagal, hentikan proses di sini. Pengunjung tidak terdampak karena blue masih aktif.
5. Bila sehat, ubah `aktif.conf` ke port 8002, jalankan `nginx -t`, lalu reload Nginx.
6. Biarkan blue tetap hidup beberapa saat sebagai jalan pulang. Deploy berikutnya akan masuk ke blue, dan peran keduanya bertukar.

Rollback cukup langkah 5 ke arah sebaliknya. Langkah ini mudah diotomatisasi dengan skrip shell kecil yang membaca salinan mana yang aktif, lalu dipanggil dari pipeline seperti [GitHub Actions](https://nivelva.com/insight/cara-deploy-otomatis-vps-github-actions).

| Tahap | Blue (8001) | Green (8002) | Pengunjung diarahkan ke |
|:--|:--|:--|:--|
| Sebelum deploy | Versi lama, aktif | Kosong atau versi lebih lama | Blue |
| Green disiapkan | Versi lama, aktif | Versi baru, diuji | Blue |
| Setelah dialihkan | Versi lama, siaga | Versi baru, aktif | Green |
| Bila ada masalah | Diaktifkan lagi | Diperbaiki | Blue |

## Versi Docker dari pola yang sama

Kalau aplikasimu berjalan di container, susunannya hampir sama. Jalankan dua container dari image berbeda, misalnya `app-blue` yang dipetakan ke `127.0.0.1:8001` dan `app-green` ke `127.0.0.1:8002`. Deploy berarti menarik image versi baru, menjalankannya sebagai container yang sedang tidak aktif, menunggu cek kesehatannya lolos, lalu mengubah `aktif.conf` dan me-reload Nginx seperti di atas.

Perhatikan agar port container hanya dibuka di `127.0.0.1`, bukan di semua alamat. Nginx di host yang menjadi satu-satunya pintu masuk dari luar. Container yang tidak aktif bisa dihentikan setelah kamu yakin versi baru stabil, untuk menghemat RAM.

## Database adalah bagian tersulit

Kedua salinan aplikasi memakai database yang sama. Inilah jebakan utama blue-green. Kalau versi baru menghapus atau mengganti nama kolom, versi lama yang masih hidup (dan menjadi jalan rollback) langsung rusak.

Cara yang umum dipakai adalah memecah perubahan skema menjadi beberapa deploy, sering disebut pola expand dan contract. Pertama, tambahkan kolom atau tabel baru tanpa menghapus yang lama, sehingga versi lama dan baru sama-sama bisa berjalan. Setelah versi baru stabil dan tidak ada rencana rollback, barulah kolom lama dihapus di deploy berikutnya.

Hal lain yang perlu dipikirkan adalah sesi pengguna dan file upload. Kalau sesi disimpan di memori proses atau file upload ditaruh di dalam folder aplikasi, pengunjung bisa ter-logout atau kehilangan file setelah perpindahan. Simpan sesi di Redis atau database, dan file upload di folder bersama di luar folder blue dan green.

## Kapan pola ini sepadan dengan usahanya?

Blue-green menambah kerumitan: dua salinan, skrip pengalih, dan disiplin migrasi database. Untuk situs profil perusahaan yang jarang diperbarui, restart biasa di jam sepi sering sudah cukup. Pola ini mulai sepadan ketika aplikasi melayani transaksi sepanjang hari, deploy terjadi beberapa kali seminggu, atau satu menit error sudah berarti pesanan yang hilang.

Langkah awal yang realistis adalah membuat endpoint health check dan skrip pengalih, lalu mencobanya di server staging. Setelah beberapa kali berjalan mulus, pindahkan ke produksi.

Intinya, blue-green di VPS bekerja dengan dua salinan aplikasi, Nginx sebagai sakelar, dan cek kesehatan sebelum pindah. Reload Nginx menjaga koneksi tetap utuh, dan salinan lama menjadi jalan rollback instan. Bagian yang paling menentukan berhasil atau tidaknya justru perubahan database yang harus tetap cocok dengan dua versi aplikasi sekaligus.

## Sumber

- <https://nginx.org/en/docs/http/ngx_http_upstream_module.html>
- <https://nginx.org/en/docs/control.html>

---

Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/cara-deploy-downtime-blue-green-vps
Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com