Cara Update n8n di Docker Tanpa Kehilangan Workflow: Backup, Update, dan Rollback

Update n8n docker sebenarnya hanya dua perintah: docker compose pull lalu docker compose up -d. Yang membuatnya berisiko adalah langkah yang tidak terlihat: begitu versi baru menyala, n8n langsung mengubah struktur database (migrasi). Kalau versi baru bermasalah dan Anda tidak punya backup, jalan pulangnya tidak bersih.

Di artikel ini kami menjalankan seluruh siklusnya di server sungguhan: backup, update dari n8n 2.45.7 ke 2.47.2, mencoba rollback, memulihkan backup ke PostgreSQL 17, lalu membersihkan image lama. Hasilnya: n8n hanya tidak bisa diakses 11 detik, dan semua workflow utuh.

Diuji 5 November 2026 di Super Cloud Regular 1 vCPU · 2 GB, Ubuntu 24.04.5 LTS, Docker 29.9.3. Susunan awal: n8n 2.45.7 + PostgreSQL 16 + Caddy 2 di folder /opt/n8n, seperti di panduan install n8n di VPS. Semua keluaran di bawah adalah hasil asli.

Sebelum update n8n di Docker: cek versi dan catatan rilis

Pastikan Anda bekerja di folder yang berisi compose.yaml, lalu cek versi yang sedang berjalan:

cd /opt/n8n
sudo docker compose exec n8n n8n --version

2.45.7

Baca catatan rilis versi tujuan di halaman Release notes dokumentasi n8n, terutama bagian breaking changes. Lompatan kecil di versi 2.x (misalnya 2.45 ke 2.47) biasanya aman; lompatan versi utama (1.x ke 2.x) wajib dibaca dulu.

Kalau Anda masih memakai tag latest di compose.yaml, ganti dulu menjadi versi yang jelas lewat variabel N8N_VERSION di .env. Dengan latest, n8n bisa berganti versi diam-diam setiap kali container dibuat ulang, termasuk saat Anda tidak siap.

Langkah 1: backup tiga hal

Ada tiga hal yang harus diselamatkan: database (workflow, kredensial, riwayat eksekusi), volume data n8n, dan file .env (berisi N8N_ENCRYPTION_KEY).

cd /opt/n8n
sudo mkdir -p /root/backup-n8n
t=$(date +%F)
sudo docker compose exec -T postgres pg_dump -U n8n -d n8n | gzip | sudo tee /root/backup-n8n/n8n-db-$t.sql.gz > /dev/null
sudo docker run --rm -v n8n_n8n_data:/data -v /root/backup-n8n:/backup alpine tar czf /backup/n8n-data-$t.tar.gz -C /data .
sudo cp .env /root/backup-n8n/env-$t
sudo ls -lh /root/backup-n8n

Hasil di server uji:

-rw------- 1 root root  204 Nov  5 05:44 env-2026-11-05
-rw-r--r-- 1 root root 265K Nov  5 05:44 n8n-data-2026-11-05.tar.gz
-rw-r--r-- 1 root root 203K Nov  5 05:44 n8n-db-2026-11-05.sql.gz

Ukurannya kecil (database berisi 1 workflow dan 1.001 eksekusi), dan pg_dump aman dijalankan selagi n8n hidup.

Nama volume n8n_n8n_data berasal dari nama folder (n8n) ditambah nama volume di compose.yaml (n8n_data). Cek nama volume di server Anda dengan:

sudo docker volume ls

n8n_caddy_config
n8n_caddy_data
n8n_n8n_data
n8n_postgres_data

Simpan salinan backup, terutama file env-…, di luar VPS (komputer Anda atau penyimpanan lain). Backup yang hanya ada di server yang sama ikut hilang bila server-nya bermasalah.

Langkah 2: ganti versi dan unduh image baru

sudo sed -i "s/^N8N_VERSION=.*/N8N_VERSION=2.47.2/" .env
sudo docker compose pull n8n

Di server uji, pull memakan 71 detik. Selama itu n8n versi lama tetap berjalan normal, karena container belum diganti. Inilah alasan pull dipisah dari up: waktu unduh tidak ikut menjadi waktu mati.

Langkah 3: jalankan versi baru

sudo docker compose up -d n8n

Perintah ini selesai dalam 1 detik, tetapi n8n butuh beberapa detik untuk menyala dan menjalankan migrasi database. Kami memantau https://n8n.domainanda.com/healthz setiap detik dari komputer lain selama proses ini. Hasilnya berurutan:

 5 kali  200   (versi lama, sebelum up -d)
11 kali  502   (n8n sedang menyala, Caddy belum bisa meneruskan)
74 kali  200   (versi baru, sampai pemantauan selesai)

Jadi waktu mati sebenarnya sekitar 11 detik. Webhook yang masuk di rentang itu mendapat 502. Sebagian layanan (payment gateway, WhatsApp gateway) mengulang pengiriman webhook yang gagal, tetapi tidak semua. Karena itu jalankan update di jam sepi.

Langkah 4: pastikan semuanya utuh

sudo docker compose exec n8n n8n --version
sudo docker compose exec n8n n8n list:workflow
sudo docker compose exec postgres psql -U n8n -d n8n -tAc "select count(*) from execution_entity"
sudo docker compose logs n8n | grep -i migration

Hasil di server uji:

2.47.2
ujiWebhook000001|Uji webhook JowHost
1002
n8n-1  | Starting migration RemovePublicAppVisibility1793612194540
n8n-1  | Finished migration RemovePublicAppVisibility1793612194540

Versi sudah 2.47.2, workflow masih ada, riwayat eksekusi tidak hilang, dan log menunjukkan migrasi database selesai. Terakhir, panggil satu webhook untuk memastikan workflow benar-benar berjalan:

curl https://n8n.domainanda.com/webhook/uji

{"pesan":"Halo dari n8n di VPS JowHost","waktu":"2026-11-05T12:49:21.763+07:00"}

Buka juga editor n8n di browser dan jalankan satu atau dua workflow terpenting Anda secara manual, terutama yang memakai kredensial (Google, database, API berbayar).

Kalau versi baru bermasalah: rollback yang benar

Godaan pertama biasanya: kembalikan saja N8N_VERSION ke versi lama lalu up -d. Kami mencobanya:

versi: 2.45.7
healthz 200

n8n 2.45.7 memang menyala lagi. Tetapi ini tidak aman. Database-nya sudah dimigrasi oleh 2.47.2, dan versi lama tidak tahu apa-apa tentang perubahan itu. Hari ini terlihat normal; masalahnya bisa muncul belakangan di fitur yang menyentuh tabel yang berubah. n8n memang punya perintah n8n db:revert untuk membatalkan migrasi, tetapi hanya satu migrasi terakhir per perintah dan tidak kami uji di sini.

Rollback yang pasti adalah memulihkan backup yang dibuat sebelum update, ke volume database yang baru dan kosong. Volume lama dibiarkan dulu sebagai cadangan.

1. Matikan semua container (tanpa -v, supaya volume tidak terhapus):

   cd /opt/n8n
   sudo docker compose down
   

2. Di compose.yaml, ganti nama volume PostgreSQL ke nama baru di dua tempat: di bagian volumes: milik service postgres, dan di daftar volumes: paling bawah. Misalnya postgres17_data menjadi postgres17_pulih.

3. Kembalikan versi n8n di .env ke versi saat backup dibuat:

   sudo sed -i "s/^N8N_VERSION=.*/N8N_VERSION=2.45.7/" .env
   

4. Nyalakan PostgreSQL saja, tunggu sampai siap, lalu pulihkan dump:

   sudo docker compose up -d postgres
   sleep 15
   sudo gunzip -c /root/backup-n8n/n8n-db-2026-11-05.sql.gz | sudo docker compose exec -T postgres psql -q -U n8n -d n8n
   

5. Nyalakan semuanya:

   sudo docker compose up -d
   

Di server uji, pemulihan selesai tanpa error (exit code 0), dan hasilnya kembali persis ke kondisi saat backup:

n8n 2.45.7 | workflow: ujiWebhook000001|Uji webhook JowHost | eksekusi: 1001

Perhatikan jumlah eksekusinya kembali ke 1.001, bukan 1.002. Eksekusi yang terjadi setelah backup dibuat tidak ikut kembali. Inilah alasan backup dibuat tepat sebelum update, bukan sehari sebelumnya.

Volume n8n_data tidak perlu dipulihkan untuk rollback, karena isinya tidak diubah oleh update. Arsipnya dibutuhkan bila Anda memindahkan n8n ke server baru, dengan perintah kebalikan dari backup (tidak kami jalankan di uji ini):

sudo docker run --rm -v n8n_n8n_data:/data -v /root/backup-n8n:/backup alpine tar xzf /backup/n8n-data-2026-11-05.tar.gz -C /data

Pindah dari PostgreSQL 16 ke 17 dengan cara yang sama

n8n 2.45.7 di server uji menulis peringatan ini di log saat menyala, karena database-nya PostgreSQL 16:

Postgres 16 is outside the supported range and receives compatibility support only. Upgrade to Postgres 17 or newer.

PostgreSQL tidak bisa langsung membaca folder data dari versi utama lain, jadi mengganti postgres:16-alpine menjadi postgres:17-alpine saja tidak akan berhasil. Caranya sama persis dengan rollback di atas: down, ganti image ke postgres:17-alpine sekaligus ganti nama volume (misalnya postgres_data menjadi postgres17_data), nyalakan postgres, pulihkan dump, lalu up -d.

Itulah yang kami lakukan di server uji. Pemulihan selesai dengan exit code 0, select version() menunjukkan PostgreSQL 17.11, dan isinya utuh:

n8n 2.45.7 | workflow: ujiWebhook000001|Uji webhook JowHost | eksekusi: 1001

Setelah itu n8n kami update lagi ke 2.47.2. Workflow tetap utuh, webhook berjalan, dan peringatan PostgreSQL 16 tidak muncul lagi.

Volume lama (n8n_postgres_data) tidak terhapus otomatis. Biarkan beberapa hari sampai Anda yakin semuanya beres, baru hapus:

sudo docker volume rm n8n_postgres_data

Langkah 5: bersihkan image lama

Setiap image n8n berukuran hampir 2 GB, dan versi lama tetap tersimpan setelah update. Di server uji:

caddy:2-alpine                   92MB
docker.n8n.io/n8nio/n8n:2.47.2   1.94GB
docker.n8n.io/n8nio/n8n:2.45.7   1.81GB
postgres:17-alpine               424MB
postgres:16-alpine               420MB
alpine:latest                    13MB

Setelah update terbukti lancar beberapa hari, hapus image yang tidak dipakai container mana pun:

sudo docker image prune -a -f

Total reclaimed space: 1.929GB

Pemakaian disk turun dari 6,8 GB menjadi 5,0 GB. Jangan jalankan ini tepat setelah update: kalau ternyata perlu rollback, image versi lama harus diunduh ulang dulu. Pertimbangan ukuran disk untuk n8n kami bahas di Spesifikasi VPS untuk n8n.

Backup otomatis setiap hari

Backup sebelum update itu wajib, tetapi backup harian membuat Anda aman juga dari kesalahan lain (workflow terhapus, kredensial tertimpa). Simpan perintah di Langkah 1 ke sebuah skrip:

sudo tee /root/backup-n8n.sh > /dev/null <<'EOF'
#!/bin/bash
set -euo pipefail
cd /opt/n8n
t=$(date +%F-%H%M)
mkdir -p /root/backup-n8n
docker compose exec -T postgres pg_dump -U n8n -d n8n | gzip > /root/backup-n8n/n8n-db-$t.sql.gz
docker run --rm -v n8n_n8n_data:/data -v /root/backup-n8n:/backup alpine tar czf /backup/n8n-data-$t.tar.gz -C /data .
cp .env /root/backup-n8n/env-$t
find /root/backup-n8n -type f -mtime +14 -delete
EOF
sudo chmod 700 /root/backup-n8n.sh

Lalu jadwalkan lewat sudo crontab -e, misalnya setiap hari pukul 02.30:

30 2 * * * /root/backup-n8n.sh

Perintah di dalam skrip sama dengan yang kami jalankan saat uji; baris find menghapus backup yang lebih tua dari 14 hari. Jalankan skrip sekali secara manual dan periksa isi /root/backup-n8n untuk memastikan semuanya terbentuk.

Kalau tidak berhasil

• 502 Bad Gateway lebih dari semenit setelah update: lihat sudo docker compose logs n8n --tail 50. Biasanya migrasi masih berjalan (database besar) atau n8n gagal menyala karena konfigurasi.
• n8n meminta "Set up owner account" lagi, semua workflow seolah hilang: hampir pasti Anda menjalankan docker compose dari folder lain, sehingga Docker membuat volume baru yang kosong dengan awalan nama folder berbeda. Jalankan docker compose down di folder yang salah, lalu up -d lagi dari folder asli (/opt/n8n). Data lama tidak hilang; hanya tidak terpakai.
• Muncul pesan Mismatching encryption keys: N8N_ENCRYPTION_KEY di .env berbeda dengan yang tersimpan di volume n8n_data. Kembalikan .env dari backup (env-…).
• pull gagal karena disk penuh: bersihkan image yang tidak terpakai dengan docker image prune -a, lalu ulangi.
• Jangan pernah memakai docker compose down -v: opsi -v menghapus semua volume, termasuk database dan data n8n.

Pertanyaan yang sering muncul

Seberapa sering n8n perlu di-update? n8n merilis versi baru sangat sering. Tidak perlu mengikuti semuanya; update sebulan sekali, atau segera bila ada perbaikan keamanan, sudah cukup untuk kebanyakan pemakaian.

Bolehkah memakai update otomatis seperti Watchtower? Kami tidak menyarankannya untuk n8n. Update otomatis berarti migrasi database berjalan tanpa backup sebelumnya dan tanpa ada yang mengecek hasilnya. Lima menit untuk menjalankan langkah di atas jauh lebih murah daripada kehilangan workflow.

Bisa melompati beberapa versi sekaligus? Bisa. Migrasi semua versi di antaranya dijalankan berurutan saat n8n menyala. Lompatan kami dari 2.45.7 ke 2.47.2 melewati beberapa rilis tanpa masalah. Yang perlu dibaca lebih teliti adalah lompatan versi utama (misalnya 1.x ke 2.x).

Saya memakai n8n one-click di Super Cloud, apakah caranya sama? Prinsipnya sama: backup dulu, ganti versi, pull, up -d, lalu cek. Tetapi cara pemasangan one-click bisa berbeda dari contoh /opt/n8n di artikel ini, jadi periksa dulu dengan docker ps, docker compose ls, dan docker volume ls di mana konfigurasi dan volumenya berada. Kalau ragu, pesan Super Cloud per jam sebagai server cadangan, pulihkan backup n8n Anda di sana, lalu coba update di salinan itu sebelum menyentuh yang asli.