Pengalaman Migrasi n8n 2GB: Mindahin Database, Nyelametin Credential, dan Beresin Docker Compose
Sabtu, 18 Jul 2026
Ada dua hal yang paling malesin pas ngurus server: migrasi database gede dan benerin Docker Compose yang error.
Kali ini gw dapet dua-duanya sekaligus wkwkw.
Awalnya semua ini gara-gara masa trial Google Cloud yang gw pake hampir habis. Sekitar tiga bulan sebelumnya, gw bikin VM di Google Cloud buat jalanin n8n. Waktu pertama dipasang, isinya masih sedikit. Cuma beberapa workflow eksperimen, bot Telegram, dan automation kecil yang masih gw utak-atik.
Karena terus dipake, lama-lama workflow-nya makin banyak. Mulai ada sistem omnichannel, workflow Instagram, Gen AI Builder, berbagai credential API, webhook, community node, sampai ribuan history execution.
Tanpa kerasa, database SQLite-nya udah bengkak hampirĀ 2GB.
Masalahnya, masa trial Google Cloud tetap berjalan. Mau workflow gw masih banyak atau credential belum dibackup, Google Cloud tentu tidak ikut memikirkan nasib bot Telegram gw wkwkw.
Sebelum kredit trial-nya habis dan VM lama dihapus, gw harus mindahin seluruh instance n8n ke VPS baru yang menggunakan AlmaLinux dan aaPanel.
Targetnya bukan cuma bikin halaman login n8n muncul lagi. Semua workflow, credential, user login, webhook, community node, binary data, dan history execution harus tetap ada.
Jadi kali ini gw mau bahas sedikit tentang how to migrate n8n safely, khususnya dari server GCP lama ke server AlmaLinux baru menggunakan Docker dan aaPanel.
Securing Database SQLite 2GB
Pernah ga lo mindahin server production yang database SQLite-nya udah bengkak sampai hampir 2GB?
Nah, gw baru aja ngerjain ini buat flow.bisnisgo.id.
Secara sederhana, ada tiga komponen utama yang harus dipindahkan:
-
File
.envyang menyimpan encryption key dan konfigurasi n8n. -
Database SQLite beserta data di Docker volume.
-
File
docker-compose.ymluntuk menjalankan n8n di server baru.
Bagian paling pentingnya justru ada di .env.
Credential n8n disimpan di database dalam kondisi terenkripsi. Jadi supaya password, token, dan API key lama bisa dibaca di server baru, n8n membutuhkan encryption key yang sama.
Kurang lebih bentuknya seperti ini:
N8N_ENCRYPTION_KEY=KUNCI_ENKRIPSI_LAMA Kalau database 2GB berhasil dipindahkan tapi encryption key-nya ketinggalan, credential lo bisa muncul di dashboard, tetapi isinya ga bakal terbaca dengan benar.
Sebelum backup, gw hentikan container lama dulu supaya SQLite tidak sedang ditulis oleh workflow yang masih aktif.
docker stop NAMA_CONTAINER Setelah itu seluruh data n8n gw kompres menjadi satu file backup:
tar -czf /root/n8n-backup-lengkap.tar.gz \ -C /var/lib/docker/volumes/n8n_data/_data . Database aslinya hampir 2GB, tetapi setelah dikompres ukuran arsipnya jadi sekitar 935MB.
Proses download-nya hampir dua jam karena kecepatannya cuma sekitar 100 sampai 137KB per detik. Benar-benar waktu yang tepat bagi koneksi internet untuk kembali ke masa lalu.
Setelah file selesai dipindahkan ke VPS AlmaLinux, backup tersebut gw ekstrak ke Docker volume yang baru:
tar -xzf n8n-backup-lengkap.tar.gz \ -C /var/lib/docker/volumes/n8n_data/_data Gw juga memastikan file database.sqlite, folder community node, binary data, dan konfigurasi lainnya benar-benar ikut masuk.
Setelah database dan .env aman, gw pikir bagian paling sulitnya udah selesai.
Ternyata belum.
Sisa sisa OpenClaw di Docker Compose
Setelah semua file berhasil dipindahkan, gw langsung menjalankan command sakti:
docker compose up -d Ekspektasinya tentu image ditarik, network dibuat, lalu container berubah jadi Started.
Realitanya malah muncul error:
invalid spec Setelah gw cek, ternyata file docker-compose.yml dari server lama masih menyimpan sisa konfigurasi service eksperimen bernama OpenClaw.
Service itu sebenarnya udah ga dipake. Image dan beberapa referensinya juga udah ga tersedia di server baru. Tapi karena blok konfigurasinya masih ada, Docker Compose tetap mencoba membacanya.
Bisa di-run?
SANGAT... SANGAT GA BISA wkwkwk.
Akhirnya gw bersihin file Compose lama dan bikin ulang konfigurasi yang cuma fokus menjalankan n8n.
services: n8n: image: docker.n8n.io/n8nio/n8n:latest container_name: n8n_bot_bisnisgo restart: unless-stoppedports:
- "127.0.0.1:***2:5***"
env_file:
- .env
volumes:
- n8n_data:/home/node/.n8n
Sebelum dijalankan lagi, gw cek dulu hasil konfigurasi akhirnya:
docker compose config Command ini berguna buat memastikan file YAML valid, .env terbaca, volume-nya benar, dan ga ada service lama yang masih numpang hidup.
Setelah Compose bersih, baru gw jalankan lagi:
docker compose up -d Kali ini container berhasil hidup dan n8n bisa diakses dari port lokalĀ ****
Ā
.
Tapi pekerjaannya belum selesai. Container udah hidup, domain production-nya belum.
Masalah DNS dan SSL di aaPanel
Domain utama yang gw pake adalah:
flow.bisnisgo.id Karena n8n dijalankan di balik Nginx Reverse Proxy aaPanel, gw harus mengatur DNS, SSL, dan proxy ke port internal n8n.
Masalahnya, SSL Letās Encrypt baru bisa diterbitkan kalau domain sudah mengarah ke IP AlmaLinux yang baru.
Tapi kalau DNS dipindahkan terlalu cepat sementara container n8n belum siap, request webhook dari Telegram atau service lain bakal masuk ke server yang belum bisa melayaninya.
Makanya sebelum mindahin DNS, gw pastikan dulu n8n sudah merespons dari localhost:
curl -I http://127.0.0.1:**** Setelah container stabil, baru record DNS di Cloudflare gw arahkan ke IP server AlmaLinux.
Di aaPanel, gw bikin website tipe Pure Static untuk flow.bisnisgo.id, pasang SSL Letās Encrypt, matiin cache, lalu aktifkan Reverse Proxy dengan target:
http://127.0.0.1:**** Konfigurasi domain di .env juga gw sesuaikan:
N8N_HOST=flow.bisnisgo.id N8N_PROTOCOL=https N8N_PORT=**** WEBHOOK_URL=https://flow.bisnisgo.id/Setelah itu container dijalankan ulang supaya konfigurasi barunya terbaca.
docker compose down docker compose up -d The Result?
Yuk kita tes.
Gw akses flow.bisnisgo.id dari browser, lalu halaman login n8n muncul.
Gw masuk menggunakan username dan password lama.
BISA LOGIN! HAHAHA
Ā
Semua workflow masih ada. Insta System, Gen AI Builder, bot Telegram, community node, sampai history execution yang sukses maupun gagal tetap utuh.
Credential juga masih bisa digunakan karena database dan encryption key berhasil dipindahkan bersama.
Setelah itu workflow gw aktifkan satu per satu sambil memantau execution dan log. Gw ga langsung mengaktifkan semuanya karena kalau ada error, bakal lebih gampang mencari workflow mana yang bermasalah.
THATāS WHY I PREFER DOCKER FOR N8N MIGRATION INSTEAD OF NATIVE INSTALL.
Dalam kasus migrasi server, pemisahan antara image, konfigurasi, dan persistent volume bikin prosesnya jauh lebih terkontrol.
Kalau instalasi native pake NPM, urusan versi Node.js, dependency, permission, dan process manager bisa lebih panjang lagi.
Dari proses ini gw juga sadar kalau jasa migrasi n8n sebenarnya punya nilai yang lumayan tinggi.
Yang dijual bukan cuma kemampuan bikin container berubah jadi Started. Yang dijual adalah memastikan database tidak rusak, credential tetap terbaca, webhook kembali aktif, dan automation klien tetap berjalan setelah pindah server.
Catatan Terakhir
Sekarang domain flow.bisnisgo.id udah ga aktif lagi karena gw juga udah ga gabung di company tersebut.
Waktu ngerjain itu lumayan banyak trial and error, tapi justru di situ serunya. Dari satu kasus ini gw jadi lebih ngerti cara kerja Docker volume, encryption key n8n, struktur database SQLite, deployment di aaPanel, dan risiko kecil yang bisa bikin satu sistem automation mati total.
Walaupun server dan domainnya udah ga dipake, pengalamannya tetap relevan. Buat gw, ini bukan sekadar cerita mindahin n8n, tapi salah satu tantangan server yang bikin kemampuan troubleshooting gw naik cukup jauh.
Dan jujur aja, kasus kayak gini lebih seru daripada cuma install n8n dari nol terus lihat halaman login muncul. Yang susah itu bukan bikin sistem hidup, tapi bikin sistem lama pindah tanpa kehilangan ingatan.
