How to Update n8n Without Losing Workflows or Credentials

To update n8n without losing workflows, back up the database and the encryption key first, read the release notes for every version between yours and the target, then change a pinned version number and restart; n8n applies any database migrations on startup. Your workflows and credentials live in the database, not in the container or the npm package, so an update is safe as long as the data persists and the encryption key stays the same. The rest is having a tested way back if the new version misbehaves.

Where your n8n data actually lives

• The database (SQLite file or PostgreSQL): workflows, credentials (encrypted), users, tags and execution history.

• The n8n data folder (/home/node/.n8n in the Docker image, ~/.n8n for npm installs): the config file holding the encryption key if you never set one, the SQLite database if you use it, binary files in filesystem mode, and installed community nodes.

• Your environment file: database settings, N8N_ENCRYPTION_KEY, webhook URL and other options.

Most "the update deleted my workflows" stories come down to one of two things: the container was recreated without a persistent volume, or the instance started with a different encryption key and could no longer read its credentials.

Why n8n updates sometimes break things

• Breaking changes. Releases occasionally change node behaviour, remove deprecated options, rename environment variables or change defaults. Major versions ship with a migration guide that lists them.

• Node versions. n8n typically keeps existing workflows on the node version they were built with, while new nodes use the latest one, so two similar-looking nodes can behave differently.

• Database migrations. Schema changes run automatically at startup. They are usually one-way, and on a large execution table they can take a while.

• Runtime requirements. npm installs depend on a supported Node.js version, which moves forward over time.

• Community nodes. Third-party nodes may lag behind a new n8n release.

Pre-update checklist

1. Record the version you run now.

2. Read the release notes for every version between yours and the target, looking for breaking changes. Check the release notes for your version rather than relying on memory or blog posts, this one included.

3. Dump the database.

4. Save the encryption key somewhere outside the server, such as a password manager.

5. Export workflows and credentials with the CLI as a second, portable copy.

6. Archive the n8n data folder or Docker volume.

7. Pick a quiet window, and note which workflows are time-critical so you can check them first afterwards.

# 0. note the version you are running now
docker compose exec n8n n8n --version

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

# 2. portable exports (credentials stay encrypted with your key)
docker compose exec -u node n8n n8n export:workflow --all --output=/home/node/.n8n/backups/workflows.json
docker compose exec -u node n8n n8n export:credentials --all --output=/home/node/.n8n/backups/credentials.json
docker compose cp n8n:/home/node/.n8n/backups ./n8n-backups-$(date +%F)

# 3. the encryption key: from the environment, or from the config file if it was generated
docker compose exec n8n printenv N8N_ENCRYPTION_KEY
docker compose exec n8n cat /home/node/.n8n/config

The export of credentials remains encrypted and can only be imported into an instance with the same key. There is a --decrypted option, but a plain-text credentials file is a serious secret; avoid it unless you have a real need. To archive the Docker volume as well:

docker volume ls        # find the real name, e.g. myproject_n8n_data
docker run --rm -v myproject_n8n_data:/data:ro -v "$PWD":/backup alpine \
  tar czf /backup/n8n-data-$(date +%F).tgz -C /data .

For a deeper look at PostgreSQL dumps, retention and restore testing, see our guide to PostgreSQL tuning, backups and security on a VPS, and keep at least one copy off the server as described in our 3-2-1 VPS backup strategy.

Updating a Docker installation

Never run production on the latest tag. Pin an exact version in your .env file so an unrelated restart cannot update you by surprise, and so rolling back is a one-line change.

# in .env: change N8N_VERSION=old.version to the new, tested version
docker compose pull
docker compose up -d
docker compose logs -f n8n     # wait for migrations to finish

Do not stop the container while migrations are running; an interrupted migration is the hardest failure to recover from. In queue mode the main instance and every worker must run the same version, so update them together. A safe order is to stop the workers, let the main instance migrate, then start workers on the new version:

docker compose stop n8n-worker
docker compose pull
docker compose up -d n8n
docker compose logs -f n8n          # editor reachable, migrations done
docker compose up -d n8n-worker

If you run queue mode, our n8n queue mode guide shows the full Compose layout these commands assume.

Updating an npm installation

n8n --version
node --version                 # compare with the Node.js version the release requires
npm install -g [email protected]       # an exact version, not just "latest"
sudo systemctl restart n8n     # or: pm2 restart n8n

Check the Node.js requirement in the release notes before you install. If it has moved, upgrade Node.js first, then n8n.

Your rollback plan

Because migrations change the schema, rolling back means returning both the software and the database to their previous state. Changing the image tag back alone is not enough.

docker compose stop n8n n8n-worker
# in .env: set N8N_VERSION back to the previous version
docker compose exec -T postgres pg_restore -U n8n -d n8n --clean --if-exists < n8n-db-2026-10-14.dump
docker compose up -d

n8n also has an n8n db:revert command, but it reverts only the most recent migration; restoring the dump is the more reliable path. Anything that ran after the dump was taken is lost on restore, so decide quickly whether to roll back.

Restoring from CLI exports

If the database itself is lost or corrupted and the dump fails, the JSON exports are your fallback. Start a fresh n8n with PostgreSQL and the same encryption key, then import credentials before workflows so the references between them resolve:

# on a fresh instance started with the SAME N8N_ENCRYPTION_KEY
n8n import:credentials --input=credentials.json
n8n import:workflow --input=workflows.json

Exports do not contain execution history, and users, sharing and project settings may need to be set up again depending on your version. Review which workflows are active after the import before you point webhooks and schedules back at the instance. This path is slower than restoring a dump, which is why the dump comes first in the checklist.

Test on staging first

For instances the business depends on, rehearse the update on a second server. Restore the production dump there with the same encryption key, but deactivate every workflow before the editor starts, so staging does not send emails, charge cards or poll APIs twice. CLI commands change between releases, so confirm with n8n --help on your version:

# on staging, after restoring the dump with the same N8N_ENCRYPTION_KEY
docker compose run --rm n8n update:workflow --all --active=false

Give staging its own WEBHOOK_URL and domain, run the update, open your most important workflows and execute them manually against test data. If a sizing question comes up while you test, our n8n system requirements guide covers what each workload needs.

After-update checks

• The editor opens and shows the expected version.

• Open a few credentials: if they load, the encryption key is correct.

• Active workflows are still active, and schedules fire at the expected time.

• Production webhooks respond; send a test request to one.

• Run your most critical workflow and inspect each node's output.

• Watch the logs and the failed executions list for the next day.

• Community nodes load without errors.

Frequently asked questions

Will updating n8n delete my workflows?

No, as long as the database and data folder persist across the update. Workflows are stored in the database, not in the application.

Can I skip several versions in one update?

Usually yes, since migrations run in sequence on startup. Read the release notes for every version you skip, because each one's breaking changes still apply.

Do I need CLI exports if I have a database backup?

The database dump is your main restore path. JSON exports are a portable second copy that is easy to inspect, keep in Git or import into a fresh instance.

How often should I update n8n?

A regular rhythm, for example monthly, keeps each jump small. Apply security fixes sooner.

Updating n8n on IM HOST

IM HOST n8n Hosting runs your instance on a dedicated NVMe KVM server with PostgreSQL, full root and free daily backups, so the tools above work exactly as written. A daily backup can be up to a day old, so take a fresh dump right before every update.