How to Update n8n on Hostinger VPS (2026)

n8n releases updates frequently, with security fixes and new nodes you do not want to miss. Updating on a Hostinger VPS takes a few minutes — but you should always back up first, because a failed update without a backup can cost you every workflow you built.

Before you update: back up everything

Do these three things before touching the update. They take five minutes and are the difference between a scare and a disaster.

1. Export your workflows. In the n8n interface, open each important workflow → menu → Download, or export everything at once from the command line inside your n8n setup:

   n8n export:workflow --all --output=/backup/workflows.json
   n8n export:credentials --all --output=/backup/credentials.json

   Store the files somewhere off the server (your computer, cloud storage).
2. Back up the database. If you run n8n with Docker, your data lives in a volume. Back it up:

   docker run --rm -v n8n_data:/data -v /backup:/backup alpine tar czf /backup/n8n-data.tar.gz -C /data .

   Replace n8n_data with your actual volume name (docker volume ls shows them). If you installed n8n with npm, copy ~/.n8n/database.sqlite to a safe place instead.
3. Note your current version and settings. Write down the n8n version shown in the UI, plus any environment variables or custom nodes you configured. You will need them if you ever roll back.

Method A — Update with Docker Compose (recommended)

If you installed n8n with a docker-compose.yml file, this is the cleanest path:

cd /path/to/your/n8n
docker compose pull
docker compose up -d

That pulls the new image and recreates the container with your existing volumes and settings. Check it came back healthy:

docker compose ps
docker compose logs --tail 50 n8n

Then open n8n in your browser and confirm the new version number in the UI.

Method B — Update a plain Docker container

If you started n8n with docker run, stop and recreate the container with the same options:

docker stop n8n
docker rm n8n
docker pull docker.n8n.io/n8nio/n8n
docker run -d --name n8n --restart unless-stopped \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  -e N8N_HOST="n8n.yourdomain.com" \
  -e WEBHOOK_URL="https://n8n.yourdomain.com/" \
  docker.n8n.io/n8nio/n8n

Use your original environment variables and volume names, not these examples verbatim — they must match how you first set n8n up.

Method C — Update an npm installation

npm update -g n8n

Then restart whatever keeps n8n running — for example pm2 restart n8n, or systemctl restart n8n if you made a systemd service. Verify the version with n8n –version.

After the update: verify

1. Open the n8n UI and check the version number matches what you expected.
2. Manually execute your two or three most important workflows and confirm they complete.
3. Check scheduled workflows fired at their next run time.
4. Glance at the logs for errors in the first hour.

If something breaks: roll back

Because you backed up, recovery is straightforward. With Docker, pin the previous version explicitly:

docker compose down
# edit docker-compose.yml: image: docker.n8n.io/n8nio/n8n:OLD-VERSION
docker compose up -d

If data was corrupted, stop n8n, restore your volume backup or the sqlite file, then start it again. With npm, reinstall the old version with npm install -g n8n@OLD-VERSION.

Major version jumps (for example 1.x to 2.x) deserve extra care: read the n8n release notes and migration guide first, because breaking changes to nodes and expressions are announced there.

Choosing a release channel: latest vs pinned versions

By default, docker compose pull grabs the latest tag — whatever n8n published most recently. That is convenient but means an update can surprise you with a major version. More cautious operators pin a version in docker-compose.yml:

image: docker.n8n.io/n8nio/n8n:1.110.0

With a pinned tag, updates become deliberate: you change the number, read the release notes for that version, then pull and up -d. n8n also publishes a next tag with pre-release builds — never use it on a production instance. A practical middle ground: pin the minor version and let patches flow, or simply update monthly after skimming the changelog. Either way, the backup steps above stay mandatory.

Automating updates (carefully)

Tools like Watchtower or Ouroboros can auto-update Docker containers when new images appear. For n8n, fully automatic updates are risky — an unattended major-version jump can break workflows while you sleep. If you want automation, a safer pattern is a scheduled job that only notifies you:

# weekly cron: check for a new n8n image, email yourself
0 8 * * 1 docker pull docker.n8n.io/n8nio/n8n:latest | grep -q "Downloaded newer image" && echo "n8n update available" | mail -s "n8n update" [email protected]

Then you run the real update by hand, with your backup fresh and time to verify. Automation should remove toil, not remove your judgment from a step that can break production.

Document your own update runbook

After your first successful update, write down the exact commands you ran — your compose path, volume names, and verification steps — in a short runbook note. The next update then takes ten calm minutes instead of thirty nervous ones, and anyone else on the team can do it. Include the rollback commands too: a runbook that only covers the happy path is half a runbook. Store it where you will actually find it, not in a chat thread that scrolls away.

Frequently asked questions

How often should I update n8n?

Monthly is a sensible rhythm for most self-hosted setups. Update sooner if a release fixes a security issue or adds a node you need. Avoid updating right before a critical deadline — schedule it when you have time to verify.

Will updating n8n break my workflows?

Patch and minor updates rarely do. Major versions can change node behavior, which is why the backup and the release-notes check matter. Test your key workflows after every update regardless.

Docker or npm — which install method is better for updates?

Docker. Updates are one pull command, rollbacks are one version tag, and the environment is identical every time. npm installs are fine but depend more on your server’s Node version staying compatible.

What should I do if n8n will not start after an update?

Read the container logs first (docker logs n8n) — the error message usually names the cause, often a breaking change or a bad environment variable. If you cannot fix it quickly, roll back to the previous version using your backup, then research the issue calmly.