Belajar n8n - Self-hosting & Deployment Patterns

#Pendahuluan

Di episode 14 kalian membangun tata kelola untuk tim: role, sharing, dan audit. Sekarang saatnya tempat tinggal yang permanen. Sepanjang seri ini kalian mungkin berjalan di desktop mode atau container sekali jalan — tapi produksi menuntut lebih: data tidak boleh hilang saat container restart, database tidak boleh jadi titik kegagalan, dan beban harus bisa bertambah tanpa rombak besar.

Episode 15 membahas Self-hosting & Deployment Patterns: deploy di Docker Compose, Kubernetes, dan cloud VM, menentukan storage backend serta persistent data, sampai high availability dan scaling worker nodes.

#Memilih Strategi Deployment

Sebelum menulis file konfigurasi, tentukan dulu panggungnya. Tiga pola yang umum:

• Cloud VM — satu atau beberapa VM tempat Docker berjalan. Paling sederhana, cocok untuk tim kecil; kalian bertanggung jawab atas update OS, backup, dan reverse proxy.
• Docker Compose — pengembangan dari satu VM: seluruh stack (n8n, database, Redis, reverse proxy) didefinisikan sebagai file YAML yang bisa di-commit ke Git.
• Kubernetes — untuk organisasi yang sudah menjalankan klaster. Menawarkan auto-scaling, self-healing, dan pemisahan environment yang rapi, dengan biaya kompleksitas yang lebih tinggi.

Aturan praktis: mulai dari Docker Compose di satu VM. Naik ke Kubernetes hanya ketika tim atau beban sudah membutuhkan orkestrasi — bukan karena mengikuti tren.

#Docker Compose untuk Produksi

Stack produksi yang sehat minimal terdiri dari n8n, PostgreSQL sebagai database, dan — bila memakai queue mode — Redis sebagai message queue. Contoh komposisi lengkap:

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - postgres_data:/var/lib/postgresql/data
 
  n8n:
    image: docker.n8n.io/n8nio/n8n
    ports:
      - "5678:5678"
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_USER_MANAGEMENT_JWT_SECRET: ${N8N_USER_MANAGEMENT_JWT_SECRET}
      WEBHOOK_URL: https://n8n.example.com/
      GENERIC_TIMEZONE: Asia/Jakarta
      TZ: Asia/Jakarta
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      - postgres
 
volumes:
  postgres_data:
  n8n_data:

Perhatikan tiga hal: semua rahasia (POSTGRES_PASSWORD, N8N_ENCRYPTION_KEY, N8N_USER_MANAGEMENT_JWT_SECRET) datang dari .env atau secret store, bukan hardcode. Volume n8n_data dan postgres_data menjamin data selamat saat container di-recreate. Dan WEBHOOK_URL disetel ke domain publik agar payload webhook memakai URL yang benar di balik proxy.

#Storage Backend, Database & Persistent Data

Pilihan database menentukan batas instance kalian:

• SQLite — default, cukup untuk penggunaan pribadi dan eksperimen. Tidak cocok untuk multi-user atau queue mode karena akses tulis terkonsentrasi di satu file.
• PostgreSQL — rekomendasi produksi: mendukung multi-user, eksekusi bersamaan, dan menjadi prasyarat saat menjalankan queue mode.

Selain database relasional, ada data biner (file yang diunduh atau dihasilkan workflow). Secara default n8n menyimpannya di filesystem dalam volume n8n. Untuk instance yang skalanya besar, mode penyimpanan bisa diarahkan ke S3 dengan N8N_DEFAULT_BINARY_DATA_MODE=s3 beserta kredensial bucket-nya — memindahkan beban file dari disk ke object storage.

Kunci dari semuanya adalah persistence: setiap state yang bernilai (database, binary data, .env) harus hidup di storage yang tahan restart, dan dicadangkan secara berkala.

#Deploy ke Cloud VM dengan Reverse Proxy

Cloud VM pada dasarnya adalah host Docker di atas. Yang membedakan dengan laptop: traffic masuk harus diakhiri TLS oleh reverse proxy. Caddy dipilih karena otomatis menerbitkan sertifikat Let's Encrypt:

n8n.example.com {
    reverse_proxy n8n:5678
}

Di belakang proxy ini, WEBHOOK_URL di compose diarahkan ke https://n8n.example.com/ sehingga n8n membangun URL webhook yang benar. Batasi pula akses port di security group: buka hanya 80 dan 443 untuk publik, biarkan 5678 hanya dijangkau jaringan internal.

#Deploy ke Kubernetes

Tim yang sudah memakai Kubernetes sebaiknya memakai Helm chart resmi n8n daripada menulis manifest dari nol — chart sudah menangani Deployment, Service, Ingress, Secret, dan opsi persistence:

helm repo add n8n https://n8n-io.github.io/helm-charts
helm repo update
helm install n8n n8n/n8n --values values.yaml

Nilai yang lazim diatur di values.yaml: image dan tag, postgresql.enabled dengan password dari Secret, persistence untuk n8n_data, extraEnv untuk N8N_ENCRYPTION_KEY dan N8N_USER_MANAGEMENT_JWT_SECRET, serta ingress.host untuk domain. Di klaster, manfaat terbesarnya adalah node yang gagal di-restart otomatis dan volume yang dibawa oleh PersistentVolumeClaim.

#Queue Mode & Scaling Worker Nodes

Ketika beban eksekusi mulai banyak, eksekusi tidak perlu selalu berjalan di proses utama. Queue mode memindahkan eksekusi ke antrean Redis, lalu para worker mengambil job dari antrean tersebut. Main tetap menangani UI dan API; worker yang menghabiskan CPU untuk eksekusi.

Aktifkan dengan EXECUTIONS_MODE=queue pada semua layanan, lalu jalankan worker:

n8n worker --concurrency=10

N8N_CONCURRENCY_PRODUCTION_LIMIT=10 n8n worker

Worker bisa dijalankan sebagai container terpisah dengan image yang sama — cukup perintah n8n worker dan env yang sama (EXECUTIONS_MODE=queue, QUEUE_BULL_REDIS_HOST, QUEUE_BULL_REDIS_PORT). Catatan penting: concurrency di bawah 5 bisa membuat environment tidak stabil, jadi mulai dari nilai itu ke atas. Jangan lupa set N8N_COMMUNITY_NODES_ENABLED=true pada main dan worker bila memakai community nodes, karena kedua sisi harus memuat node yang sama.

#High Availability

Menyiapkan redundancy berarti menghilangkan titik kegagalan tunggal:

• Redis dan PostgreSQL dijalankan dengan replikasi atau managed service, sehingga satu node mati tidak melumpuhkan antrean dan database.
• Worker bisa di-scaling horizontal dengan menambah replica — antrean Redis menyalurkan job ke worker mana pun yang menganggur.
• Main bisa multi-instance dengan N8N_MULTI_MAIN_SETUP_ENABLED=true, memungkinkan beberapa replica main di belakang load balancer. Health check QUEUE_HEALTH_CHECK_ACTIVE=true dan endpoint /healthz dari episode 13 memastikan replica yang sehat saja yang melayani traffic.
• Backup rutin untuk database (misalnya pg_dump) dan volume binary data; uji restore secara berkala, karena backup yang tidak pernah diuji sama saja tidak ada.

#Penutup

Episode 15 memindahkan n8n dari eksperimen menjadi layanan produksi. Kalian memilih strategi deployment sesuai konteks, membangun stack Docker Compose dengan PostgreSQL dan volume persistent, mengamankan akses lewat reverse proxy, mengelola deployment di Kubernetes dengan Helm, menyalakan queue mode untuk scaling worker, dan menyusun high availability di atas Redis, PostgreSQL, dan health check.

Inti yang harus dibawa pulang:

• Mulai dari Docker Compose di satu VM, naik ke Kubernetes hanya saat dibutuhkan.
• PostgreSQL wajib untuk produksi, SQLite hanya untuk eksperimen; binary data bisa dipindah ke S3.
• Semua state harus persistent — volume, database, dan .env yang tahan restart.
• Queue mode memindahkan eksekusi ke worker via Redis, dengan concurrency minimal 5.
• High availability berarti menghapus titik kegagalan tunggal dan menguji backup secara rutin.

Di episode 16 berikutnya kita mengorek performa: Performance Optimization — memecah workflow besar menjadi sub-workflow, batch processing dan concurrency, serta mengoptimalkan execution runtime dan throughput. Sampai jumpa!