How to update n8n on Docker without losing data

Short answer: back up, pull the new image with docker compose pull, and recreate the container with docker compose up -d. n8n runs the database migrations by itself on startup. The whole process takes a minute or two.

n8n releases a new version almost every week, and several fix security issues. Before you decide whether to update right now, check the minimum safe n8n version today, the latest stable version and the n8n release notes.

1Check the current version

In the folder with your compose.yaml:

docker compose exec n8n n8n --version

2Back up first

Updates change the database schema. If something goes wrong, the safe way back is restoring the backup.

• With SQLite (default): copy the n8n data volume, which holds the database and the encryption key.
• With PostgreSQL: make a dump with pg_dump.

The commands are in the n8n backup guide.

3Pick the right tag

In production, use n8nio/n8n:stable or pin a version (n8nio/n8n:2.43.6, for example). The latest tag can point to a beta release. To pin a version without editing the file every time, use a variable:

  n8n:
    image: n8nio/n8n:${N8N_VERSION:-stable}

With that, N8N_VERSION=2.43.6 docker compose up -d starts a specific version, and without the variable you get stable.

4Update

docker compose pull n8n
docker compose up -d

pull downloads the new image (about 270 MB compressed, 1.1 GB once extracted) and up -d recreates only the container that changed. On startup, the log shows the migrations:

docker compose logs n8n --since 2m

Migrations in progress, please do NOT stop the process.
Starting migration ...
Finished migration ...

Do not interrupt the container during migrations. Afterwards, check the version and test an important webhook or workflow:

docker compose exec n8n n8n --version

Published workflows stay active after the update; you don’t need to publish them again.

5Clean up old images

Each old version keeps taking about 1 GB of disk. Once you have confirmed everything works:

docker image prune

How to roll back to the previous version

Switching the tag back to the old version sometimes works between close versions, but it is not guaranteed: the old version does not know the migrations the new one applied. The safe route is to stop n8n, restore the backup from step 2 and start with the old tag. That is why the backup comes first.

Configuration warnings in the log

Recent versions list in the log variables whose default is about to change, such as N8N_RUNNERS_MODE or N8N_RUNNERS_TASK_TIMEOUT. They don’t stop n8n from starting, but read the list: if you rely on the current behavior, set the variable explicitly in compose.yaml before a future version changes the default.

If you installed n8n by following the Docker Compose guide, these steps apply exactly as written.

Frequently asked questions

How do I update n8n on Docker Compose?

Back up, run docker compose pull n8n and then docker compose up -d. n8n applies the database migrations by itself on startup.

Will I lose my workflows when I update n8n?

No: workflows, credentials and executions live in the database and the volume, which are kept. Published workflows stay active. Still, back up first, because migrations change the database.

Can I roll back to the previous n8n version?

It sometimes works between close versions, but it is not guaranteed, because the old version does not know the new migrations. The safe route is restoring the backup you took before updating.

Should I use the latest or the stable tag?

Use stable or a pinned version. The latest tag can point to a beta release.