If you deployed n8n on Dokploy, you probably did it because you wanted the Docker Compose power without babysitting a raw VPS terminal every time something needs a config tweak. Updating fits the same logic — it’s a UI job, not an SSH job. But there’s a catch almost nobody mentions until it bites them: Dokploy doesn’t always re-pull a new image just because you clicked Redeploy. If your compose file is sitting on a version tag that hasn’t changed, or you’re on latest and Dokploy cached the old layer, you can click Redeploy all day and stay on the exact version you started with.
This guide walks through the actual update n8n on dokploy— the part that works — and the two or three places people get stuck, pulled straight from Dokploy’s own GitHub issue tracker instead of guessed at.
Table of Contents
Quick Answer
Log into your Dokploy dashboard, open your n8n service, go to the Compose tab, find the image: line, and change the version tag to whatever’s newest on the n8n GitHub releases page — for example docker.n8n.io/n8nio/n8n:2.32.7. Save, then hit Redeploy. That’s the whole mechanic. Your n8n_data volume (workflows, credentials, execution history) isn’t touched — only the container gets recreated on the new image.
The part that actually needs care is everything around that: backing up first, knowing your encryption key is safe, and confirming the redeploy actually pulled the new image instead of quietly reusing the old one. That’s what the rest of this covers.
Why This Actually Matters Right Now
n8n ships new builds constantly — patch releases go out almost daily, minor versions weekly. Most of that is routine bug fixes you can ignore for a while. Security patches are the exception.
Case in point: on July 22, 2026, n8n confirmed and shipped a fix for a high-severity sandbox-escape flaw (tracked as GHSA-gv7g-jm28-cr3m, CVSS 8.7) that let anyone with workflow edit access — not even admin, just edit — run OS-level commands as the n8n process itself. Affected versions were anything below 2.31.5, and 2.32.0 up to just before 2.32.1. If your Dokploy instance has been sitting untouched for a few weeks, there’s a real chance you’re inside that window. This isn’t a hypothetical “keep software updated” platitude — it’s a specific, dated, confirmed hole that got closed less than two weeks ago as of this writing.
n8n has had a handful of these in 2026 — sandbox escapes and prototype-pollution bugs mostly, several rated 9+ on CVSS. The pattern is consistent: self-hosted instances that don’t update promptly are the ones that stay exposed. n8n Cloud users get this patched for them automatically. Self-hosted — including Dokploy — means it’s on you.
That’s the actual argument for updating monthly at minimum, not “new features are nice.”
Step-by-Step: Updating n8n on Dokploy
Step 1 — Find the latest n8n version
Go to github.com/n8n-io/n8n/releases. The top of that page is always the newest stable tag — as of this writing that’s [email protected], but by the time you’re reading this it’ll almost certainly be higher, and that’s the point: don’t hardcode a version number from any blog post (including this one), always pull the actual current tag from that page.
n8n uses semantic versioning — MAJOR.MINOR.PATCH. A patch bump (2.32.6 → 2.32.7) is safe to take blind. A minor bump is almost always safe too. A major version change (like the 1.x → 2.0 jump that happened in December 2025) is the one place you slow down and actually read the migration notes, because those can require action — the 2.0 release specifically required anyone still on MySQL/MariaDB to migrate to PostgreSQL first.
Step 2 — Open your n8n service in Dokploy
Log into your Dokploy dashboard, go to the project containing n8n, and click into the n8n service.
Step 3 — On the Compose tab and find your image line
Click the General tab where your stack’s YAML lives. Look for a line that looks like this:
version: "3.8"
services:
n8n:
image: docker.n8n.io/n8nio/n8n:2.30.7
restart: always
....more lines....Step 4 — Update the version tag
Change the number after the colon to whatever you copied from the GitHub releases page in Step 1. Nothing else in the file needs to change — same volumes, same environment block, same network settings.
image: docker.n8n.io/n8nio/n8n:2.32.7Step 5 — Save, then hit Redeploy
Save the compose file, then click Redeploy. Dokploy will pull the new image and recreate the n8n container. Your n8n_data volume — and your Postgres database, if you’re using the template with a separate DB service — is untouched by this. Only the n8n container itself gets swapped.
If you’re running Postgres alongside n8n in the same stack, only touch the n8n image tag. Leave the Postgres service line exactly as it is unless you specifically intend to upgrade the database engine too — that’s a separate, more careful operation.
Step 6 — The gotcha: confirm it actually pulled the new image
This is the step most guides skip, and it’s exactly where people get stuck. Dokploy doesn’t force a fresh image pull on every redeploy by default — this is a known, open behavior discussed in their own GitHub issues (see #2655 and #3522). If your tag genuinely changed (like Step 4 above), the pull almost always happens correctly because Docker sees a new tag it doesn’t have locally. But if you’re on :latest and the underlying image was updated without the tag changing, a plain Redeploy can serve the cached layer instead of pulling fresh.
Two fixes if that happens:
- If your Dokploy version has a “force rebuild” / “re-pull” toggle on the deploy action, enable it and redeploy again.
- If not, SSH in and pull manually first, then redeploy: docker pull docker.n8n.io/n8nio/n8n:2.32.7, then hit Redeploy in the dashboard so it recreates the container from the image now sitting locally.
There’s also a documented edge case (Dokploy issue #945) where a compose redeploy doesn’t reflect a config change at all — Dokploy behaves as if nothing changed. The workaround the maintainers themselves confirmed: click Stop, wait for it to fully stop, then click Deploy again rather than Redeploy. That forces a clean recreate instead of an in-place update.
Confirming the Update Worked
Don’t just trust the green checkmark. Verify the version actually changed:
- Open your n8n editor and check the bottom-left corner — it shows how many versions behind you are, or confirms you’re current.
- Or go to Help → About n8n inside the editor for the exact version string.
- Or from the Dokploy terminal/SSH access: docker exec -it <container-name> n8n –version
If the version still shows your old number after a “successful” deploy, go back to the gotcha in Step 6 — that’s what’s happening.
Rolling Back If Something Breaks
This is why Step 1 of the checklist (writing down your current version) matters. To roll back:
- Go back into the Compose tab.
- Change the image tag back to the exact version you noted before you started.
- Redeploy.
- If a database migration ran that’s now causing schema mismatches (rare on a single-version rollback, more relevant if you jumped several versions at once), restore from the backup you took in the checklist.
This is also the strongest argument for updating in small, frequent jumps rather than letting an instance sit for six months and absorbing a dozen version bumps at once. A one-version rollback is trivial. A six-version rollback is not.
Common Dokploy Update Errors (and What They Actually Mean)
| What you’re seeing | What’s actually happening |
|---|---|
| Redeployed, but version number didn’t change | Image wasn’t re-pulled — see Step 6 above. Force a re-pull or use the Stop → Deploy workaround. |
| “Updating broke my credentials — everything shows invalid” | N8N_ENCRYPTION_KEY wasn’t preserved across the redeploy. If the compose file or env block was rebuilt instead of edited in place, n8n generated a new key on boot. No fix except re-entering credentials — this is exactly what the checklist backup step protects against. |
| Config changes not applying at all after Redeploy | Known Dokploy behavior (issue #945) — use Stop, then Deploy, instead of Redeploy. |
| n8n container won’t start after the version bump | Check the deployment logs in Dokploy first — usually a missing env var expected by the new version, or a Postgres version incompatibility if you also touched the database service. Roll back, read the release notes for that specific version’s requirements, then retry. |
| Private registry / GHCR auth errors | Only relevant if you’re pulling a custom-built n8n image rather than the official one. Official images are public — this shouldn’t come up unless you’ve forked and self-published. |
How Often Should You Actually Update?
Once a month, minimum — that’s n8n’s own guidance, and it holds up. More often if a security advisory drops (like the July 22 fix above). The goal is small, low-risk jumps instead of one terrifying leap across six months of accumulated changes.
If you’re managing more than one n8n instance — which, if you’re doing this for clients through an agency, you probably are — this turns into a recurring checklist item that’s easy to let slide until something breaks or a client asks why a workflow stopped firing.
Where This Fits If You’d Rather Not Do This At All
Everything above is maybe 10 minutes of actual work once you know where to click. The honest cost isn’t the 10 minutes — it’s remembering to do it every month, across however many instances you’re running, forever, without missing the one update that happened to be a security patch.
That’s the exact gap n8n LaunchPad exists to close. You get a fully managed, pre-deployed n8n instance — same n8n, same nodes, same workflows, no execution caps — and we handle version updates and security patches in the background. No Dokploy dashboard, no compose file, no wondering whether a redeploy actually pulled the new image. Plans start at $6/mo, which is less than most people’s VPS cost alone, before you even count the time spent babysitting updates.
If you’ve read this far into a guide about safely updating your own Dokploy instance, there’s a decent chance you’d rather just not have to.
Get Started with n8n LaunchPad →
Frequently Asked Questions
Does updating n8n on Dokploy affect my saved workflows or credentials?
No, not if you follow this process. Your workflows, credentials, and execution history live in the n8n_data volume (or your Postgres database), which a redeploy doesn’t touch — only the container itself gets recreated on the new image. The one exception is if your N8N_ENCRYPTION_KEY gets lost or changed during the process, which is why checking it beforehand matters.
Why did I click Redeploy and my n8n version didn’t change?
Almost always because the new image wasn’t actually pulled — either your compose file was still pointing at the same tag, or you’re on :latest and Dokploy served a cached layer instead of pulling fresh. Force a re-pull (or manually docker pull the image via SSH first) and redeploy again.
Should I use :latest or a pinned version tag on Dokploy?
Pinned, for any production instance. :latest is convenient but means you can’t predict exactly what you’re getting until it’s already running. A pinned tag like :2.32.7 means you control exactly when and what you upgrade to, and rolling back is just reverting to a version number you already know worked.
Do I need to update Postgres separately when I update n8n on Dokploy?
n8n runs its own internal database migrations automatically on startup when the app updates — you don’t manually run those. You do still want to keep the Postgres engine itself reasonably current and backed up, but that’s a separate maintenance task from bumping the n8n image tag, and you shouldn’t change both at once unless you have a specific reason to.
What if Redeploy doesn’t work at all — nothing seems to happen?
This matches a known Dokploy behavior where a compose redeploy doesn’t reflect changes. Click Stop, wait for the service to fully stop, then click Deploy rather than Redeploy. That forces a clean container recreation.
Is it safe to automate n8n updates on Dokploy with something like Watchtower?
Technically possible, but risky for anything holding production credentials and live webhooks — an unattended update that hits a breaking change with nobody watching is worse than a scheduled manual one. Most people running anything beyond a personal test instance stick to monthly manual updates, or at most a notify-then-approve setup rather than fully automatic.
How do I know if my n8n version was affected by a recent CVE?
Check the version range listed in n8n’s security advisories or the release notes for the patched version — they specify exactly which versions were affected. If your current version falls in that range, treat the update as urgent rather than routine.
Does n8n LaunchPad also run on Dokploy under the hood?
No — that’s actually the point. With n8n LaunchPad you’re not managing any underlying infrastructure at all, Dokploy or otherwise. You get a pre-deployed n8n instance with updates, patches, and backups handled on our end, so none of the steps in this guide are something you ever have to think about.
