Cara Deploy Aplikasi ke VPS Ubuntu dengan Nginx

Antara "aplikasinya sudah jadi di laptop" dan "aplikasinya bisa dibuka pelanggan" ada satu jurang yang menghentikan banyak proyek: deployment. Padahal VPS kecil — harganya sebanding beberapa gelas kopi per bulan — sanggup menampung aplikasi bisnis yang dipakai puluhan orang, asal urutan pemasangannya benar dari awal. Tutorial ini adalah urutan itu, dari server kosong sampai aplikasi yang hidup di balik HTTPS.

Peta besarnya: dari kode di laptop ke server hidup

Empat lapisan yang akan kita susun, dari dalam ke luar: aplikasi Anda berjalan sebagai service yang bangun sendiri saat server restart; Nginx berdiri di depannya menerima semua trafik; HTTPS mengunci jalurnya; dan firewall menutup semua pintu lain. Contoh di sini memakai aplikasi Python (FastAPI), tapi polanya identik untuk Node.js atau Go — hanya perintah menjalankannya yang berbeda.

Langkah 1: Amankan akses awal server

Lima menit pertama di server baru menentukan tingkat tidur nyenyak Anda ke depan:

adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Lalu di /etc/ssh/sshd_config: set PermitRootLogin no dan PasswordAuthentication no (pastikan login SSH key Anda sudah terbukti jalan sebelum menutup password). Terakhir, firewall:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

Server yang baru menyala langsung dipindai bot dari seluruh dunia — itu bukan paranoia, itu isi log auth setiap VPS publik. Tiga langkah di atas membuat pindai itu membentur tembok.

Langkah 2: Pasang aplikasi dan jalankan sebagai service

Salin kode ke server (git clone paling rapi), siapkan lingkungannya, lalu — bagian yang paling sering dilewatkan pemula — daftarkan sebagai systemd service supaya aplikasi hidup lagi sendiri setelah crash atau reboot. Buat /etc/systemd/system/appku.service:

[Unit]
Description=Aplikasi internal
After=network.target

[Service]
User=deploy
WorkingDirectory=/home/deploy/appku
ExecStart=/home/deploy/appku/.venv/bin/gunicorn \
  -w 2 -k uvicorn.workers.UvicornWorker \
  -b 127.0.0.1:8000 main:app
Restart=always

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now appku
systemctl status appku

Perhatikan -b 127.0.0.1:8000: aplikasi hanya mendengarkan dirinya sendiri. Dunia luar tidak akan pernah bicara langsung dengannya — itu tugas Nginx.

Langkah 3: Taruh Nginx di depan aplikasi

sudo apt install nginx

Buat /etc/nginx/sites-available/appku:

server {
    listen 80;
    server_name app.usaha-anda.com;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo ln -s /etc/nginx/sites-available/appku /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Kenapa repot pakai perantara? Karena Nginx mengerjakan hal-hal yang aplikasi Anda sebaiknya tidak urus sendiri: menampung koneksi lambat, menyajikan file statis dengan cepat, membatasi ukuran upload, dan — di langkah berikutnya — memegang sertifikat HTTPS untuk semua aplikasi di server ini sekaligus.

Langkah 4: Pasang HTTPS dan uji dari luar

Arahkan DNS domain Anda ke IP server, tunggu resolusinya jalan, lalu:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d app.usaha-anda.com

Certbot menerbitkan sertifikat, mengedit konfigurasi Nginx, dan memasang perpanjangan otomatis. Lalu uji seperti orang luar: buka situs dari jaringan seluler (bukan WiFi kantor), periksa gemboknya, dan coba juga alamat http:// untuk memastikan ia dialihkan ke https://.

Checklist sebelum server dianggap selesai

• Reboot server sekali, lalu pastikan aplikasi bangun sendiri. Ini menguji seluruh rantai systemd dalam satu perintah.
• Log bisa ditemukan: journalctl -u appku untuk aplikasi, /var/log/nginx/ untuk trafik. Saat masalah datang jam 11 malam, Anda tidak ingin baru mulai mencari log.
• Backup terjadwal untuk data — kode bisa di-clone ulang, database tidak.
• Update keamanan otomatis: paket unattended-upgrades menambal celah OS tanpa menunggu Anda ingat.

Batas jujurnya

Satu VPS yang dirawat baik cukup untuk aplikasi internal dan situs dengan trafik wajar. Ia bukan jawaban untuk sistem yang tidak boleh mati semenit pun atau lonjakan trafik puluhan kali lipat — kebutuhan seperti itu masuk wilayah arsitektur yang lebih besar. Dan kalau tidak ada siapa pun di tim yang mau memegang sisi server ini, itu sinyal untuk menyerahkan pembangunan dan perawatannya sekaligus — 38.000 jam maintenance yang sudah kami jalani persisnya pekerjaan ini.

Pasangan alami artikel ini: membangun REST API dengan FastAPI untuk aplikasinya, dan Docker untuk pemula sebagai jalur deploy alternatif yang lebih terbungkus.