How to update self-hosted n8n without losing your workflows

By the serverserv team · 8 min read · Updated 28 October 2026

Updating n8n with Docker Compose takes about ten minutes. Losing workflows during an update almost always comes down to one of two things: no backup of the database, or no copy of the encryption key that protects your saved credentials. This guide covers the backup, the update itself, how to check it worked, and how to roll back, including the extra steps for moving from n8n 1.x to 2.x.

Before you start

This guide assumes n8n runs with Docker Compose, using PostgreSQL as its database, which is the most common production setup. Commands use a project folder called ~/n8n and containers named n8n and n8n-postgres; adjust the names to match yours. You can check them with docker ps and docker volume ls.

Note your current version first, so you know what to roll back to:

cd ~/n8n
docker compose exec n8n n8n --version

Step 1: Back up the database, volume and encryption key

You need three things: the database, the n8n data folder, and the encryption key. Without the key, a restored database is useless for credentials, because n8n cannot decrypt them.

Database dump (PostgreSQL, custom format):

mkdir -p ~/n8n-backups
docker exec n8n-postgres pg_dump -U n8n -d n8n --format=custom \
  > ~/n8n-backups/n8n-db-$(date +%Y%m%d-%H%M).dump

The n8n data volume, copied through a throwaway container:

docker run --rm -v n8n_n8n_data:/source:ro -v ~/n8n-backups:/backup \
  alpine tar czf /backup/n8n-data-$(date +%Y%m%d-%H%M).tar.gz -C /source .

Your config files and encryption key:

cp ~/n8n/.env ~/n8n-backups/env-$(date +%Y%m%d).bak
cp ~/n8n/docker-compose.yml ~/n8n-backups/compose-$(date +%Y%m%d).yml.bak
grep N8N_ENCRYPTION_KEY ~/n8n/.env

If the key is not in .env, n8n generated it itself and stored it in /home/node/.n8n/config inside the container. Save the key in a password manager as well as on the server. Then copy the backup folder off the server, for example to your computer or object storage.

Step 2: Read the release notes

Spend two minutes on the n8n release notes for every version between yours and the new one. Look for database migrations, removed or renamed nodes, changed environment variables and new PostgreSQL version requirements. Minor updates within the same major version are usually smooth; major versions are where breaking changes live.

Step 3: Pin the new version and update

Pin an exact version in docker-compose.yml rather than using latest. That way you always know what is running, and rolling back is a one-line change.

services:
  n8n:
    image: n8nio/n8n:2.x.y   # the version you are updating to

Then pull the image and restart:

cd ~/n8n
docker compose pull
docker compose down
docker compose up -d

The first start after an update can take a minute or two while n8n runs database migrations. Do not stop it during that time.

Step 4: Check that the update worked

docker compose exec n8n n8n --version
docker compose logs --tail 50 n8n

The logs should show migrations finishing and the editor becoming available. Then open n8n in your browser and check that:

• your workflows are all there and still active,
• a credential-based node (for example Gmail or Slack) still connects, which proves the encryption key is right,
• one important workflow runs end to end, and webhooks still respond.

How to roll back a bad update

If something breaks, go back to the old version and, if migrations ran, the old database.

cd ~/n8n
docker compose down
# set image back to your previous version in docker-compose.yml
docker compose up -d n8n-postgres
docker cp ~/n8n-backups/n8n-db-YYYYMMDD-HHMM.dump n8n-postgres:/tmp/n8n.dump
docker exec n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists /tmp/n8n.dump
docker compose up -d

Restoring the database matters: an older n8n version may not start, or may behave oddly, on a database that a newer version has already migrated. This is why the backup in step 1 is not optional.

Updating from n8n 1.x to 2.x

n8n 2.0 brought breaking changes, so a jump from 1.x needs a little more care.

• MySQL and MariaDB are no longer supported. Move to PostgreSQL first.
• Task runners are on by default, and Code nodes can no longer read environment variables unless you allow it.
• Some nodes, such as Execute Command and Local File Trigger, are disabled by default.
• The old Start node is gone, and saving and publishing a workflow are now separate actions.

The safe order is: update to the latest 1.x release, open Settings > Migration Report (available from 1.121.0) and fix what it lists, take a fresh backup, then switch the image to a 2.x version and update as above.

How often should you update n8n?

Once a month is a sensible rhythm for most teams, plus straight away when a security fix is released. Waiting many months makes each update bigger and riskier. Automate the backup with a daily cron job, so an update is never the first time you take one:

0 3 * * * /home/you/n8n/backup-n8n.sh >> /home/you/n8n-backups/backup.log 2>&1

If you would rather not do any of this, serverserv n8n hosting comes with n8n installed and set up on your own server, with no cap on executions, and we build your first workflow for free. On a managed VPS, our team handles operating system updates, hardening and monitoring, and can help with n8n updates by support ticket. See also how to self-host n8n and how to secure an n8n server.

Questions

Sources

• n8n docs: Docker installation and updating
• n8n release notes
• Virtua Cloud: back up and update n8n in production (Docker Compose and PostgreSQL)
• n8n docs: environment variables, including the encryption key

Prices from other companies are as published at the time of writing and can change.