How to Update Self-Hosted n8n (Without Breaking Your Workflows)

If you’ve ever logged into your self-hosted n8n instance and seen that little orange dot next to your version number, you already know the feeling — half “ooh, new features,” half “what if I touch this and break every workflow I’ve spent three weeks building.”

That hesitation is normal. n8n ships updates constantly — the release notes show patch builds going out almost daily and minor versions landing weekly — which is great for getting fixes fast, but it also means “update self-hosted n8n” is one of the most searched problems in every Reddit automation thread and the n8n community forum. People aren’t confused about why to update. They’re nervous about how to do it without losing credentials, encryption keys, or a production webhook mid-flow.

This guide walks through every popular way people actually run n8n in 2026: plain Docker/terminal, Dokploy, Coolify, Portainer, and the older npm/PM2 setup — in that order, because that’s roughly the order of popularity among self-hosters right now. Real commands, real gotchas pulled from actual community threads, no filler. Let’s get straight to “How to update n8n?”

And if by the end of this you’re thinking “this is a lot of babysitting for a $5 VPS” — stick around for the last section, because that’s exactly the problem we built n8n LaunchPad to solve.

Why bother updating at all

A few reasons this isn’t optional busywork:

• Security. n8n patches vulnerabilities in core and in nodes regularly — recent patch notes alone have included fixes for dependency-level security issues (a langsmith CVE fix shipped in a recent point release, for example). Sitting on an old build means sitting on known holes.
• New nodes and integrations. Between January and mid-2026, n8n shipped dozens of new nodes — native Anthropic Claude, Google Gemini, Groq, and more landed as separate releases, not as one big yearly update. If you’re not updating, you’re not getting them.
• Bug fixes that actually affect your workflows. Recent releases alone fixed things like broken pagination in the Supabase node, large file upload failures in Google Cloud Storage, and webhook deletion bugs in Zendesk triggers — small stuff until it’s your workflow silently failing.
• The longer you wait, the worse the jump. n8n’s own docs are blunt about this: update frequently so you’re not forced to leap across several breaking changes at once. Their official guidance is to update at least once a month and to check release notes before doing it.

Before you touch anything: the 5-minute pre-update checklist

Skipping this is how a 5-minute update turns into a 3-hour Saturday. Do these every time, no exceptions:

1. Back up your data volume. Your workflows and credentials live in /home/node/.n8n (SQLite) or in your Postgres database, not in the container itself. Snapshot it before you touch anything:

   tar -czf n8n_data_backup_$(date +%F).tgz -C /var/lib/docker/volumes/n8n_data/_data .

If you’re on Postgres, run a pg_dump instead.

2. Export your workflows as a second safety net.

   docker exec -it n8n n8n export:workflow --all --output=/home/node/.n8n/backup.json

3. Know your N8N_ENCRYPTION_KEY. This single environment variable decrypts every saved credential. Lose it or accidentally regenerate it during a redeploy and every credential becomes unreadable — there’s no recovery. Write it down somewhere safe before you touch your compose file.
4. Skim the release notes for breaking changes, especially if you’re jumping more than one or two minor versions, or crossing a major version boundary (like the 1.x → 2.0 migration). n8n publishes a migration checklist for major jumps — read it if your version number is about to change on the left of the dot.
5. If you’re running anything business-critical, test the update on a staging copy first. Even a throwaway VPS with the same compose file is enough to catch a breaking change before it hits production.

Got all that? Good. Pick your method below.

Method 1: Terminal + Docker Compose (the most common setup)

This is the setup most serious self-hosters end up on — n8n’s own documentation defaults to Docker Compose for production because it isolates your database, reverse proxy, and n8n itself into one manageable stack.

Step 1: Check what version you’re running

docker exec -it n8n n8n --version

Or just check inside the editor: Help → About n8n.

Step 2: Decide — pinned version or latest?

If your docker-compose.yml uses image: docker.n8n.io/n8nio/n8n:latest (or the Docker Hub mirror n8nio/n8n:latest), you’re always pulling whatever’s newest, which is convenient but unpredictable — you won’t know exactly what changed until after it’s running.

If you’ve pinned a version (e.g. docker.n8n.io/n8nio/n8n:1.104.0), you control exactly when and what you upgrade to — open the file, bump the tag to the version you want, save.

For production, pinning is the safer habit. For a personal/testing instance, latest is fine.

Step 3: Pull, stop, restart

Run below commands one by one or chain them by using &&

cd n8n                  # wherever your docker-compose.yml lives
docker compose pull     # downloads the new image(s)
docker compose down     # stops and removes the old containers
docker compose up -d    # starts everything fresh on the new image

Three commands. That’s the entire update. Your n8n_data (or Postgres) volume isn’t touched by down — only the containers are recreated, not the data.

Plain docker run users (no Compose file)

Same idea, just more manual since there’s no compose file tracking your flags:

docker pull docker.n8n.io/n8nio/n8n
docker ps -a                      # find your container ID/name
docker stop n8n
docker rm n8n
docker run -d --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

Heads up: people regularly get stuck “updating” with docker pull and then wondering why the version didn’t change — that’s almost always because they pulled the new image but never actually recreated the running container. Pulling downloads the image; it doesn’t touch what’s already running. You always need the stop → remove → run (or compose down → up) step too.

Method 2: Docker Desktop (GUI, no terminal)

If you’re running n8n locally through Docker Desktop rather than a VPS:

1. Go to the Images tab, find n8nio/n8n, right-click → Pull.
2. Once it’s downloaded, go to Containers, stop your existing n8n container.
3. Start a new container from the freshly pulled image, mounting the same volume you used before.

This is the cleanest path if you genuinely don’t want to touch a terminal, but it’s mostly relevant for local dev/testing — not how anyone runs n8n in production.

Method 3: npm / PM2 (the non-Docker setup)

Some people — especially folks who set up n8n early or on a bare VPS without Docker — run it straight off npm with PM2 keeping it alive. It’s a smaller crowd than Docker users today, but still common enough to cover.

npm update -g n8n
pm2 restart n8n

If you want to jump to a specific version instead of just “latest available”:

npm install [email protected] -g
pm2 restart n8n

Check what’s running:

n8n --version
pm2 logs n8n --lines 50

This method has no isolation from your system Node.js version, which is the main downside — if your server’s Node version drifts out of n8n’s supported range, updates can fail in ways that are annoying to debug. It’s also why most new self-hosted setups in 2026 default to Docker instead.

Method 4: Updating n8n on Dokploy

Dokploy has become a genuinely popular self-hosted PaaS for running n8n because it deploys straight from a Docker Compose template and hides most of the Traefik/SSL/networking pain. If you used Dokploy’s official n8n template, your service is just a Compose stack under the hood — updating it follows the same logic as Method 1, but through the UI.

1. Open your Dokploy dashboard and go to the n8n project/service.
2. Open the Compose tab where your stack’s YAML is editable.
3. Find the image line — it’ll look like:

   image: docker.n8n.io/n8nio/n8n:2.XX.XX

Bump the version number to the one you want (check the n8n release notes first).

4. Save, then click Redeploy.

Dokploy pulls the new image and recreates the container while leaving your n8n_data volume alone, exactly like a manual docker compose pull && up -d. If you’re running Postgres alongside n8n in the same Dokploy template (the “n8n with Postgres” template), only touch the n8n image tag — leave the Postgres service as-is unless you specifically need a database version bump too.

Tip: If you deployed n8n on Dokploy using image: …:latest instead of a pinned tag, just hitting Redeploy with the “force rebuild / re-pull” option enabled will grab whatever’s newest — but you lose the ability to know exactly what version you landed on without checking the editor afterward.

Method 5: Updating n8n on Coolify

Coolify is the other big self-hosted-PaaS name people use for n8n, and it’s arguably the smoothest of the GUI options because of how it handles redeploys.

1. Log into your Coolify dashboard and select your n8n service.
2. Open the Configuration tab.
3. Update the Docker image tag — for example, from :1.104.0 to :1.110.0.
4. Click Deploy (or, in the Advanced section, use Pull Latest Images & Restart if you’re tracking latest instead of a pinned tag).

Coolify performs a rolling restart by default — it starts the new container and waits for it to pass its health check before killing the old one. If your service only has a single replica, you’ll still see a short gap (roughly 30 seconds) while the swap happens. If you’ve configured two replicas, the restart is effectively zero-downtime.

After deploying, confirm the update landed:

1. Open your n8n instance.
2. Check the bottom-left of the editor — the “What’s New” indicator should show 0 versions behind once you’re current.
3. Or check Help → About n8n directly for the version string.

If the version badge still shows you’re behind after a successful-looking deploy, it almost always means the image tag in your Coolify config didn’t actually change (people sometimes redeploy without realizing the field still says latest and Coolify cached the old pulled layer) — double check the tag field, force a fresh pull, and redeploy again.

Method 6: Other popular platforms (Portainer, CapRover, Railway, and friends)

Not everyone is on Docker Compose, Dokploy, or Coolify. Here’s the quick version for the rest of the popular stacks:

The underlying mechanic never changes: new image in, old container out, volume untouched. Whatever dashboard you’re using is just a wrapper around that same Docker primitive.

When updates go wrong: common errors and fixes

Pulled straight from real threads people have hit:

“I pulled the new image but the version number didn’t change.”
Almost always means the container was never recreated — you pulled the image but the old container is still running on the old one. Run the stop/remove/start (or down/up) sequence again, and double-check you’re not accidentally targeting a different container name than the one actually serving traffic.

“Updating broke my credentials — everything shows as invalid.”
This is the N8N_ENCRYPTION_KEY problem. If that variable wasn’t preserved across the redeploy (common when people rebuild a compose file from scratch instead of editing the existing one, or switch hosting platforms without copying env vars over), n8n generates a new key on first boot and every existing credential becomes permanently unreadable. There’s no fix after the fact except re-entering every credential — which is exactly why step 3 of the pre-update checklist matters.

“I’m stuck on an old version and can’t update past it no matter what I try.”
Usually a leftover container or image caching issue — confirm with docker images that you actually have the newer image locally, and that docker ps shows the container running from that image’s ID, not an old one with the same name reused.

A major version jump introduced breaking changes to my workflows.
This is why pinning versions and reading release notes before crossing a major boundary (like the 1.0 or 2.0 migration points) matters. n8n provides official migration checklists and a migration tool for major jumps — use them instead of just bumping the tag blind.

How often should you actually update?

n8n’s own guidance is simple: update at least once a month, more often if you’re chasing a specific fix, and never let your instance drift so far behind that one update has to absorb six months of changes at once. If you’re managing multiple n8n instances — which, if you’re running automation for clients, you probably are — this turns into a recurring chore that’s easy to forget until something breaks or a client asks why their workflow stopped firing.

The part nobody tells you about self-hosting n8n

Here’s the honest version: self-hosting n8n is genuinely the right call if you want full control, no execution limits, and to keep your automation data off someone else’s cloud. But “self-hosted” quietly means you’re now the ops team. Every month, that’s: checking release notes, backing up volumes, pulling images, recreating containers, watching logs for errors, and occasionally untangling an encryption key issue at 11pm because a redeploy lost an environment variable.

That’s the trade nobody mentions when they recommend “just self-host it, it’s free.” The server might be $5/month. Your time isn’t.

This is exactly the gap n8n LaunchPad was built to close. You get a fully managed, pre-deployed n8n instance — same n8n, same nodes, same workflows, zero limits — except we handle the version updates, security patches, and backups in the background. No terminal, no Dokploy dashboard, no 2am encryption key panic. You log in and build automations; we keep the infrastructure current.

It’s priced at $6/mo or $8/mo depending on your tier — cheaper than most people’s VPS + their own time spent babysitting updates, and a fraction of what n8n Cloud charges once you factor in per-execution pricing. If you’ve made it this far down a guide about how to safely update your own server, there’s a good chance you’d rather just not.

Frequently Asked Questions