# Self-Hosting n8n dan Flowise di Platform Bertagihan Rupiah

> n8n dan Flowise sama-sama bisa dideploy sekali klik di platform yang menagih dalam rupiah. Keduanya tidak selamat dari redeploy pertama tanpa persistent volume, webhook URL publik, encryption key yang dipatok, dan authentication.

URL: https://www.matthewswong.com/id/blog/one-click-n8n-flowise-self-host-idr/

- Author: Matthews Wong (https://www.matthewswong.com/id/about/)
- Published: 2026-09-05
- Updated: 2026-09-05
- Category: DevOps

> **Key takeaway:** Deploy sekali klik untuk n8n atau Flowise hanya memberi Anda satu container yang berjalan dan satu URL publik, tidak lebih. Anda sendiri yang memasang persistent volume, mengatur alamat webhook publik, memaku encryption key sebelum boot pertama, dan memasang authentication di depan editor. Lewatkan satu saja, dan redeploy berikutnya menghapus credential Anda tanpa suara.

Daftar template sekali klik di sebuah PaaS Indonesia terbaca seperti daftar keinginan solo builder: Supabase, PostgreSQL, Redis, Uptime Kuma, lalu dua entri yang paling menarik bagi saya, n8n untuk workflow automation dan Flowise untuk membangun LLM flow. Ditagih dalam rupiah, dibayar lewat QRIS atau transfer bank, tanpa kartu kredit sama sekali. Sekali klik, keduanya sudah menjawab di sebuah subdomain dengan TLS yang sudah beres.

Klik itu memang bagian yang mudah, dan bukan bagian yang menentukan apakah instance-nya masih ada bulan depan. Tulisan ini membahas empat hal yang tidak dikerjakan tombol itu untuk Anda, dengan setiap nama environment variable saya cek ke dokumentasi resmi n8n dan Flowise, bukan ke tutorial: persistent volume, URL publik, encryption key, dan authentication.

## Deploy sekali klik memberi container, bukan tempat menyimpan datanya

Mulailah dari kalimat platform-nya sendiri, karena di situ seluruh masalahnya: secara default sebuah service mendapat runtime storage yang ephemeral, dan apa pun yang harus selamat dari redeployment butuh persistent volume yang dipasang. n8n dan Flowise dua-duanya berada di sisi yang salah dari default itu. Keduanya tidak datang dengan database service terpisah, dan keduanya menulis state ke sebuah direktori di dalam container seolah-olah direktori itu masih akan ada besok.

Contoh Docker Compose milik n8n sendiri melakukan kelalaian yang sama secara sengaja dan mengatakannya terang-terangan: tanpa database service, n8n jatuh ke SQLite bawaannya, yang tersimpan di dalam container kecuali Anda memasang volume untuknya. Memasang volume hanya satu kolom di panel deploy. Salah mount path adalah versi mahal dari kolom itu, karena volume yang dipasang di lokasi yang tidak pernah ditulis prosesnya terlihat persis seperti volume yang bekerja.

> Platform yang saya maksud adalah Helipod, yang memasang harga dalam rupiah, menerima QRIS dan transfer bank tanpa kartu kredit, serta memuat n8n dan Flowise di antara template sekali kliknya bersama Supabase, PostgreSQL, Redis dan Uptime Kuma. Semua yang dibahas di bawah berlaku untuk platform container mana pun, bukan hanya yang satu ini:

## Apa yang hilang dari n8n saat container restart tanpa volume

SQLite adalah database default, dan n8n memakainya untuk menyimpan credential, riwayat execution, dan workflow. Direktori data-nya menyimpan lebih dari satu file itu: encryption key, log instance, dan aset yang dibutuhkan fitur source control. Itu seluruh instance dalam satu folder, yang praktis begitu Anda memasangnya dan total begitu Anda tidak.

| Isi direktori data n8n | Harga restart tanpa volume |
| --- | --- |
| Database SQLite, definisi workflow | Semua workflow yang Anda bangun, kembali ke canvas kosong |
| Database SQLite, credential tersimpan | Setiap API key dan OAuth token yang disimpan, terenkripsi dan hilang |
| Database SQLite, riwayat execution | Log jalan yang biasa Anda pakai untuk men-debug workflow gagal |
| File settings, encryption key hasil generate | Kuncinya sendiri, sehingga database yang direstore pun tetap tak terbaca |
| Log instance dan aset source control | Diagnostik lokal dan kunci yang dipakai integrasi Git untuk menandatangani |

Restart adalah bagian yang menjebak, karena tidak selalu Anda yang memicunya. Docker image n8n merestart prosesnya otomatis setelah heap habis, jadi container tanpa volume bisa mengosongkan dirinya sendiri saat tidak ada yang sedang men-deploy apa pun. Perlakukan persistent volume sebagai kolom pertama yang Anda isi, bukan langkah hardening yang bisa menyusul.

## n8n harus diberi tahu URL yang dipakai dunia luar

n8n menyusun webhook URL-nya dengan menggabungkan N8N_PROTOCOL, N8N_HOST dan N8N_PORT, dan dokumentasinya menjelaskan dengan jelas kenapa itu rusak di belakang reverse proxy: n8n berjalan di port 5678 secara internal, sementara proxy memaparkannya ke internet di port 443. Setiap managed platform adalah reverse proxy. Biarkan default-nya dan editor akan memberi Anda alamat callback di localhost, yang bisa Anda tempel dengan santai ke payment gateway atau GitHub App, lalu Anda habiskan satu sore bertanya-tanya kenapa tidak ada yang masuk.

Perbaikannya adalah menyebut base URL publik secara eksplisit dan memberi tahu n8n berapa proxy yang ada di depannya. Perhatikan nama variabelnya sambil mengerjakan itu: N8N_WEBHOOK_URL menggantikan WEBHOOK_URL, yang deprecated sejak n8n 2.35.0 dan mencatat peringatan saat startup. Sebagian besar panduan masih memakai nama lama, jadi instance yang dikonfigurasi dari tutorial memulai hidupnya dengan deprecation warning di log. Flowise punya versi lebih kecil dari kebutuhan yang sama pada APP_URL, yang menjadi tautan di email reset password dan undangan workspace-nya.

## Encryption key dibuat sekali dan tidak pernah diperlihatkan

Ini kegagalan yang paling mahal dan paling terlambat muncul. Jika N8N_ENCRYPTION_KEY tidak diset, n8n membuat kunci acak saat launch pertama, menyimpannya ke folder data, dan memakainya untuk mengenkripsi setiap credential sebelum masuk database. Tidak ada satu pun bagian antarmuka yang memperlihatkan nilai itu. Redeploy tanpa foldernya, atau restore database di sebelah kunci baru yang baru saja digenerate, dan semua credential berubah menjadi ciphertext yang Anda miliki tetapi tidak bisa Anda baca.

Flowise gagal dengan cara yang sama dan bahkan menerbitkan pesan errornya, yang justru membantu. Dokumentasinya mencatat bahwa encryption key kadang digenerate ulang atau path penyimpanannya berubah, bahwa hasilnya adalah error credentials could not be decrypted, dan bahwa menyetel FLOWISE_SECRETKEY_OVERWRITE membuat kunci yang sama selalu dipakai. Dua variabel, digenerate sekali, disimpan di password manager, ditempel ke secret variable milik platform. Itu seluruh mitigasinya.

> Setel kedua kunci sebelum boot pertama. Kalimat n8n cukup teliti: Anda bisa memberikan kunci sendiri selama kunci itu belum masuk ke file settings. Setelah n8n membuat kuncinya sendiri, mengubah variabel itu tidak mengenkripsi ulang apa pun, melainkan membuat credential yang tersimpan tidak terbaca. Karena itu rotasi kunci adalah fitur opt-in terpisah yang dokumentasinya dibuka dengan perintah mengambil full backup database lebih dulu.

*Baca tag-nya, bukan labelnya: masing-masing menyebut hal yang benar-benar Anda ketik di panel deploy, dan band paling bawah yang dilebarkan adalah satu-satunya entri di sini yang datang tanpa pesan error apa pun.*

## Flowise menulis ke empat path, dan hanya dua yang satu folder

Default Flowise adalah jebakan yang tidak selesai dengan satu volume mount. Database SQLite-nya mendarat di folder .flowise di bawah home directory user container, dan file yang diupload di subfolder storage di dalamnya, itu masih rapi. Encryption key dan log-nya default ke tempat yang sama sekali lain, di bawah package server di dalam direktori aplikasi. Pasang volume hanya di path database dan Anda menyimpan semua chatflow sambil kehilangan kunci yang mendekripsi credential yang menempel padanya.

- Arahkan DATABASE_PATH, BLOB_STORAGE_PATH, SECRETKEY_PATH dan LOG_PATH ke direktori mount yang sama, supaya satu volume menutupi keempatnya.
- Periksa user container sebelum menyalin mount path dari mana pun: compose file resmi Flowise memasang ke folder .flowise di bawah /home/node karena image-nya berjalan sebagai user node non-root, sementara panduan lama masih menunjukkan path di bawah /root.
- Biarkan SECRETKEY_STORAGE_TYPE bernilai local kecuali Anda benar-benar memakai AWS Secrets Manager, karena itu yang dicari oleh nilai satunya.

Detail user itu lebih penting daripada kelihatannya, sebab mount di path yang tidak pernah disentuh prosesnya sama sekali tidak memunculkan error. Flowise tetap start, tetap bekerja, dan menulis state sebenarnya ke lapisan ephemeral di sebelah volume kosong Anda. Satu-satunya cara menangkapnya adalah membuat satu credential, redeploy dengan sengaja, lalu memastikan credential itu masih bisa didekripsi, tes dua menit yang layak dikerjakan saat Anda belum punya apa pun untuk hilang.

## Flowise menjangkau internet publik sebelum Anda sekali pun login

Sebuah instance Flowise adalah gudang API key milik orang lain, termasuk key model provider dan key vector database Anda, yang duduk di belakang satu web UI. Sejak v3.0.1 ia melakukan authentication dengan benar, memakai sistem berbasis Passport.js dan JWT yang disimpan di HTTP-only cookie, dan pasangan lama FLOWISE_USERNAME serta FLOWISE_PASSWORD adalah jalur deprecated yang dipertahankan agar install lama bisa login sekali untuk mengklaim akun admin baru. Sebagian besar tutorial belum menyusul, dan dari situ instance berakhir di jalur deprecated, atau tanpa jalur sama sekali.

Poin yang lebih tajam adalah apa yang terjadi kalau Anda tidak menyetel apa pun. Dokumentasi Flowise menganjurkan Anda mengonfigurasi sendiri variabel JWT dan secret token, karena kalau tidak nilai default yang dipakai, dan itu memperbesar peluang penyerang memalsukan token yang valid lalu menyamar sebagai pengguna. Default terdokumentasi untuk EXPRESS_SESSION_SECRET adalah string flowise apa adanya. Empat nilai acak plus NUMBER_OF_PROXIES, diset saat deploy, sudah menutupnya. Padanannya di n8n adalah N8N_USER_MANAGEMENT_JWT_SECRET, yang juga digenerate saat start kalau dibiarkan, satu alasan lagi kenapa folder datanya bukan opsional.

## Di mana plan kecil benar-benar terasa menggigit

Kedua project tidak menerbitkan angka memori minimum dan saya tidak akan mengarangnya. Yang memang dikatakan dokumentasi n8n adalah bahwa ia tidak membatasi berapa banyak data yang boleh diambil dan diproses sebuah node, dan justru sifat itulah yang mengubah workflow yang tampak wajar menjadi heap habis di container kecil. Dokumen itu juga mendaftar apa yang menggelembungkan satu run: ukuran payload JSON, ukuran binary data, jumlah node, node Code secara khusus, dan manual execution, karena run manual membuat salinan kedua datanya untuk frontend.

Flowise menerbitkan rekomendasi production, bukan angka minimum, dan itu lebih cocok dibaca sebagai kalibrasi ketimbang sebagai syarat: queue mode dengan dua main server yang di-load-balance mulai dari empat vCPU dan delapan gigabyte RAM masing-masing, ditambah empat worker berukuran sama. Itu menggambarkan deployment ramai yang dipakai bersama, bukan chatflow satu builder, tetapi tetap memberi tahu Anda dari arah mana tekanannya datang. Di plan satu atau dua gigabyte, jalankan kedua service secara terpisah, pecah job besar menjadi run yang lebih kecil, dan siapkan diri bahwa node Code adalah tempat plafonnya muncul lebih dulu.

> Sebelum mempercayai instance baru, rusakkan dulu dengan sengaja. Simpan satu credential, jalankan satu workflow, lalu redeploy memakai tombol platform itu sendiri dan periksa apakah credential-nya masih bisa didekripsi. Satu tes itu menangkap volume yang belum dipasang, mount path yang salah, dan encryption key yang belum diset sekaligus, pada satu-satunya saat ketika kehilangan ketiganya tidak merugikan Anda.

Template sekali klik layak dipakai, hanya saja namanya salah menjual. Yang benar-benar dikerjakan tombol itu adalah build, start, routing, dan enkripsi jalur transportnya, bagian yang dulu memakan satu sore untuk konfigurasi nginx. Yang tidak bisa ia ketahui adalah bahwa container ini menyimpan sebuah database, sebuah secret, dan sebuah identitas publik. Jadi empat keputusan tetap milik Anda pada setiap template yang stateful: pasang volume, publikasikan URL yang sebenarnya, patok encryption key, dan setel secret authentication sebelum request pertama datang.

## Sumber

- Dokumentasi n8n, environment variable deployment, termasuk N8N_ENCRYPTION_KEY dan N8N_USER_FOLDER
- Dokumentasi n8n, mengonfigurasi webhook URL di belakang reverse proxy
- Dokumentasi Flowise, environment variable untuk database, storage dan credential
- Dokumentasi Flowise, authorization tingkat aplikasi dan konfigurasi JWT
- Dokumentasi Helipod, services, runtime storage ephemeral dan persistent volume

*Kolom paling kanan adalah yang selalu lolos dari pengujian manual, karena webhook baru gagal ketika ada sistem luar yang mencoba memanggilnya.*

## Source links

- https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/deployment
- https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/configure-webhook-urls-with-reverse-proxy
- https://docs.flowiseai.com/configuration/environment-variables
- https://docs.flowiseai.com/configuration/authorization/app-level

## FAQ

### Kenapa workflow n8n saya hilang setelah redeploy?

Karena container-nya tidak punya persistent volume. n8n menyimpan workflow, credential, dan riwayat execution di database SQLite bawaan, dan di platform container runtime storage bersifat ephemeral secara default, sehingga file itu hidup dan mati bersama container. Pasang volume dengan mount di direktori data n8n, dan redeploy yang sama jadi tidak berbahaya.

### Apa mount path volume yang benar untuk n8n dan Flowise di Docker?

Untuk n8n path-nya /home/node/.n8n, tempat user node di dalam image menyimpan database SQLite, file settings, dan log instance. Compose file resmi Flowise memasang folder .flowise di bawah /home/node dengan alasan yang sama, karena container itu juga berjalan sebagai user node non-root. Panduan lama yang menunjukkan path di bawah /root dibuat sebelum perubahan tersebut dan memasang direktori yang tidak pernah ditulis prosesnya.

### Kenapa n8n memberikan webhook URL localhost yang tidak bisa dijangkau siapa pun?

n8n menyusun webhook URL dari N8N_PROTOCOL, N8N_HOST dan N8N_PORT, yang default-nya http, localhost, dan 5678. Di belakang reverse proxy, dan setiap managed platform adalah reverse proxy, nilai-nilai itu menggambarkan bagian dalam container, bukan alamat publiknya. Setel N8N_WEBHOOK_URL ke base URL Anda yang sebenarnya dan N8N_PROXY_HOPS ke jumlah proxy yang ada di depannya.

### Bisakah saya menyetel N8N_ENCRYPTION_KEY setelah n8n sudah berjalan?

Anda hanya bisa memberikan kunci sendiri selama kunci itu belum masuk ke file settings. Setelah n8n membuat kuncinya sendiri saat launch pertama, mengarahkan variabel itu ke nilai lain tidak mengenkripsi ulang apa pun dan justru membuat credential yang tersimpan tidak terbaca. Mengganti kunci yang sudah dipakai adalah fitur rotasi opt-in terpisah yang dokumentasinya meminta Anda mengambil full backup database lebih dulu.

### Apakah plan satu gigabyte cukup untuk menjalankan n8n dan Flowise sekaligus?

Kedua project tidak menerbitkan angka memori minimum, jadi anggap ini bergantung pada beban kerja, bukan angka tetap. Dokumentasi n8n mencatat bahwa ia tidak membatasi berapa banyak data yang boleh diambil dan diproses sebuah node, dan bahwa node Code, binary payload besar, serta manual execution semuanya menggelembungkan satu run. Jalankan kedua service secara terpisah, pecah job besar, dan awasi baris JavaScript heap out of memory di log.

---

- HTML version: https://www.matthewswong.com/id/blog/one-click-n8n-flowise-self-host-idr/
- English: https://www.matthewswong.com/en/blog/one-click-n8n-flowise-self-host-idr/
- Site index for agents: https://www.matthewswong.com/llms.txt
- Sitemap: https://www.matthewswong.com/sitemap.xml
- API description (OpenAPI): https://www.matthewswong.com/openapi.json