n8n Queue Mode: Panduan Scaling dengan Redis, Worker, dan Multi-Main

Begitu n8n mulai memegang proses yang benar-benar penting, misalnya sinkronisasi order, notifikasi WhatsApp ke pelanggan, atau AI agent yang memproses ratusan dokumen, satu instance n8n biasa akan mulai terasa sesak. Editor melambat saat workflow berat berjalan, webhook sesekali timeout, dan satu proses yang macet bisa menahan semuanya. Jawaban standar n8n untuk masalah ini adalah n8n queue mode.

Artikel ini membahas queue mode dari sudut pandang perusahaan: kapan Anda benar-benar membutuhkannya, bagaimana arsitekturnya bekerja, environment variable apa saja yang penting, cara memantaunya, dan fitur scaling mana yang gratis versus yang membutuhkan lisensi berbayar. Semua detail teknis di sini mengacu pada dokumentasi resmi n8n per Oktober 2026. Selalu cek ulang dokumentasi untuk versi n8n yang Anda pakai, karena nama dan default variabel bisa berubah antarversi.

Apa itu n8n queue mode?

Secara default, n8n berjalan dalam regular mode: satu proses menangani semuanya, mulai dari editor, API, trigger, webhook, sampai menjalankan eksekusi workflow. Untuk tim kecil, ini sederhana dan cukup.

Queue mode memecah pekerjaan itu menjadi beberapa peran:

• Main menerima trigger (timer, polling, webhook), membuat eksekusi, lalu menaruh ID eksekusi ke antrean di Redis.
• Redis berfungsi sebagai message broker yang menyimpan antrean.
• Worker mengambil ID dari antrean, memuat data workflow dari database, menjalankan eksekusi, menyimpan hasilnya ke database, lalu memberi sinyal selesai lewat Redis.
• Database (PostgreSQL) dipakai bersama oleh main dan semua worker.

Hasilnya, kapasitas eksekusi tidak lagi dibatasi oleh satu proses. Kalau beban naik, Anda tambah worker. Kalau beban turun, kurangi worker. Main tetap ringan karena tidak ikut menjalankan eksekusi produksi.

Kapan perusahaan perlu queue mode?

Queue mode menambah komponen yang harus dirawat (Redis, Postgres, beberapa container), jadi jangan dipasang hanya karena terdengar "enterprise". Berikut tanda-tanda yang biasanya kami lihat di lapangan sebelum queue mode layak dipertimbangkan:

• Editor dan UI melambat setiap kali workflow berat atau batch besar sedang berjalan.
• Webhook timeout atau terlambat merespons saat banyak request masuk bersamaan, misalnya saat kampanye atau jam sibuk.
• Satu workflow bermasalah memengaruhi semua workflow lain, karena semuanya berbagi satu proses.
• Eksekusi menumpuk dan antrean kerja tidak pernah benar-benar habis.
• Anda butuh ketahanan: kalau satu worker mati, worker lain tetap memproses antrean.

Sebaliknya, kalau masalahnya adalah workflow yang tidak efisien (loop yang memproses item satu per satu tanpa batching, polling terlalu sering, data eksekusi yang tidak pernah dibersihkan), queue mode hanya memindahkan masalah ke lebih banyak mesin. Rapikan desain workflow dan atur pembersihan data eksekusi lebih dulu.

Kalau Anda masih di tahap memutuskan apakah n8n sebaiknya di-self-host atau tidak, baca dulu panduan n8n self-hosted untuk perusahaan dan perbandingan self-hosted vs cloud automation.

Arsitektur queue mode n8n

Gambaran arsitektur queue mode yang umum untuk perusahaan:

                  ┌─────────────────────┐
  Pengguna ──────▶│  Main (editor, API, │
                  │  trigger, timer)    │
                  └─────────┬───────────┘
  Webhook                   │ ID eksekusi
  produksi ──▶ [Webhook     ▼
               processor]─▶ Redis (antrean)
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
          Worker 1      Worker 2      Worker N
              └─────────────┴─────────────┘
                            │
                       PostgreSQL
              (workflow, kredensial, hasil eksekusi)

Beberapa komponen opsional yang perlu Anda pahami:

Webhook processor

Untuk beban webhook yang tinggi, n8n menyediakan proses khusus yang dijalankan dengan perintah n8n webhook. Load balancer Anda mengarahkan path /webhook/* dan /webhook-waiting/* ke kumpulan webhook processor, sementara path lainnya tetap ke main. Dokumentasi n8n secara eksplisit menyarankan jangan memasukkan main ke pool webhook. Jika ingin main sama sekali tidak menangani webhook produksi, set N8N_DISABLE_PRODUCTION_MAIN_PROCESS=true.

Multi-main

Queue mode biasa tetap hanya punya satu instance main. Kalau main mati, editor, API, dan trigger berbasis timer ikut berhenti sampai main kembali hidup, walaupun worker masih bisa menyelesaikan antrean yang sudah ada. Multi-main menjalankan beberapa main sekaligus di belakang load balancer dengan sticky session. Satu main menjadi leader yang menjalankan tugas yang hanya boleh terjadi sekali (timer, poller, pruning), sedangkan yang lain menjadi follower. Jika leader gagal, follower mengambil alih.

Penting: multi-main membutuhkan lisensi n8n Enterprise self-hosted dan tidak tersedia di n8n Cloud. Ini dibahas di bagian lisensi di bawah.

Environment variable yang wajib Anda pahami

Berikut variabel inti queue mode berdasarkan daftar environment variable queue mode di dokumentasi n8n:

Variabel	Default	Fungsi
EXECUTIONS_MODE	regular	Set ke queue di main dan semua worker
N8N_ENCRYPTION_KEY	-	Harus sama persis di main, worker, dan webhook processor agar kredensial bisa dibaca
QUEUE_BULL_REDIS_HOST	localhost	Host Redis
QUEUE_BULL_REDIS_PORT	6379	Port Redis
QUEUE_BULL_REDIS_PASSWORD	kosong	Password Redis (default tanpa autentikasi, jangan biarkan begitu di produksi)
QUEUE_BULL_REDIS_TLS	false	Aktifkan TLS untuk koneksi Redis
QUEUE_BULL_REDIS_CLUSTER_NODES	kosong	Daftar host:port jika memakai Redis Cluster
QUEUE_HEALTH_CHECK_ACTIVE	false	Mengaktifkan endpoint health check di worker
N8N_GRACEFUL_SHUTDOWN_TIMEOUT	30 (detik)	Waktu bagi worker menyelesaikan job sebelum berhenti
OFFLOAD_MANUAL_EXECUTIONS_TO_WORKERS	false	Jika true, eksekusi manual (dari editor) juga dijalankan di worker
N8N_MULTI_MAIN_SETUP_ENABLED	false	Mengaktifkan multi-main (butuh lisensi)

Contoh file environment minimal yang dipakai bersama oleh main dan worker:

# .env (dipakai main + worker)
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=ganti-dengan-secret

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
QUEUE_BULL_REDIS_PASSWORD=ganti-dengan-secret

# WAJIB identik di semua proses
N8N_ENCRYPTION_KEY=ganti-dengan-key-acak-yang-panjang

QUEUE_HEALTH_CHECK_ACTIVE=true

Lalu jalankan proses sesuai perannya:

# Main (editor, API, trigger)
n8n start

# Worker, dengan 10 eksekusi paralel per worker
n8n worker --concurrency=10

# Opsional: webhook processor
n8n webhook

Jika memakai Docker, image yang sama (n8nio/n8n) dipakai untuk semua peran; worker cukup diberi argumen worker.

Tiga jebakan yang paling sering terjadi

1. Encryption key berbeda. Kalau N8N_ENCRYPTION_KEY di worker tidak sama dengan main, worker tidak bisa membuka kredensial dan eksekusi gagal. Simpan key ini di secret manager dan backup dengan serius, karena tanpa key itu kredensial di database tidak bisa dipulihkan.
2. Binary data di filesystem. Queue mode tidak mendukung penyimpanan binary data di filesystem lokal, karena worker yang berbeda tidak berbagi disk yang sama. Pilihannya adalah mode database (set N8N_DEFAULT_BINARY_DATA_MODE=database) atau external storage S3 yang butuh lisensi Business atau Enterprise.
3. Concurrency terlalu rendah dengan banyak worker. Dokumentasi n8n mengingatkan bahwa concurrency rendah dengan jumlah worker besar bisa menghabiskan pool koneksi database. n8n menyarankan concurrency 5 atau lebih.

n8n di Kubernetes: kapan masuk akal?

Queue mode bisa berjalan dengan Docker Compose di satu atau beberapa VM, dan untuk banyak perusahaan menengah itu sudah cukup. Kubernetes mulai masuk akal ketika:

• Tim Anda sudah mengoperasikan Kubernetes untuk sistem lain, sehingga n8n tinggal mengikuti standar yang ada.
• Anda butuh autoscaling worker berdasarkan beban.
• Ada kebutuhan standar platform internal (network policy, secret management, observability) yang sudah dibangun di atas Kubernetes.

Pola umumnya: deployment terpisah untuk main, worker (stateless, bisa banyak replika), dan opsional webhook processor, dengan PostgreSQL dan Redis sebagai layanan eksternal. Hal yang sering terlupa adalah graceful shutdown: saat Kubernetes mengurangi replika worker, eksekusi yang sedang berjalan bisa terputus. Samakan terminationGracePeriodSeconds di pod dengan N8N_GRACEFUL_SHUTDOWN_TIMEOUT, dan pertimbangkan scaling berdasarkan panjang antrean, bukan hanya CPU, karena banyak workflow n8n lebih banyak menunggu API (I/O) daripada memakai CPU.

Kalau tim Anda belum punya pengalaman Kubernetes, jangan jadikan n8n proyek pertama untuk belajar Kubernetes. Docker Compose yang dirawat dengan baik jauh lebih aman daripada cluster yang tidak ada yang paham.

Monitoring queue mode

Arsitektur terdistribusi butuh visibilitas. Minimal, pantau hal-hal berikut:

• Health check worker. Dengan QUEUE_HEALTH_CHECK_ACTIVE=true, worker menyediakan /healthz (apakah proses hidup) dan /healthz/readiness (apakah koneksi database dan Redis siap). Pakai ini untuk liveness dan readiness probe.
• Metrik Prometheus. Set N8N_METRICS=true untuk mengaktifkan endpoint /metrics, dan N8N_METRICS_INCLUDE_QUEUE_METRICS=true untuk menyertakan metrik antrean. Dari sini Anda bisa membuat dashboard Grafana dan alert, misalnya ketika antrean terus memanjang.
• Redis dan PostgreSQL. Pantau memori Redis, jumlah koneksi Postgres, dan ukuran tabel eksekusi. Banyak insiden n8n sebenarnya berawal dari database yang membengkak.
• Tampilan Workers di n8n. Pengguna Enterprise self-hosted bisa melihat worker yang sedang berjalan beserta metrik performanya di Settings > Workers.
• Error workflow. Pasang workflow error handler terpusat agar kegagalan eksekusi langsung dikirim ke Slack, email, atau WhatsApp tim on-call.

Fitur scaling mana yang gratis dan mana yang berbayar?

Ini bagian yang paling sering disalahpahami. Ringkasan berdasarkan daftar fitur Community Edition dan dokumentasi terkait:

Fitur	Community (gratis)	Butuh lisensi
Queue mode + worker	Ya	-
Webhook processor	Ya	-
Binary data mode database	Ya	-
Endpoint /metrics Prometheus	Ya (dokumentasi tidak menyebut syarat lisensi)	-
External storage S3 untuk binary data	Tidak	Business atau Enterprise self-hosted
Multi-main (high availability main)	Tidak	Enterprise self-hosted
Tampilan Settings > Workers	Tidak	Enterprise self-hosted
Log streaming	Tidak	Enterprise

Artinya, perusahaan bisa mulai scaling dengan queue mode tanpa biaya lisensi. Lisensi baru menjadi relevan ketika Anda butuh high availability di sisi main, penyimpanan binary data di S3, atau fitur tata kelola seperti SSO, log streaming, dan external secrets. Perbandingan lengkap paketnya ada di n8n Enterprise vs Business vs Community, dan gambaran biayanya di harga n8n. Kalau Anda sedang menimbang lisensi Enterprise, kami bisa membantu menyusun kebutuhan (scope) dan menghubungkan Anda langsung dengan tim n8n lewat halaman lisensi n8n Enterprise.

Checklist sebelum go-live

• PostgreSQL produksi dengan backup terjadwal dan uji restore
• Redis dengan password (dan TLS jika lintas jaringan), tidak terbuka ke internet
• N8N_ENCRYPTION_KEY identik di semua proses, tersimpan di secret manager, dan di-backup
• Binary data memakai mode database atau S3, bukan filesystem
• Health check dan /metrics aktif, dengan alert untuk antrean yang memanjang
• Graceful shutdown dikonfigurasi agar deploy tidak memutus eksekusi
• Semua main dan worker memakai versi n8n yang sama
• Error workflow terpusat sudah aktif
• Hardening keamanan dasar sudah dilakukan (lihat checklist keamanan n8n self-hosted)

Butuh bantuan merancang queue mode?

Queue mode tidak sulit dinyalakan, tetapi sulit dijalankan dengan benar dalam jangka panjang: versi yang harus selalu sinkron, encryption key yang tidak boleh hilang, database yang perlu dirawat, dan monitoring yang harus benar-benar dibaca seseorang. WithMi Automation membantu perusahaan merancang dan memasang n8n self-hosted, termasuk queue mode, di infrastruktur milik perusahaan Anda sendiri, lalu menyerahkan dokumentasi dan pelatihan agar tim internal bisa mengoperasikannya.

Lihat cakupan layanannya di jasa setup n8n self-hosted, atau ceritakan kondisi n8n Anda saat ini lewat sesi konsultasi gratis. Kami akan membantu menilai apakah Anda memang butuh queue mode sekarang, atau cukup merapikan workflow dan server yang ada.