How to Self-Host N8N on a VPS: The Hostinger Setup Guide

Self-hosted vs. N8N Cloud

A Hostinger VPS running the N8N OS template costs $7 to $10 a month with no execution caps, full control over every environment variable, and nothing leaving your server. N8N Cloud starts around €20 a month and caps how many workflow executions you get.

Here's the comparison in plain terms:

• Monthly cost: about $7-10 self-hosted vs €20-50 for N8N Cloud Pro
• Workflow executions: unlimited vs plan-capped
• Environment variables: set in docker-compose.yml and .env vs Settings → Variables in the Cloud dashboard
• Custom domain: any domain you own vs a *.app.n8n.cloud subdomain
• Data location: stays on your server vs hosted by N8N
• Setup time: about 5 minutes with the OS template vs about 2 minutes for account setup

For AI-powered automation, Claude API calls, Supabase reads and writes, webhook receivers for a Facebook page, self-hosting is the right call if you care about data ownership and execution volume. N8N Cloud makes sense if you'd rather skip server management entirely and don't mind paying per execution.

If you'd rather have the system configured and running than manage a server yourself, book a call and we'll take it from there.

Ordering the VPS with the N8N template

Choose your plan

For N8N running AI-powered workflows, KVM 2 is the plan we recommend: 2 vCPU, 8 GB RAM. The extra RAM matters when N8N is processing simultaneous webhook calls alongside Claude API responses and Supabase writes. KVM 1 (1 vCPU, 4 GB RAM) works for light testing, but struggles under real load.

Get the Hostinger KVM 2 VPS goes straight to the right plan.

Select the N8N OS template

This is the step most guides skim past. Do not skip it.

1. Log into hPanel and go to VPS → Manage → your server.
2. Click OS & Panel in the sidebar, then Operating System.
3. In the template search box, type n8n and select Ubuntu 24.04 with N8N. (There's also an "n8n queue mode" variant. Use the standard one unless you're certain you need queue mode.)
4. Set a strong root password. This is your SSH login, so use a password manager.
5. Click Reinstall. Your VPS is ready in about 2 minutes.

Reinstalling wipes the VPS. If your server already has data on it, take a snapshot in hPanel first. Only reinstall on a fresh server, or one you're happy to reset.

Note your server IP

Once provisioning finishes, find the IPv4 address in hPanel under VPS → your server → Server Info. You'll need it for DNS.

First login: your default N8N URL

After the template finishes, N8N runs at a URL based on your server's assigned hostname. Hostinger gives each VPS a default hostname, something like srv857441.hstgr.cloud, visible in hPanel under Server Info.

Your default N8N URL follows this pattern: https://n8n.[your-vps-hostname]. For the example above, that's https://n8n.srv857441.hstgr.cloud.

Open that URL in a browser. N8N prompts you to create an owner account on first access. Set your name, email, and password, skip the optional setup screens, and you're inside the dashboard.

Your N8N instance is live, which puts you ahead of most automation projects that never get past 'it works on my machine.'

Setting up a custom domain

The default Hostinger hostname works fine. A custom domain, something like n8n.youragency.com, is worth the five extra minutes. It looks more professional in webhook URLs you share with clients, it's easier to remember, and it's required if you ever want to run more than one service on the same VPS.

Hostinger's template ships with a reverse proxy already configured. Point a domain at your VPS, update two environment variables, restart N8N, and HTTPS is live automatically. No Certbot, no certificate files to manage.

Add an A record at your domain registrar

In your DNS panel, add an A record with the name n8n, pointing to your VPS IP address, with a TTL of 3600 or Auto.

DNS propagation usually takes 1 to 30 minutes. Check it by running ping n8n.yourdomain.com. Once it returns your VPS IP, move on.

SSH into your VPS

Run ssh root@your-vps-ip.

Edit the docker-compose file

Open /root/docker-compose.yml with nano /root/docker-compose.yml. Find the environment: block under the n8n: service and update or add three lines: N8N_HOST=n8n.yourdomain.com, WEBHOOK_URL=https://n8n.yourdomain.com/, and N8N_PROTOCOL=https. Replace n8n.yourdomain.com with your actual subdomain, then save with Ctrl+O → Enter → Ctrl+X.

Restart N8N

From /root, run docker compose up -d. N8N recreates its container with the new configuration in about 10 seconds. Visit https://n8n.yourdomain.com and HTTPS should be active. The reverse proxy handles SSL automatically once your DNS A record resolves to the VPS. No manual certificate step.

Environment variables and secrets

Every N8N setting is controlled through environment variables in /root/docker-compose.yml, under the environment: block, in VARIABLE_NAME=value format. After any change, run docker compose up -d from /root to apply it.

That one file is the control panel for your N8N instance: timezone, public URL, encryption key, webhook base URL, queue mode flags, and any custom variables your workflows read at runtime.

Storing secrets in a .env file

For sensitive values (API keys, access tokens, service role credentials), put them in /root/.env instead of directly in docker-compose.yml. Docker Compose reads this file automatically from the same directory. Reference each value in docker-compose.yml using the ${VARIABLE_NAME} syntax instead of typing the secret in plain text.

Do not commit .env to git. If you version-control your docker-compose.yml, add .env to .gitignore before the first commit. A leaked Supabase service role key or a leaked access token causes real damage before you notice it.

Reading env vars inside N8N workflows

Any variable set in the environment: block is available inside N8N workflow nodes through the $env accessor. For example: {{ $env.ANTHROPIC_API_KEY }}. Use that expression in any node field: URL parameters, headers, request bodies. No credentials hardcoded into the workflow JSON. Values inject from the server's environment at runtime, which matters once you're deploying the same workflow across more than one instance: the JSON stays identical, the credentials stay in .env.

One note for N8N Cloud users: Cloud uses $vars instead of $env. Variables are set under Settings → Variables and referenced as {{ $vars.VARIABLE_NAME }}.

Keeping N8N updated

N8N ships updates often: new node types, bug fixes, performance improvements. Updating on the Hostinger template takes three commands, run from /root:

1. docker compose pull fetches the latest N8N image.
2. docker compose down stops and removes the current container.
3. docker compose up -d starts a new container on the updated image, in the background.

Your workflows, credentials, and execution history live in a Docker volume, not inside the container. They survive the update untouched.

Before a major version update (N8N 1.x to 2.x, say), check the N8N changelog for migration notes. Most updates apply cleanly. When in doubt, take a VPS snapshot in hPanel first. It takes 30 seconds and gives you a one-click rollback if anything breaks.

Queue mode (when you need it)

Standard N8N executes workflows synchronously, one at a time. For most use cases, including a single social media page handling routine comment volume, that's enough.

Queue mode is built for high-volume scenarios: dozens of simultaneous webhook calls, a page receiving hundreds of interactions an hour, or workflows that need distributed processing across multiple workers. It uses Redis as a message queue, with workers picking up jobs asynchronously to improve throughput and fault tolerance.

To use it, select Ubuntu 24.04 with N8N (queue mode) at the OS installation step. To scale workers, run docker compose up -d --scale n8n-worker=5. Each worker consumes additional RAM. On a KVM 2 VPS, 3 to 5 workers is a reasonable ceiling.

Start with the standard template. Queue mode adds operational complexity: Redis, worker management, separate logs per worker. That isn't worth carrying until you're actually hitting throughput limits. You can migrate later by reinstalling the OS template after backing up your workflows.

Once your N8N instance is running, the next step is generating an API key so a workflow can deploy into it automatically. That's covered in the N8N API key guide. If you're also wiring in Systeme.io for CRM contact creation, the Systeme.io tag ID guide covers what you'll need from that side of the stack.

The N8N documentation on environment variables is the authoritative reference for every configuration option available. Worth bookmarking, since you'll want it eventually.