Panduan Self-Host n8n di VPS untuk Otomatisasi Workflow

Berdasarkan pertanyaan yang sering ditanyakan kepada tim support kami, salah satu topik yang banyak dicari adalah cara menjalankan self-host n8n di VPS agar server tidak kehabisan memori. Banyak pengguna mulai menjalankan banyak workflow, integrasi webhook, hingga integrasi AI, tapi kemudian menemui error 502 Bad Gateway karena kehabisan resource.

Menjalankan n8n secara mandiri memberikan kontrol lebih besar atas data dan konfigurasi tanpa bergantung pada batas eksekusi bulanan layanan cloud. Tanpa perencanaan kapasitas, penggunaan resource dapat meningkat dan mengganggu stabilitas server. Artikel ini membahas masalah teknis yang sering terjadi saat menjalankan n8n di VPS serta langkah yang dapat dilakukan untuk mengatasinya.

Mengapa Menjalankan n8n pada Layanan Shared Hosting Sering Bermasalah

Salah satu kendala yang sering ditanyakan kepada tim support adalah pengguna yang mencoba menjalankan n8n pada layanan shared hosting berbasis cPanel. Pada lingkungan shared hosting, terdapat mekanisme pembatas resource seperti CloudLinux LVE yang membatasi memori fisik, thread proses, dan IOPS per akun.

Ketika workflow n8n menerima webhook secara bersamaan, runtime Node.js akan mengalokasikan memori sesuai kebutuhan proses. Begitu penggunaan RAM melampaui batas paket hosting, sistem operasi server akan memicu Out of Memory (OOM) killer untuk menghentikan proses n8n. Akibatnya, proses terhenti dan webhook pengirim menerima respons kegagalan. Penjelasan mengenai cara kerja lingkungan tersebut dibahas lebih detail dalam pengertian apa itu n8n untuk otomatisasi bisnis agar Anda dapat menentukan jenis server yang sesuai sejak awal.

Keterbatasan SQLite dan Masalah Database Locking

Secara default, instalasi n8n menggunakan database SQLite untuk menyimpan konfigurasi workflow, kredensial, dan riwayat eksekusi. SQLite cocok untuk pengujian lokal dengan satu pengguna, tapi memiliki keterbatasan saat menangani transaksi konkuren.

Ketika banyak data masuk bersamaan melalui webhook, SQLite menerapkan database locking. Jika satu proses membutuhkan waktu untuk menulis data riwayat eksekusi, proses lain yang menunggu giliran dapat mengalami timeout. Masalah ini berkaitan langsung dengan keterbatasan I/O database saat menangani banyak antrean data secara bersamaan.

Penumpukan Riwayat Eksekusi yang Menghabiskan Ruang Disk

Masalah lain yang sering terjadi adalah kapasitas hard disk server yang penuh akibat penyimpanan log. Secara default, n8n mencatat data input dan output dari setiap node yang dieksekusi.

Jika workflow memproses ribuan data per hari atau mengolah file seperti gambar dan PDF, ukuran database n8n dapat bertambah dengan cepat. Jika ruang disk habis, sistem file server dapat berubah menjadi read-only, sehingga layanan lain pada server yang sama juga ikut terganggu.

Konfigurasi Penting Saat Menjalankan Self-Host n8n di VPS

Untuk menjaga agar n8n dapat berjalan dengan stabil untuk kebutuhan operasional harian, terdapat beberapa pengaturan server yang sebaiknya diterapkan.

Menggunakan PostgreSQL untuk Menangani Beban Kerja Lebih Besar

Langkah awal yang perlu dilakukan adalah mengarahkan penyimpanan data n8n ke database relasional seperti PostgreSQL. PostgreSQL dirancang untuk menangani beban konkurensi melalui row-level locking dan connection pool.

Dengan memisahkan database n8n ke PostgreSQL, server dapat memproses banyak pemanggilan data secara bersamaan tanpa risiko data rusak. Hal ini penting jika Anda menerapkan teknik menggunakan webhook di n8n untuk integrasi API yang menerima data dari platform eksternal sepanjang waktu.

Mengaktifkan Fitur Pruning Data Otomatis

Untuk membatasi ukuran database, Anda dapat menambahkan environment variable berikut pada file docker-compose atau konfigurasi n8n:

Konfigurasi ini mengatur n8n agar menghapus data eksekusi yang berusia lebih dari 7 hari (168 jam) dan membatasi riwayat maksimal 10.000 entri. Pengaturan ini membantu menjaga penggunaan storage server tetap terkendali.

Mengatur Batasan Memori Node.js dan Swap File

Node.js memiliki batas memori heap bawaan. Jika workflow memproses data dalam ukuran besar, tentukan batas memori melalui variabel lingkungan:

NODE_OPTIONS="--max-old-space-size=2048"

Selain itu, aktifkan swap file minimal 2 GB hingga 4 GB sebagai cadangan saat terjadi lonjakan penggunaan RAM. Langkah teknis terkait pengelolaan resource server dapat Anda pelajari dalam panduan cara mengatasi penggunaan CPU tinggi pada VPS.

Kapan Workflow Otomatisasi Membutuhkan VPS Terpisah

Penggunaan n8n umumnya dimulai dari beberapa workflow sederhana. Namun, seiring bertambahnya integrasi seperti sinkronisasi data transaksi, bot pesan, hingga proses dokumen, kebutuhan resource server akan meningkat.

Anda sebaiknya memindahkan n8n ke VPS terpisah jika menemukan kondisi berikut:

1. Workflow sering terhenti karena timeout.
2. Webhook dari layanan pihak ketiga menerima balasan error 504 Gateway Timeout.
3. Database atau aplikasi web lain pada server yang sama mulai melambat akibat penggunaan CPU dari proses n8n.

Untuk memperkirakan kebutuhan kapasitas server, Anda dapat membaca analisis kapan saat yang tepat upgrade ke VPS sebagai bahan pertimbangan teknis.

Menjalankan n8n pada Infrastruktur Flaz Cloud

Workflow n8n membutuhkan server dengan resource yang cukup agar dapat berjalan dengan stabil. Pemisahan resource juga penting jika n8n digunakan bersama aplikasi atau layanan lain.

Jika Anda ingin menjalankan n8n tanpa melakukan instalasi Docker, SSL, dan database secara manual, Flaz Cloud menyediakan layanan cloud apps n8n siap pakai. Jika membutuhkan kontrol penuh atas konfigurasi sistem operasi dan akses root, Anda dapat menggunakan server VPS NVMe berperforma tinggi.

Jika Anda ingin berkonsultasi mengenai kebutuhan spesifikasi vCPU dan RAM yang sesuai untuk workflow n8n Anda, tim support kami siap membantu memeriksa kebutuhan server Anda.

FAQ

1. Berapa spesifikasi minimal VPS untuk menjalankan n8n?

Untuk workflow sederhana dengan frekuensi eksekusi rendah, spesifikasi 1 vCPU, RAM 2 GB, dan SSD 25 GB sudah mencukupi. Namun, jika workflow memproses webhook secara simultan atau terhubung dengan model AI, spesifikasi 2 vCPU dan RAM 4 GB lebih disarankan agar proses Node.js tidak mengalami kehabisan memori.

2. Apa penyebab utama error 502 Bad Gateway pada n8n?

Penyebab paling umum adalah proses Node.js yang dihentikan oleh OOM killer karena penggunaan RAM melebihi alokasi yang tersedia. Hal ini sering terjadi ketika workflow memproses file berukuran besar, ketiadaan swap file, atau penumpukan log eksekusi yang tidak dibersihkan.

3. Apakah SQLite cukup untuk menjalankan n8n di lingkungan produksi?

SQLite kurang disarankan untuk lingkungan produksi dengan trafik webhook yang sering. SQLite menggunakan mekanisme database locking saat proses penulisan berlangsung, sehingga antrean transaksi berikutnya berisiko mengalami timeout. Menggunakan PostgreSQL jauh lebih aman untuk stabilitas data.

4. Bagaimana cara agar database n8n tidak memenuhi ruang hard disk?

Anda dapat menyetel environment variable EXECUTIONS_DATA_PRUNE=true dan menentukan masa retensi data melalui EXECUTIONS_DATA_MAX_AGE=168 (menghapus data lebih dari 7 hari). Cara ini membatasi ukuran log riwayat sehingga kapasitas disk VPS tetap terjaga.

5. Bagaimana cara memindahkan workflow n8n ke VPS baru?

Anda dapat mengekspor workflow dan data kredensial langsung melalui dashboard n8n atau menggunakan perintah CLI n8n export:workflows dan n8n export:credentials. File JSON hasil ekspor kemudian dapat diimpor ke instance n8n pada VPS baru.