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

N8N Cloud charges €20–50 per month with execution caps. A Hostinger VPS running the N8N OS template costs $7–10 per month with no caps, no data leaving your server, and full control over every environment variable your workflows read at runtime.

The setup has a reputation for being complicated. It isn't — as long as you use Hostinger's pre-built OS template, which installs Docker, Docker Compose, and a fully configured N8N instance in one operation. What this guide covers is everything that happens after those 2 minutes: pointing a custom domain, setting environment variables properly, storing secrets, and keeping N8N updated without losing your workflows.

Self-hosted vs. N8N Cloud

Here is the comparison in plain numbers:

Feature	Self-hosted (Hostinger KVM 2)	N8N Cloud Pro
Monthly cost	~$7–10/mo	€20–50/mo
Workflow executions	Unlimited	Plan-capped
Environment variables	docker-compose.yml + .env	Settings → Variables ($vars)
Custom domain	Any domain you own	*.app.n8n.cloud subdomain
Data stays on your server	Yes	No — hosted by N8N
Setup time	~5 min with OS template	~2 min account setup

For AI-powered automation workflows — Claude API calls, Supabase reads and writes, Facebook webhook receivers — self-hosted is the right call if you care about data ownership and execution volume. N8N Cloud is the right call if you want to skip server management entirely and don't mind the cost per execution.

Not the right decision for you to make right now? Fair. If you'd rather have the system configured and running than manage a server, the intake form is where that conversation starts.

Ordering the VPS with the N8N template

Choose your plan

For N8N running AI-powered workflows, the KVM 2 plan is the recommended minimum: 2 vCPU and 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 will struggle under real load.

Get the Hostinger KVM 2 VPS — this link goes directly 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 navigate to VPS → Manage → your server.
2. Click OS & Panel in the left sidebar, then Operating System.
3. In the template search box, type n8n and select Ubuntu 24.04 with N8N. (There is 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 — use a password manager.
5. Click Reinstall. Your VPS will be ready in approximately 2 minutes.

Reinstalling wipes the VPS. If your server already has data, 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 completes, find the IPv4 address in hPanel under VPS → your server → Server Info. You'll need this for DNS.

First login: your default N8N URL

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

Your default N8N URL:

https://n8n.[your-vps-hostname]
# Example: 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 any optional setup screens, and you're inside your N8N dashboard.

Your N8N instance is live, which is more than most automation projects manage between "it works on my machine" and production.

Setting up a custom domain

The default Hostinger hostname works. 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 at midnight, and it's required if you ever want to run multiple services on the same VPS.

Hostinger's template ships with a reverse proxy pre-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.

Step 1 — Add an A record at your domain registrar

In your DNS management panel (wherever your domain is registered), add:

Type	Name / Host	Value / Points to	TTL
A	n8n	your VPS IP address	3600 or Auto

DNS propagation typically takes 1–30 minutes. Check it by running ping n8n.yourdomain.com — when it returns your VPS IP, proceed.

Step 2 — SSH into your VPS

ssh root@your-vps-ip

Step 3 — Edit /root/docker-compose.yml

nano /root/docker-compose.yml

Find the environment: block under the n8n: service. Update or add these three lines:

N8N_HOST=n8n.yourdomain.com
WEBHOOK_URL=https://n8n.yourdomain.com/
N8N_PROTOCOL=https

Replace n8n.yourdomain.com with your actual subdomain. Save: Ctrl+O → Enter → Ctrl+X.

Step 4 — Restart N8N

cd /root
docker compose up -d

N8N recreates its container with the new configuration in about 10 seconds. Visit https://n8n.yourdomain.com — HTTPS is active. SSL is handled automatically by the reverse proxy 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. Format: VARIABLE_NAME=value. After any change, run docker compose up -d from /root to apply it.

That single 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.

# /root/.env
FACEBOOK_PAGE_ACCESS_TOKEN=EAAxxxxxxxxxxxxxxxx
ANTHROPIC_API_KEY=sk-ant-api03-xxxxxxxx
SUPABASE_URL=https://xxxxxxxxxxx.supabase.co
SUPABASE_SERVICE_ROLE_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
SYSTEME_IO_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxx

Reference them in docker-compose.yml using the ${VARIABLE_NAME} syntax:

services:
  n8n:
    environment:
      N8N_HOST=n8n.yourdomain.com
      WEBHOOK_URL=https://n8n.yourdomain.com/
      FACEBOOK_PAGE_ACCESS_TOKEN=${FACEBOOK_PAGE_ACCESS_TOKEN}
      ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      SUPABASE_URL=${SUPABASE_URL}
      SUPABASE_SERVICE_ROLE_KEY=${SUPABASE_SERVICE_ROLE_KEY}
      SYSTEME_IO_API_KEY=${SYSTEME_IO_API_KEY}

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

Reading env vars inside N8N workflows

Any variable set in the environment: block is accessible inside N8N workflow nodes using the $env accessor:

{{ $env.FACEBOOK_PAGE_ACCESS_TOKEN }}
{{ $env.ANTHROPIC_API_KEY }}
{{ $env.SUPABASE_URL }}

Use this expression in any N8N node field — URL parameters, headers, request bodies. No credentials hardcoded into the workflow JSON. The values inject from your server's environment at runtime. This matters when you deploy the same workflow across multiple instances — the JSON stays identical, the credentials stay in .env.

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 releases updates frequently — new node types, bug fixes, performance improvements. Updating on the Hostinger template is three commands:

cd /root
docker compose pull
docker compose down
docker compose up -d

What each command does:

• docker compose pull — fetches the latest N8N Docker image.
• docker compose down — stops and removes the current running container.
• docker compose up -d — starts a new container using the updated image, in the background.

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

Before major version updates (e.g. N8N 1.x to 2.x), check the N8N changelog for migration notes. Most updates are safe to apply directly. When in doubt, take a VPS snapshot in hPanel first — 30 seconds, 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 an AI social agent handling a single Facebook page, this is adequate.

Queue mode is designed for high-volume scenarios: dozens of simultaneous webhook calls, pages receiving hundreds of interactions per hour, or workflows that need distributed processing across multiple workers. It uses Redis as a message queue — workers pick up jobs asynchronously, improving throughput and fault tolerance.

To use queue mode, select Ubuntu 24.04 with N8N (queue mode) at the OS installation step. To scale workers:

cd /root
docker compose up -d --scale n8n-worker=5

Each worker consumes additional RAM. On a KVM 2 VPS, 3–5 workers is a reasonable ceiling.

Start with the standard template. Queue mode adds operational complexity — Redis, worker management, separate logs per worker — that is not worth the overhead unless 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 your API key so the AIIP Setup Studio can deploy your workflow 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 exactly what you'll need from that side of the stack.

The N8N official documentation on environment variables is the authoritative reference for every configuration option available — bookmarked here because you will want it eventually.