Cara Install n8n di VPS dengan Docker

Bagaimana cara install n8n di VPS dengan Docker?

Untuk install n8n di VPS dengan Docker, arahkan domain ke server, jalankan versi n8n yang dipin melalui Docker Compose, dan gunakan reverse proxy HTTPS. Amankan akses serta uji backup sebelum memakai data bisnis sungguhan. Untuk instance yang sudah berjalan, selesaikan checklist upgrade di bawah sebelum mengganti versi image.

Self-host memungkinkan Anda memilih server dan konfigurasi, sekaligus membuat tim bertanggung jawab atas pemeliharaan dan pemulihan. Layanan AI dan SaaS yang terhubung tetap bisa menerima data workflow. Panduan ini mengasumsikan Ubuntu 22.04/24.04 dan domain sendiri (misalnya n8n.domainanda.com). Contoh minimal ini mencakup n8n dan Caddy; sandbox n8n Assistant atau task runner produksi terpisah belum dikonfigurasi.

Apa yang perlu disiapkan sebelum mulai?

Sebelum mengetik perintah apa pun, pastikan empat hal berikut sudah ada:

• VPS dengan OS Ubuntu (22.04 atau lebih baru) dan akses root/sudo via SSH.
• Domain atau subdomain yang bisa Anda atur DNS-nya (untuk HTTPS dan URL yang rapi).
• Spesifikasi minimal yang sesuai beban kerja (lihat tabel di bawah).
• Kemampuan administrasi server, termasuk membaca log container, mengatur akses, dan memulihkan backup.

Angka berikut adalah perkiraan awal, bukan jaminan kapasitas. Ukur memori, durasi eksekusi, dan konkurensi dengan workflow yang mewakili penggunaan Anda:

Beban kerja	vCPU	RAM	Penyimpanan	Catatan
Coba-coba / personal	1-2	2 GB	20 GB SSD	Mulai kecil; ukur penggunaan memori
Bisnis kecil (UMKM)	2	2-4 GB	40 GB SSD	Uji beban integrasi yang dipakai
Produksi / AI agent	4	4-8 GB	60-100 GB SSD	Hitung kapasitas database dan runner terpisah

Bandingkan region Jakarta dan Singapura berdasarkan latensi nyata dan kebutuhan penanganan data. Anggarkan backup, storage, monitoring, pengelolaan, dan pemakaian API selain biaya VPS. Panduan Docker Compose resmi mensyaratkan minimal RAM 4 GB dan 2 vCPU untuk stack sandbox Assistant yang lebih besar; konfigurasinya berbeda dari contoh minimal di sini.

Bagaimana langkah-langkah install n8n dengan Docker Compose?

Gunakan langkah ini untuk instance baru. Ganti n8n.domainanda.com dengan domain Anda. Instance yang sudah berjalan membutuhkan backup dan staging seperti dijelaskan di bawah terlebih dahulu.

1. Login ke VPS via SSH dan update sistem.

   ssh root@IP_VPS_ANDA
   apt update && apt upgrade -y
   

2. Install Docker dan Docker Compose plugin. Ikuti petunjuk resmi Docker Engine untuk Ubuntu, termasuk repositori apt dan plugin Compose. Verifikasi dengan docker --version dan docker compose version.

3. Arahkan domain ke server. Di panel DNS domain Anda, buat record A untuk n8n.domainanda.com yang menunjuk ke IP publik VPS. Tunggu propagasi DNS (biasanya beberapa menit hingga satu jam).

4. Buat folder proyek dan file konfigurasi.

   mkdir ~/n8n && cd ~/n8n
   nano docker-compose.yml
   

5. Isi docker-compose.yml dengan konfigurasi n8n + Caddy (Caddy mengurus HTTPS otomatis lewat Let's Encrypt): Contoh ini mem-pin n8n 2.43.5, diperiksa 15 Oktober 2026, dan mempertahankan Caddy 2.11.7 yang sebelumnya diperiksa 10 Oktober. Tinjau rilis yang lebih baru sebelum mengadopsinya. N8N_WEBHOOK_URL dan satu trusted proxy hop mengikuti panduan reverse proxy n8n; sesuaikan jumlah hop jika rantai proxy Anda berbeda.

   services:
     n8n:
       image: n8nio/n8n:2.43.5
       restart: always
       environment:
         - N8N_HOST=n8n.domainanda.com
         - N8N_PROTOCOL=https
         - N8N_WEBHOOK_URL=https://n8n.domainanda.com/
         - N8N_PROXY_HOPS=1
         - GENERIC_TIMEZONE=Asia/Jakarta
         - TZ=Asia/Jakarta
       volumes:
         - n8n_data:/home/node/.n8n
     caddy:
       image: caddy:2.11.7
       restart: always
       ports:
         - "80:80"
         - "443:443"
       volumes:
         - ./Caddyfile:/etc/caddy/Caddyfile
         - caddy_data:/data
   volumes:
     n8n_data:
     caddy_data:
   

6. Buat file Caddyfile di folder yang sama untuk reverse proxy + HTTPS otomatis:

   n8n.domainanda.com {
       reverse_proxy n8n:5678
   }
   

7. Batasi akses onboarding, lalu jalankan n8n. Sebelum startup, izinkan akses HTTPS hanya dari IP administrator Anda melalui firewall provider VPS, atau gunakan jalur akses terbatas yang setara. Jaga halaman setup owner tetap privat sampai akun Anda dibuat. Pastikan pembatasan yang dipilih tetap memungkinkan validasi sertifikat Caddy.

   docker compose up -d
   

   Caddy akan otomatis mengambil sertifikat SSL. Buka https://n8n.domainanda.com di browser, lalu buat akun owner pertama Anda.

8. Konfigurasikan firewall host dan provider. Contoh UFW di bawah mengatur host. Port yang dipublikasikan Docker dapat melewati aturan UFW; gunakan firewall provider atau aturan yang memahami Docker untuk akses container, sesuai batasan firewall Docker. Pastikan akses SSH tetap tersedia sebelum mengaktifkan UFW:

   ufw allow OpenSSH
   ufw allow 80
   ufw allow 443
   ufw enable
   

Verifikasi HTTPS, login owner, dan webhook uji yang tidak menimbulkan dampak bisnis. Batasi akses onboarding sampai akun owner selesai dibuat, lalu periksa juga firewall provider VPS. Editor yang bisa dibuka saja belum membuktikan kesiapan produksi.

Bagaimana cara mengamankan n8n yang di-self-host?

• Batasi akses. Gunakan HTTPS, akun owner, dan akses jaringan seperlunya. Jangan publikasikan port n8n 5678 pada host, seperti pada contoh ini. Periksa dampak autentikasi proxy tambahan terhadap rute webhook.
• Rencanakan update. Baca catatan rilis, pin versi, lalu uji di instance staging terpisah sebelum produksi, sesuai panduan update n8n.
• Siapkan backup yang bisa dipulihkan. Untuk SQLite bawaan, hentikan n8n sebelum menyalin n8n_data, atau gunakan snapshot konsisten. Untuk PostgreSQL, sertakan backup database; volume saja tidak cukup. Sertakan storage eksternal dan file custom node yang dikonfigurasi. Lihat backup dan restore n8n.
• Lindungi encryption key yang sesuai. Simpan key dari .n8n/config atau N8N_ENCRYPTION_KEY kustom bersama backup dengan akses terbatas; pemulihan kredensial terenkripsi memerlukannya. Lihat dokumentasi encryption key. Jangan masukkan key atau ekspor kredensial ke Git.

Simpan konfigurasi deployment dan versi image sebelumnya, lalu latih pemulihan di lingkungan terisolasi. Ekspor JSON workflow saja bukan backup instance lengkap. Untuk produksi berkelanjutan, tinjau panduan PostgreSQL dan runner resmi, alih-alih menganggap contoh SQLite minimal ini mencakup semua beban kerja.

Versi n8n mana yang dipakai setelah pengungkapan keamanan 14 Oktober?

Diperiksa 15 Oktober 2026: panduan ini kini mem-pin n8n 2.43.5, dirilis 14 Oktober, rilis stabil saat ini. Versi 2.42.6 yang sebelumnya dicantumkan bukan lagi target upgrade panduan ini. n8n 2.44.1 adalah prerelease yang sudah mendapat patch, bukan rekomendasi versi stabil untuk produksi.

Untuk deployment 1.x yang sudah berjalan, 1.123.85 tercantum sebagai patch cabang untuk advisory webhook, file node, error kredensial, dan Quick Base di bawah. Ini tidak membuktikan cakupan seluruh advisory atau dukungan berkelanjutan bagi semua deployment 1.x. Rencanakan perpindahan ke 2.x secara terpisah dengan panduan migrasi 2.0 lengkap, termasuk perubahan runner, akses file, database/storage, dan publikasi workflow. Jangan menonaktifkan pengaturan keamanan bawaan hanya agar workflow lama lolos.

Workflow dan izin akses mana yang perlu ditinjau?

Enam advisory ini dipublikasikan pada 14 Oktober 2026. Prasyarat dan patch-nya berbeda; pengungkapan kerentanan bukan bukti bahwa instance Anda telah disusupi. Gunakan masing-masing advisory untuk rincian versi terdampak.

• Respons webhook, High 8.4: anggota yang bisa membuat dan mengaktifkan workflow dapat menyajikan HTML melalui jalur respons yang tidak memiliki perlindungan sandbox. Pengguna lain yang membuka URL webhook tersebut bisa mengekspos sesi n8n-nya ke halaman itu. Tinjau isi respons webhook dan siapa yang dapat mengaktifkan workflow. Patch tercantum: 1.123.85, 2.43.5, dan 2.44.1. Advisory sandbox webhook.
• Data Tables, High 7.2: anggota yang bisa membuat dan menjalankan workflow dapat mengakses baris Data Table lintas proyek, termasuk membaca, mengubah, atau menghapusnya. Tinjau batas antarproyek memakai akun uji yang diizinkan. Patch tercantum: 2.43.5 dan 2.44.1; advisory ini tidak mencantumkan patch 1.x. Advisory otorisasi Data Tables.
• Read/Write Files, High 7.1: anggota yang bisa membuat dan menjalankan workflow dengan file node dapat memicu pemrosesan path yang memblokir event loop utama, mengganggu editor, API, dan webhook. Tinjau siapa yang dapat memakai node ini. Patch tercantum: 1.123.85, 2.43.5, dan 2.44.1. Advisory denial of service file node.
• Secret dalam error eksekusi, Moderate 5.3: operasi gagal tertentu pada Git, MongoDB Atlas Vector Store, dan Google Cloud Storage dapat meninggalkan secret kredensial dalam data error eksekusi. Orang dengan akses baca eksekusi bisa melihatnya tanpa izin baca kredensial. Patch tercantum: 1.123.85, 2.43.5, dan 2.44.1. Advisory paparan kredensial.
• Filter Quick Base, Moderate 5.3: ekspresi Where dengan input tidak tepercaya dapat mengubah cakupan query/penghapusan sesuai izin kredensial. Patch: 1.123.85, 2.43.5, dan 2.44.1. Setelah upgrade, ekspresi tersebut tetap rentan: pindahkan nilai dinamis ke Where Parameters dan uji dengan data sekali pakai. Advisory filter Quick Base.
• Pemadatan riwayat workflow, High 7.1: pengguna berizin rendah yang bisa menyimpan workflow dapat menyebabkan pemrosesan riwayat berikutnya mengganggu login dan operasi tulis instance. Menurut catatan patch advisory, masalah ini sudah diperbaiki di 2.41.4 dan 2.42.1; bukan pertama kali diperbaiki pada rilis 14 Oktober. Advisory riwayat workflow.

Label tingkat keparahan di atas mengikuti advisory GitHub yang menjadi sumber utama. Selama menyiapkan patch, batasi akses ke pengguna tepercaya, kurangi izin baca eksekusi yang tidak diperlukan, dan tinjau webhook terbuka atau node terdampak yang tidak dipakai. Advisory menyebut langkah ini sebagai mitigasi sementara yang tidak lengkap, bukan pengganti perbaikan.

Sebagai tindak lanjut operasional yang hati-hati, tinjau error historis yang relevan dengan akses terbatas dan rotasi kredensial jika diduga terekspos, mengikuti prosedur layanan terkait. Ini bukan klaim adanya kebocoran di server Anda. Jangan menganggap patch otomatis menghapus salinan error lama atau merotasi secret.

Apa yang perlu diperiksa sebelum upgrade ke n8n 2.43.5?

Backup dan uji patch yang dipilih sebelum produksi. Jika berasal dari versi lebih lama, tetap lakukan pemeriksaan node lama di bawah: rilis n8n 2.42.6 pada 9 Oktober memperkenalkan penegakan aturan yang mengubah cara workflow lama disimpan, diimpor, dan dipanggil.

Workflow lama mana yang terdampak?

Pemblokiran bawaan mencakup Function, Function Item, dan LangChain Code. Workflow tersimpan yang langsung memuat node tersebut masih dapat berjalan tanpa perubahan. Saat update, node boleh dibiarkan sama, dipindah posisinya di canvas, dihapus, atau dimigrasikan ke versi yang didukung; perubahan parameter, nama, kredensial, atau status disabled ditolak. Impor JSON workflow, termasuk restore melalui CLI ke instance baru, serta source-control pull bisa gagal. Pemulihan database/volume lengkap adalah operasi terpisah. Lihat aturan breaking change pada PR n8n #40707.

PR yang sama menjelaskan pemeriksaan saat eksekusi untuk subworkflow dari JSON inline, URL, atau file lokal, eksekusi satu node melalui Assistant, serta chat tool deprecated. Chat tool yang sudah ada dengan tipe deprecated berhenti bekerja ketika penegakan aktif. Impor ulang tanpa perubahan ke workflow yang sudah ada diperbolehkan; itu belum membuktikan ekspor yang sama dapat diimpor ke instance baru.

Checklist upgrade praktis

1. Inventarisasi sebelum mengganti versi. Catat versi berjalan, database/storage, node aktif, dan izin kolaborator. Catat pemilik workflow dan cari tiga tipe node lama pada workflow aktif, JSON template, ekspor backup, subworkflow, serta chat tool. Sertakan pekerjaan yang belum dipublikasikan dan jalur source control bila paket Anda mendukungnya.
2. Backup dan siapkan staging terisolasi terlebih dahulu. Ambil backup lengkap sebelum upgrade dan latih pemulihannya. Gunakan database, volume, dan hostname terpisah. Blokir tujuan produksi atau ganti kredensial dengan akun uji sebelum menyalakan trigger. Terapkan versi n8n berpatch yang dipilih di staging; selesaikan migrasi dan pengujian di bawah di sana sebelum mengubah produksi.
3. Migrasikan dan bandingkan output. Gunakan Code node yang didukung untuk logika Function/Function Item, dengan mode semua item atau per item yang sesuai. Bangun ulang logika LangChain Code memakai node yang didukung sesuai tujuannya; jangan anggap penggantinya selalu langsung kompatibel. Periksa bentuk item, error, dan dampak ke sistem berikutnya. Pertahankan penegakan aturan: Function lama masih memakai sandbox vm2 yang tidak aman sebagaimana dijelaskan dalam PR tersebut.
4. Tinjau filter dinamis Quick Base. Selesaikan migrasi parameter dan uji cakupan di atas jika fitur ini dipakai.
5. Uji jalur yang benar-benar dipakai. Periksa login, isolasi proyek/peran yang diharapkan, akses file, trigger terjadwal/webhook, eksekusi manual, penyuntingan dan penyimpanan, sumber subworkflow, Assistant dan chat tool bila dikonfigurasi, impor template, restore ke instance baru, serta source-control pull bila tersedia. Verifikasi dekripsi kredensial dan output yang diharapkan, bukan hanya health check HTTP. Catat kegagalan dan penanggung jawabnya.
6. Tinjau, lalu update produksi. Lanjutkan setelah tim menerima hasil uji dan rencana pemulihan. Dalam jadwal pemeliharaan, set tag image n8n yang sudah ditinjau pada Compose, tarik service tersebut, lalu buat ulang container-nya. Verifikasi versi yang berjalan dengan docker compose exec n8n n8n --version, lalu periksa log dan workflow perwakilan. Jangan anggap image lama bisa membaca database yang sudah di-upgrade; gunakan prosedur restore yang telah dilatih jika pemulihan diperlukan.

Ini rekomendasi pemeriksaan untuk deployment Anda, bukan klaim bahwa server atau workflow tertentu sudah diuji. Untuk upgrade dari 1.x atau rilis 2.x yang lebih lama, tinjau juga seluruh breaking change di antaranya. Pisahkan upgrade service lain dan versi mayor PostgreSQL dari patch keamanan ini: dokumentasi Compose mensyaratkan prosedur upgrade database terpisah untuk deployment PostgreSQL yang sudah ada, bukan sekadar mengganti tag image.

Kapan sebaiknya self-host vs pakai n8n Cloud?

Tidak semua bisnis perlu self-host. Berikut perbandingan singkatnya:

Aspek	Self-host (VPS + Docker)	n8n Cloud
Penanganan data	Anda memilih hosting dan integrasi	Tinjau ketentuan layanan terkelola dan integrasi
Biaya	Infrastruktur, pengelolaan, dan layanan eksternal	Langganan paket serta layanan eksternal
Pemeliharaan	Tim Anda mengoperasikan instance	Provider mengelola platform; tim tetap merawat workflow
Cocok untuk	Tim dengan kemampuan operasional dan kebutuhan hosting khusus	Tim yang memilih infrastruktur terkelola

Pilih berdasarkan kemampuan pengelolaan, beban kerja, kebutuhan pemulihan, dan tujuan pengiriman data setiap integrasi. Self-host saja tidak menjamin privasi, kepatuhan, atau biaya tetap. n8n Community bersifat source-available dan fair-code; tinjau Sustainable Use License dan penjelasan lisensi n8n untuk penggunaan yang diizinkan dan batas komersialnya.

Baru memulai dan ingin paham fondasinya dulu? Lihat hub n8n Indonesia, panduan Apa Itu n8n, dan tutorial n8n bahasa Indonesia. Setelah server siap, Anda bisa lanjut membangun contoh workflow n8n untuk perusahaan, AI agent dengan n8n, atau chatbot WhatsApp otomatis.

Siapa yang bisa membantu self-host n8n di Indonesia?

Untuk setup dan pembelajaran tim, jelajahi template n8n Fahmi Fahreza dan training n8n Indonesia. Tinjau node serta kredensial setiap template, lalu impor dan uji di staging sebelum menghubungkannya ke layanan produksi.

Agenda training yang berguna mencakup inventarisasi workflow dan izin akses, latihan migrasi node lama serta filter Quick Base, simulasi restore, dan checklist upgrade tertulis. Untuk merencanakan pekerjaan tersebut, lihat Corporate AI Training Indonesia atau hubungi Fahmi.