Panduan Install n8n Self-Hosted untuk Perusahaan: Docker, Postgres, HTTPS, Backup

Banyak tutorial "install n8n self hosted" berhenti di satu perintah docker run dan sebuah halaman login. Itu cukup untuk mencoba, tetapi belum cukup untuk perusahaan yang akan menaruh credential CRM, akses database, dan data pelanggan di dalamnya. n8n self hosted untuk produksi butuh lima hal yang jarang dibahas tuntas: database yang tepat, HTTPS di belakang reverse proxy, encryption key yang Anda kendalikan, backup yang benar-benar bisa di-restore, dan rutinitas update.

Panduan ini ditulis oleh Fahmi Fahreza, n8n Ambassador dan founder WithMi Automation, dari pengalaman menyiapkan n8n on premise dan di VPS untuk tim bisnis di Indonesia. Fokusnya bukan "apa itu self-hosted" (sudah kami bahas di perbandingan self-hosted vs cloud automation), melainkan cara menjalankan n8n self-hosted dengan standar perusahaan.

Sebelum mulai: apakah self-host memang pilihan yang tepat?

Dokumentasi resmi n8n cukup jujur soal ini: self-hosting butuh kemampuan teknis, mulai dari menyiapkan server dan container, mengelola resource, sampai mengamankan server dan aplikasi. Kesalahan konfigurasi bisa berujung pada kehilangan data, celah keamanan, atau downtime. n8n sendiri menyarankan n8n Cloud bagi tim yang belum berpengalaman mengelola server.

Jadi pertanyaan pertamanya bukan "bisa atau tidak", tetapi "siapa yang akan bertanggung jawab atas server ini enam bulan dari sekarang". Self-host masuk akal untuk perusahaan jika:

• Data yang diproses sensitif dan Anda ingin kendali penuh atas lokasi dan akses datanya.
• Volume eksekusi tinggi sehingga model biaya per eksekusi di cloud mulai terasa berat (lihat juga rincian harga n8n).
• Ada tim IT atau mitra yang siap merawat server, memantau, dan menerapkan update keamanan.

Jika poin ketiga belum ada, itu bukan alasan membatalkan self-host. Itu tanda Anda perlu merencanakan siapa yang mengelolanya sejak awal.

Arsitektur minimum yang layak untuk produksi

Untuk satu instance n8n perusahaan, susunan berikut sudah mencakup kebutuhan dasar tanpa berlebihan:

Komponen	Pilihan	Kenapa
Runtime	Docker + Docker Compose	Cara instalasi yang didokumentasikan n8n, mudah di-update dan dipindah
Database	PostgreSQL 16 ke atas	SQLite cukup untuk uji coba; Postgres untuk backup, beban, dan queue mode
Reverse proxy	Caddy, Traefik, atau Nginx	Menangani HTTPS dan sertifikat; n8n tidak dibuka langsung ke internet
Penyimpanan	Volume Docker persisten	Folder .n8n dan data Postgres tidak boleh hilang saat container dibuat ulang
Backup	pg_dump terjadwal + salinan encryption key	Tanpa key, backup credential tidak berguna

Dokumentasi n8n menyebut SQLite sebagai database default jika tidak ada yang dikonfigurasi, dan PostgreSQL sebagai opsi untuk self-hosted. Per dokumentasi terbaru, versi PostgreSQL minimum adalah 16, dengan dukungan untuk dua versi mayor terbaru.

Langkah 1: siapkan server dan domain

Beberapa hal yang perlu diputuskan sebelum menyentuh terminal:

• Sistem operasi. Distribusi Linux LTS yang tim Anda kuasai. Konsistensi lebih penting daripada pilihan distro.
• Ukuran server. Untuk perusahaan, 2 vCPU dan 4 GB RAM dengan Postgres di server yang sama adalah titik awal yang wajar. Workflow yang memproses file besar atau banyak memanggil model AI butuh lebih. Pantau pemakaian nyata sebelum menaikkan spesifikasi.
• Subdomain. Misalnya n8n.perusahaan.co.id, dengan A record yang mengarah ke IP server. HTTPS butuh domain.
• Firewall. Buka hanya port 80 dan 443 ke publik, plus SSH yang dibatasi (idealnya hanya dari IP kantor atau VPN). Port 5678 milik n8n dan port 5432 milik Postgres tidak boleh terbuka ke internet.

Langkah 2: buat encryption key sendiri

Ini langkah yang paling sering terlewat. Saat pertama kali jalan, n8n membuat encryption key acak dan menyimpannya di folder ~/.n8n. Key ini dipakai untuk mengenkripsi semua credential sebelum disimpan ke database.

Masalahnya, jika key itu hanya hidup di dalam volume container, Anda bisa kehilangannya saat migrasi server atau volume terhapus. Backup database lengkap pun tidak bisa dipakai, karena credential di dalamnya tidak bisa didekripsi. Jadi tetapkan key sendiri lewat variabel N8N_ENCRYPTION_KEY sebelum instance pertama kali dijalankan:

openssl rand -hex 32

Simpan hasilnya di password manager atau secret store perusahaan, terpisah dari server dan dari backup database. Jika nanti memakai queue mode, key yang sama wajib dipasang di semua worker.

Langkah 3: Docker Compose dengan PostgreSQL

Buat folder proyek, lalu file .env untuk menyimpan rahasia (jangan commit file ini ke Git):

# .env
POSTGRES_USER=n8n
POSTGRES_PASSWORD=ganti-dengan-password-panjang-acak
N8N_ENCRYPTION_KEY=hasil-openssl-rand-hex-32
N8N_DOMAIN=n8n.perusahaan.co.id

Lalu compose.yaml:

services:
  postgres:
    image: postgres:17
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    # Pin versi stable yang spesifik. Contoh per Oktober 2026; cek versi terbaru di docs.n8n.io.
    image: n8nio/n8n:2.43.7
    restart: unless-stopped
    ports:
      - "127.0.0.1:5678:5678"   # hanya bisa diakses dari server itu sendiri (reverse proxy)
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      N8N_HOST: ${N8N_DOMAIN}
      N8N_PORT: 5678
      N8N_PROTOCOL: https
      N8N_WEBHOOK_URL: https://${N8N_DOMAIN}/
      N8N_PROXY_HOPS: 1
      NODE_ENV: production
      GENERIC_TIMEZONE: Asia/Jakarta
      TZ: Asia/Jakarta
      N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS: "true"
    volumes:
      - n8n_data:/home/node/.n8n
    depends_on:
      postgres:
        condition: service_healthy

volumes:
  pg_data:
  n8n_data:

Beberapa catatan penting dari konfigurasi di atas:

• Pin versi image. Dokumentasi n8n menyebut tag stable untuk produksi dan beta bisa tidak stabil. Tag yang mengambang membuat server Anda bisa ter-update tanpa sengaja saat container dibuat ulang. Tulis nomor versi spesifik dan naikkan secara sadar.
• N8N_WEBHOOK_URL. Wajib saat n8n berjalan di belakang reverse proxy, agar URL webhook yang ditampilkan n8n memakai domain publik Anda. Nama lama WEBHOOK_URL masih berfungsi sebagai alias tetapi sudah deprecated sejak n8n 2.35.0. Jika Anda menjalankan versi lebih lama, cek nama variabel yang berlaku di versi itu.
• N8N_PROXY_HOPS: 1. Memberi tahu n8n bahwa ada satu reverse proxy di depannya, supaya IP klien dan header terbaca dengan benar.
• GENERIC_TIMEZONE. Jika tidak di-set, default-nya zona waktu New York, dan jadwal Cron Anda akan meleset beberapa jam dari WIB.
• Port 127.0.0.1:5678. n8n hanya bisa dijangkau dari server itu sendiri. Akses publik wajib lewat reverse proxy.

Langkah 4: HTTPS lewat reverse proxy

Contoh resmi Docker Compose di dokumentasi n8n memakai Traefik untuk sertifikat TLS dan routing. Alternatif yang lebih sederhana untuk satu server adalah Caddy, yang mengurus sertifikat Let's Encrypt secara otomatis. Caddyfile minimalnya:

n8n.perusahaan.co.id {
    reverse_proxy 127.0.0.1:5678
}

Nginx juga bisa, asalkan Anda mengatur sertifikat dan dukungan WebSocket untuk editor n8n. Apa pun pilihannya, prinsipnya sama: hanya proxy yang menghadap internet, dan semua akses memakai HTTPS. Secara default n8n mengirim cookie sesi hanya lewat HTTPS (N8N_SECURE_COOKIE=true). Jangan mematikan setting itu sebagai jalan pintas; perbaiki HTTPS-nya.

Jalankan stack-nya:

docker compose up -d
docker compose logs -f n8n

Buka https://n8n.perusahaan.co.id, buat akun owner, lalu langsung aktifkan 2FA di Settings > Personal.

Langkah 5: backup yang benar-benar bisa di-restore

Menurut dokumentasi backup n8n, ada beberapa hal yang harus ikut diamankan:

1. Database PostgreSQL, dengan tool bawaan database. Contoh harian:

   docker compose exec -T postgres pg_dump -U n8n -d n8n -Fc > n8n-$(date +%F).dump
   

2. Folder .n8n, yang berisi file konfigurasi dengan encryption key (dan file data jika Anda memakai mode penyimpanan filesystem untuk binary data).

3. Konfigurasi deployment: file compose.yaml, variabel koneksi database, dan N8N_ENCRYPTION_KEY.

4. Ekspor workflow dan credential sebagai lapisan tambahan:

   n8n export:workflow --backup --output=backups/workflows/
   n8n export:credentials --backup --output=backups/credentials/
   

   Ekspor ini hanya mencakup workflow dan credential, tidak termasuk user, riwayat eksekusi, atau encryption key. Di Docker, folder di dalam container tidak persisten, jadi mount folder host atau salin file keluar.

Dua aturan yang tidak bisa ditawar: simpan backup di lokasi berbeda dari server produksi, dan uji restore secara berkala ke server terpisah. Backup yang belum pernah di-restore belum terbukti sebagai backup.

Langkah 6: rutinitas update

Dokumentasi n8n menyarankan update setidaknya sebulan sekali, agar Anda tidak harus melompati banyak versi sekaligus. Ini juga soal keamanan: n8n rutin menerbitkan security advisory di repositori GitHub mereka, dan sebagian berkategori high. Instance yang tertinggal berbulan-bulan adalah risiko nyata.

Alur update yang aman:

1. Baca release notes untuk breaking changes.

2. Backup database dan pastikan encryption key tersimpan.

3. Uji versi baru di instance staging.

4. Ubah nomor versi image di compose.yaml, lalu:

   docker compose pull
   docker compose down
   docker compose up -d
   

5. Cek log dan jalankan beberapa workflow kritis.

Langkah 7: atur retensi data eksekusi

Setiap eksekusi menyimpan input dan output tiap node, yang bisa berisi data pelanggan. Secara default n8n memangkas data eksekusi setelah 336 jam (14 hari) dan menyimpan maksimal 10.000 eksekusi. Sesuaikan dengan kebijakan perusahaan lewat EXECUTIONS_DATA_MAX_AGE dan EXECUTIONS_DATA_PRUNE_MAX_COUNT, dan pertimbangkan EXECUTIONS_DATA_SAVE_ON_SUCCESS=none untuk workflow bervolume tinggi yang tidak perlu ditelusuri ulang. Retensi yang lebih pendek berarti database lebih ringan dan data sensitif lebih sedikit yang tersimpan.

Untuk lapisan keamanan berikutnya (SSO, task runner, SSRF protection, webhook, dan lain-lain), gunakan checklist keamanan n8n self-hosted sebagai lanjutan panduan ini.

Kapan perlu pindah ke queue mode?

Mode default n8n (regular) menjalankan semua eksekusi di satu proses. Itu cukup untuk banyak perusahaan. Tanda Anda mulai butuh queue mode:

• Editor terasa lambat saat banyak workflow berjalan bersamaan.
• Webhook bervolume tinggi mulai antre atau timeout.
• Satu workflow berat bisa menahan workflow lain.

Di queue mode, instance utama menerima trigger dan webhook, lalu mengirim eksekusi ke worker lewat Redis. Syaratnya menurut dokumentasi n8n: PostgreSQL (SQLite tidak didukung untuk setup terdistribusi), Redis, EXECUTIONS_MODE=queue di instance utama dan semua worker, serta encryption key yang sama di semua node. Satu hal yang sering mengejutkan: n8n tidak mendukung queue mode dengan penyimpanan binary data di filesystem, sehingga workflow yang mengolah file perlu external storage.

Queue mode sendiri tersedia di Community Edition. Yang membutuhkan lisensi Enterprise adalah multi-main setup (beberapa instance utama untuk high availability). Pembahasan lengkapnya ada di artikel n8n queue mode dan scaling.

Di mana meng-host n8n untuk perusahaan Indonesia?

Pilihannya kira-kira tiga:

• Region Jakarta dari cloud global. Beberapa penyedia cloud besar sudah punya region di Jakarta. Cocok jika perusahaan sudah memakai ekosistem tersebut dan butuh layanan terkelola seperti database dan object storage.
• Penyedia cloud atau VPS lokal. Data center di Indonesia, penagihan dalam rupiah, dan dukungan berbahasa Indonesia. Pastikan ada snapshot, backup, dan SLA yang jelas.
• On premise di server internal. n8n on premise memberi kendali paling penuh, tetapi Anda juga menanggung listrik, jaringan, perangkat keras, dan akses dari luar untuk webhook.

Lokasi server hanyalah satu bagian dari kepatuhan. Jika pertimbangan Anda adalah UU PDP dan data residency, baca n8n, UU PDP, dan data residency sebelum memutuskan. Di semua opsi di atas, server dan lisensi tetap milik perusahaan Anda.

Kapan sebaiknya memakai jasa setup n8n?

Langkah-langkah di atas bisa dikerjakan tim IT internal yang terbiasa dengan Linux dan Docker. Jasa setup n8n masuk akal jika:

• Tidak ada orang yang ditugaskan untuk update bulanan dan uji restore.
• Perusahaan butuh SSO, pemisahan environment, atau audit trail, yang berarti juga perlu memilih lisensi yang tepat (lihat perbandingan n8n Enterprise vs Business vs Community).
• Volume sudah menuntut queue mode, worker, dan Redis.
• Anda ingin instance siap pakai dengan workflow pertama yang benar-benar berjalan, bukan sekadar halaman login.

WithMi membantu perusahaan menyiapkan n8n self-hosted di infrastruktur milik Anda sendiri, mulai dari hardening server, backup, sampai dokumentasi serah terima. Instance dan lisensinya tetap atas nama perusahaan Anda. Gambaran lengkap layanan kami ada di halaman n8n Indonesia.

Ringkasan

• Pakai Docker Compose, PostgreSQL 16+, dan reverse proxy dengan HTTPS. Jangan buka port n8n langsung.
• Tetapkan N8N_ENCRYPTION_KEY sendiri dan simpan terpisah dari backup.
• Backup database, folder .n8n, dan konfigurasi; uji restore secara berkala.
• Pin versi image, update minimal sebulan sekali lewat staging.
• Atur retensi eksekusi, lalu lanjutkan dengan checklist keamanan.
• Pindah ke queue mode saat beban menuntut, bukan sejak hari pertama.

Jika Anda ingin memastikan setup n8n perusahaan sudah layak produksi, atau butuh bantuan memutuskan antara self-host dan Cloud, jadwalkan konsultasi dengan tim kami. Kami akan meninjau kebutuhan dan infrastruktur Anda lebih dulu sebelum merekomendasikan apa pun.