How to Host n8n on Hostinger (2026): Plan Choice, Setup, Backups

To run n8n on Hostinger, take a KVM VPS plan, apply the "Ubuntu 24.04 with n8n" template so n8n arrives preinstalled in Docker, open https://n8n.[your-vps-hostname] and create the owner account. KVM 2 is the plan to pick for production and KVM 1 is enough to learn on; after that, the work is a custom domain, a tighter firewall and the nightly n8n backup that Hostinger's weekly server backup does not replace.

Checked on 11 October 2026 against Hostinger's self-hosted n8n and VPS pages, its support articles on the n8n template, changing the domain, updating n8n, VPS backups and the VPS dashboard, its n8n VPS requirements guide, and n8n's backup, Docker Compose, reverse proxy and sizing docs. We did not run these steps on a Hostinger server for this article: every command comes from Hostinger's or n8n's documentation and was checked against the page. The Hostinger links are plain links, not affiliate links.

Hostinger is a common choice for n8n because the template removes the Docker and HTTPS setup, and its plans list a lot of memory for the price. The trade is that "one click" ends at a running editor. What you do in the next hour decides whether the instance survives a bad update or a full disk. If you are still choosing between a server and n8n Cloud, start with the n8n hub, which links our Cloud vs self-hosted guide; this page assumes you have picked Hostinger.

What you will have at the end

Self-host n8n on Hostinger: what the product is

Hostinger's own wording is that you "self-host n8n and only pay for your VPS". There is no Hostinger edition of n8n: the template installs the free Community Edition, which has no execution cap, inside Docker on Ubuntu 24.04. Three template variants are listed: n8n, n8n with queue mode, and n8n with a library of pre-made workflows. Every plan includes a weekly automatic backup, manual snapshots, a firewall you manage from the dashboard and a Docker Manager for Compose projects.

Two boundaries are worth knowing before you buy. Hostinger's support covers "the VPS environment itself, including installation and ensuring the n8n application is running", and it says it does not troubleshoot workflows, configuration or custom code. And the license is n8n's, not Hostinger's: SSO, sharing and Git version control still need a paid n8n license, as our list of n8n self-hosted limitations explains. Hostinger's help center also describes a separate Managed n8n product, deployed from the dashboard with updates handled for you, which it says is "currently rolling out by region". We could not find a public price for it, so this guide stays with the VPS.

Which Hostinger n8n VPS plan fits your workload?

KVM 2 for anything a business depends on, KVM 1 to learn. This is a reading of published specifications, not a benchmark of ours.

Prices are from Hostinger's VPS page: the first figure is the introductory monthly rate on a plan paid upfront, the second is the stated renewal rate, billed for two years. Budget on the renewal number. Our self-hosted n8n pricing breakdown compares it with other providers and with n8n Cloud.

The sizing logic comes from three published sources. n8n's own sizing notes say it "isn't CPU intensive" and that "memory requirements supersede CPU requirements", so compare plans by memory first. n8n's Docker Compose guide asks for at least 4 GB of RAM and 2 vCPUs once the Assistant sandbox is running, which KVM 1 misses by one core. And Hostinger's requirements guide recommends 2 to 4 vCPU cores and 4 to 8 GB of RAM for production use. KVM 2 clears all three. Pick KVM 4 if you choose the queue mode template, which starts three workers by default.

Prerequisites

n8n Hostinger setup: the steps

Step 1: apply the n8n template

A plan bought through Hostinger's self-hosted n8n page comes with the template. On a VPS you already own, apply it from the dashboard, following Hostinger's tutorial:

1. In the Hostinger dashboard, open VPS and select Manage next to the server.
2. Open OS & Panel, then Operating System.
3. Search for n8n, select the template and choose Change OS.
4. Tick the box confirming that all files will be deleted, then set a root password.

Expected result: a progress bar while the template installs, then a Manage App button on the VPS overview page.

Step 2: open n8n and claim the owner account

Go to https://n8n.[your-vps-hostname], where the hostname is the srvXXXXX.hstgr.cloud name on the overview page, or select Manage App. n8n asks you to create the owner account. Do it straight away: until someone completes that screen, the instance belongs to whoever gets there first. Then open Settings, Personal and select Enable 2FA.

Expected result: the n8n editor over HTTPS, an owner login only you hold, and recovery codes saved in your password manager.

Step 3: point your own domain at it

Webhook URLs contain the hostname, so switch to your own domain before you register webhooks with other services. Create an A record for n8n.example.com pointing at the VPS IP address, then make the edits from Hostinger's domain article:

# /docker/n8n/.env
TRAEFIK_HOST=n8n.example.com

# /docker/n8n/docker-compose.yml : change 1, the webhook URL
# Before
- WEBHOOK_URL=https://${COMPOSE_PROJECT_NAME}.${TRAEFIK_HOST}/
# After
- WEBHOOK_URL=https://${TRAEFIK_HOST}/

# Change 2, the Traefik router rule
# Before
- traefik.http.routers.${COMPOSE_PROJECT_NAME}.rule=Host(`${COMPOSE_PROJECT_NAME}.${TRAEFIK_HOST}`)
# After
- traefik.http.routers.${COMPOSE_PROJECT_NAME}.rule=Host(`${TRAEFIK_HOST}`)

cd /docker/n8n
docker compose down
docker compose up -d

Expected result: n8n loads at your domain once DNS has propagated, and the webhook URLs shown in the editor use it.

One note on that file. n8n's docs say WEBHOOK_URL is deprecated from version 2.35.0 in favour of N8N_WEBHOOK_URL, and that n8n logs a warning when the old name is used. Keep the line as Hostinger's article shows it until you have checked your version in the n8n dashboard, then rename it on a day you can test a webhook afterwards.

Step 4: lock the server down

• Firewall. In the VPS dashboard, Security holds the firewall settings. Create a rule set that accepts SSH, port 80 and port 443 and nothing else, then activate it. Add the SSH rule first. If you lock yourself out, Settings has a reset firewall option, and the browser web console still works.
• SSH keys. Add your public key under Settings, SSH keys and stop using the root password for logins.
• n8n settings. If nothing of yours calls the n8n API, n8n recommends disabling it. Set the timezone while you are in the file.
• Skip the basic auth advice. Hostinger's self-hosting tutorial still lists N8N_BASIC_AUTH variables. n8n's user management docs say basic auth was removed in n8n 1.0; the owner account and two-factor authentication are the login now.

# /docker/n8n/docker-compose.yml : add under the n8n service's environment block
- N8N_PUBLIC_API_DISABLED=true     # only if nothing of yours calls the n8n API
- GENERIC_TIMEZONE=Europe/Berlin   # your timezone, so schedules fire when you expect
- TZ=Europe/Berlin

Save, then run docker compose up -d from /docker/n8n; Hostinger's template article confirms that is all a variable change needs. For Code node isolation, n8n says to run task runners in external mode in production. Check whether your compose file has a runner service, and if it does not, our n8n Docker Compose setup guide shows the sidecar.

Step 5: add the nightly n8n backup

This is the step most Hostinger walkthroughs leave out, because the plan already says "free weekly backups". Read what that backup is before you rely on it.

n8n's backup guide says a complete backup is the .n8n folder, which holds the encryption key and, on SQLite, the database, and that n8n should be stopped while the folder is copied. Its sizing notes recommend "nightly backups by attaching another container". This script does exactly that:

#!/usr/bin/env bash
# /root/n8n-backup.sh : nightly n8n backup for the Hostinger template
set -euo pipefail
cd /docker/n8n
mkdir -p /root/n8n-backups
STAMP=$(date +%F)

# Start n8n again even if a step below fails
trap 'docker compose start n8n' EXIT

# 1. Stop n8n so the database file is not copied mid-write
docker compose stop n8n

# 2. Archive the n8n data folder: database, encryption key and settings
docker run --rm --volumes-from "$(docker compose ps -aq n8n)" \
  -v /root/n8n-backups:/backup alpine \
  tar czf "/backup/n8n-data-$STAMP.tar.gz" -C /home/node/.n8n .

# 3. Keep the compose file and .env with it
tar czf "/root/n8n-backups/n8n-config-$STAMP.tar.gz" docker-compose.yml .env
chmod 600 /root/n8n-backups/*

# 4. Keep 14 days on the server
find /root/n8n-backups -type f -mtime +14 -delete

chmod +x /root/n8n-backup.sh
crontab -e
# add this line: run at 03:15 every night
15 3 * * * /root/n8n-backup.sh >> /root/n8n-backup.log 2>&1

# from your own computer, pull the archives off the server
mkdir -p n8n-backups
scp "root@YOUR_VPS_IP:/root/n8n-backups/*" ./n8n-backups/

A caveat, stated plainly: Hostinger does not publish the template's compose file, so we could not check the script against it. It assumes the service is called n8n, as Hostinger's articles describe. Run docker compose config --services first. If the list includes a Postgres service, as the queue mode template is likely to, the workflows live there and you need a pg_dump of that database as well; the script in our Docker Compose guide shows the line. Then test a restore on a spare server before you trust any of it.

Expected result: two dated archives in /root/n8n-backups each morning, and a copy of them somewhere that is not this VPS.

Step 6: update without surprises

Hostinger documents two update routes: Docker Manager (find the n8n project, open the three-dot menu, choose Update) or SSH. Either way, back up first. A Hostinger snapshot makes a good extra checkpoint here, since it only has to last the hour.

/root/n8n-backup.sh
cd /docker/n8n
docker compose pull
docker compose down
docker compose up -d

n8n recommends updating at least monthly, and security fixes are a reason not to stretch that: its batch of advisories on 30 September 2026 included a SQL injection in the Microsoft SQL node (GHSA-5qpp-pqww-h7fp), fixed in 2.42.1 and 2.41.4. Before n8n 3.0, open Settings, Migration Report; our n8n 3.0 upgrade guide lists what it removes. Check the image: line in the compose file too. If it has no version tag, every pull takes the newest release, so pin it to the version you have tested.

Troubleshooting

• The n8n address does not load. From /docker/n8n, run docker compose ps and docker compose logs n8n. Hostinger's support covers getting the application running.
• Certificate error after changing the domain. The A record is wrong or has not propagated yet. Hostinger's article says to wait for DNS before testing.
• Webhook URLs still show the old hostname. The webhook line in the compose file was not changed, or the stack was not restarted.
• Locked out after a firewall change. Use the reset firewall option in Settings, or the web console from the overview page.
• Forgotten owner password. Hostinger has a separate article on resetting the n8n user password, linked from its template guide.
• Workflows crash on large files. n8n keeps binary data in memory by default. Switch it to filesystem mode, or move up a plan from the dashboard.

Set an error workflow as soon as the first real automation is live; our n8n error handling guide has one you can import. And if what you are hosting is turning into a product rather than a set of internal automations, the AI SaaS Builder program covers the next stage. It has no n8n lessons; it teaches building the app itself on Supabase and the Claude API, deploying it and adding Stripe billing.

n8n on Hostinger: FAQ