How to Self-Host n8n for Free: The Complete Guide (2026)

You're paying $20+/month for n8n Cloud. That's $240/year. Maybe you're on the Pro plan at $50/month — that's $600/year. For an open-source tool that's entirely free to self-host.

Here's the thing: n8n is one of the most powerful workflow automation platforms available, and its entire codebase is open source under a fair-code license. The n8n Cloud service is a convenience layer — they host it, they manage it, you pay monthly. But you don't have to.

With Oracle Cloud's Always Free tier, you can run n8n on a server with 24GB of RAM and 4 OCPUs for exactly $0 per month. Not $0 for 12 months. Not $0 with a credit limit. Zero dollars, permanently.

This guide walks you through the entire process: the cost math, the cloud provider comparison, the step-by-step setup, and the security hardening that turns a free server into a production-ready n8n instance. Whether you follow each command manually or use the n8n Self-Host Autopilot to guide you through it interactively, the result is the same — your own n8n instance, running on your server, at no monthly cost.

n8n Cloud vs Self-Hosted: The Real Comparison

Before you decide to self-host, you need to understand exactly what you're comparing. n8n Cloud is not a different product — it's the same n8n software, hosted on n8n's infrastructure, with usage limits applied based on your pricing tier.

Self-hosting removes those limits entirely. You get the full, unrestricted version of n8n running on hardware you control.

Feature-by-Feature Comparison

The differences are significant. On n8n Cloud Starter, you're capped at 5 active workflows. If you're building automation for a business — even a small one — you'll hit that wall fast. A simple CRM integration, an email automation, a lead enrichment pipeline, a reporting workflow, and a notification system: that's 5 workflows. You're full. Want a sixth? Upgrade to Pro at $50/month.

Self-hosted n8n doesn't have these limits. You can run 50, 100, or 500 active workflows. The only ceiling is your server's hardware — and Oracle's free tier gives you more hardware than most small businesses need.

Where n8n Cloud Genuinely Wins

Let's be honest about the trade-offs:

• Zero maintenance. n8n Cloud handles updates, backups, uptime monitoring, and SSL certificates. You don't think about infrastructure.
• Instant setup. Sign up, pay, start building workflows. No server provisioning, no Docker, no SSH.
• Team features. Built-in collaboration, role management, and audit logs on higher tiers.
• Compliance documentation. SOC 2, GDPR compliance paperwork — useful for enterprise contexts.

If you're a team of 5 people who need managed infrastructure with compliance documentation and zero DevOps overhead, n8n Cloud Pro makes sense. For solopreneurs, freelancers, and small service businesses? Self-hosting is overwhelmingly the better deal.

The Cost Math: 1 Year, 3 Years, 5 Years

Numbers don't lie. Let's look at what n8n costs over time across each option.

Total Cost of Ownership

*Self-hosted costs: $0 server + ~$12/year for a domain name. Total 5-year cost: ~$60 for the domain.

What $240/Year Actually Buys Elsewhere

That $240/year you'd spend on n8n Cloud Starter could instead pay for:

• 4 years of domain registration for your self-hosted instance
• A full year of a premium VPN service
• 20 months of a password manager
• The entire n8n Self-Host Autopilot Pro+ tier and still have $161 left over

Or you could just keep the $240. Every year.

The Hidden Cost: Usage Limits

The cost comparison above doesn't capture the full picture. n8n Cloud Starter caps you at 2,500 executions per month. If you have workflows that trigger frequently — say, a webhook listener that processes form submissions, or a scheduled job that runs every 15 minutes — you'll burn through 2,500 executions before the month is half over.

When you exceed limits, you either upgrade (more money) or your workflows stop running (lost productivity). Self-hosted n8n doesn't have this problem. Your workflows run until your server's resources are exhausted, and with 24GB of RAM, that threshold is very, very high for typical automation workloads.

Break-Even Analysis

Even if you factor in the time cost of initial setup — roughly 45 minutes to an hour — the break-even point is immediate. One month of not paying $20 for n8n Cloud Starter already exceeds the time investment. And the savings compound every single month after that.

For users currently on n8n Cloud Pro at $50/month, the math is even more dramatic. In one year, you save $600. In three years, $1,800. That's real money that could fund other tools, services, or growth investments for your business.

Cloud Provider Comparison for Free n8n Hosting

If you're going to self-host n8n for free, you need a free server. Every major cloud provider offers some form of free tier, but they are not created equal. Here's how the four major options stack up.

Free Tier Comparison Table

Oracle Cloud: The Clear Winner

Oracle Cloud's Always Free tier is in a league of its own. The ARM-based Ampere A1 instances give you up to 24GB of RAM and 4 OCPUs with 200GB of block storage — and it never expires. Oracle introduced this in 2019 and has publicly committed to maintaining it.

For context, 24GB of RAM is more than many paid cloud servers at the $50-100/month tier. It's enough to run n8n, a PostgreSQL database, a reverse proxy, and still have overhead for monitoring tools.

The catch? Oracle Cloud's sign-up process occasionally rejects applicants (especially during high-demand periods), and ARM instances can be temporarily out of capacity in popular regions. The workaround: try a less popular region (e.g., Phoenix instead of Ashburn) and use the "create instance" API with a retry script if the web console shows "out of capacity."

AWS Free Tier: Too Limited

AWS gives you a t2.micro instance with 1GB of RAM for 12 months. That's barely enough to run n8n with a few basic workflows. Once you add PostgreSQL and a reverse proxy, you're pushing the memory limit hard. Workflows with larger data payloads will crash.

Worse, after 12 months, it's no longer free. AWS starts billing you, and if you forget to terminate the instance, you'll get a surprise charge. For permanent free hosting, AWS doesn't work.

Google Cloud Platform: Always Free e2-micro

GCP offers an always-free e2-micro instance (1 vCPU, 1GB RAM, 30GB storage) in select US regions — permanently free, no expiration. This is enough to run n8n with basic workflows. GCP also gives $300 in trial credits for 90 days to try larger instances. The n8n Self-Host Autopilot's Free tier uses GCP's e2-micro — it's the easiest way to get started with self-hosting for $0.

Azure: Same Story as GCP

Microsoft Azure gives $200 in credits for 30 days. Even shorter than GCP. After those credits expire, you're on the meter. Azure does have some Always Free services, but compute instances are not among them at any useful size.

Verdict

For permanently free n8n self-hosting with production-grade resources, Oracle Cloud is the only real option. It's not even close. Twenty-four times the RAM of AWS free tier, with no expiration date.

Oracle Cloud Free Tier: What You Actually Get

Let's get specific about what Oracle's Always Free tier includes, because the details matter.

Always Free Resources

Compute:

• Up to 4 ARM-based Ampere A1 OCPUs (can be split across instances)
• Up to 24GB RAM (can be split across instances)
• For n8n, a single instance with 2 OCPUs and 12GB RAM is more than sufficient
• You can run a second instance with the remaining resources for other projects

Storage:

• 200GB total block volume storage
• 2 block volumes included
• 10GB object storage
• 10GB archive storage

Networking:

• 10TB/month outbound data transfer
• Load balancer (1 instance, 10 Mbps)
• Public IP addresses (up to 2)
• VCN (Virtual Cloud Network)

Databases:

• 2 Autonomous Database instances (20GB each)
• This is a fully managed Oracle database — you probably won't need it for n8n, but it's there

What's NOT Free

Be aware of these potential costs:

• AMD-based instances (VM.Standard.E2.1.Micro) are Always Free, but you only get 1GB RAM — not useful for n8n
• Additional block storage beyond 200GB
• Additional bandwidth beyond 10TB/month (you won't hit this with n8n)
• Windows OS instances (Always Free only covers Oracle Linux, Ubuntu, and CentOS)
• GPU instances (not included in free tier)

The "Always Free" Promise

Oracle distinguishes between "Free Tier" (trial credits that expire) and "Always Free" (resources that never expire). When you sign up, you get both: $300 in trial credits for 30 days AND the Always Free resources.

After 30 days, the trial credits expire, but your Always Free resources continue running. Oracle has maintained this program since 2019 across multiple infrastructure updates. The key rule: don't upgrade your account to "Pay As You Go" unless you want to — Always Free resources are available on both free and paid accounts, but staying on a free account prevents accidental charges.

Credit Card Requirement

Yes, Oracle requires a credit card to sign up. No, you won't be charged. The card is used for identity verification only. Always Free resources are never billed. If you're uncomfortable, use a virtual credit card number from your bank or a service like Privacy.com.

Step-by-Step: Setting Up n8n on Oracle Cloud

This section walks through the high-level process of getting n8n running on Oracle Cloud's free tier. Each step includes the key decisions and commands involved. For a fully interactive, command-by-command guided experience, the n8n Self-Host Autopilot handles this entire process inside Claude Code.

Step 1: Create an Oracle Cloud Account

1. Go to cloud.oracle.com and click "Sign Up"
2. Choose your home region — Ashburn (US East) or Phoenix (US West) are reliable choices. You cannot change your home region after signup.
3. Enter your details and credit card for verification
4. Wait for account activation (usually instant, sometimes up to 24 hours)

Tip: If you're rejected during sign-up, try again with a different email and select a different home region. Oracle occasionally restricts sign-ups in high-demand regions.

Step 2: Create an ARM Compute Instance (Always Free)

1. Navigate to Compute > Instances > Create Instance
2. Set the name (e.g., n8n-server)
3. Under Image and Shape:
   • Image: Canonical Ubuntu 22.04 (or 24.04 if available)
   • Shape: VM.Standard.A1.Flex (this is the ARM Always Free shape)
   • OCPUs: 2 (use 2 of your 4 free OCPUs)
   • Memory: 12 GB (use 12 of your 24 free GB)
4. Under Networking: Use the default VCN or create a new one. Ensure Assign a public IPv4 address is selected.
5. Under SSH keys: Upload your public SSH key or let Oracle generate one (download and save the private key immediately)
6. Click Create

The instance should launch within a few minutes. If you see "Out of capacity," try selecting a different availability domain within the same region, or wait and retry later.

Step 3: Configure Security Lists (Firewall)

Oracle Cloud uses Security Lists to control network traffic. By default, only SSH (port 22) is open. You need to open ports for HTTP and HTTPS:

1. Go to Networking > Virtual Cloud Networks > Your VCN > Subnet > Security List
2. Add Ingress Rules:
   • Port 80 (HTTP) — Source: 0.0.0.0/0, Protocol: TCP
   • Port 443 (HTTPS) — Source: 0.0.0.0/0, Protocol: TCP
3. Save the rules

Step 4: SSH Into Your Server

Once the instance is running and you have the public IP address:

ssh -i ~/.ssh/your-oracle-key ubuntu@YOUR_SERVER_IP

If you used Oracle-generated keys, specify the downloaded private key path instead.

Step 5: Update the System and Install Docker

First, update the package lists and install Docker:

sudo apt update && sudo apt upgrade -y

Install Docker using the official convenience script:

curl -fsSL https://get.docker.com | sudo sh

Add your user to the Docker group so you don't need sudo for every Docker command:

sudo usermod -aG docker $USER

Log out and SSH back in for the group change to take effect:

exit
ssh -i ~/.ssh/your-oracle-key ubuntu@YOUR_SERVER_IP

Verify Docker is working:

docker --version
docker run hello-world

Install Docker Compose (it's included with modern Docker, but verify):

docker compose version

Step 6: Create the Docker Compose Configuration for n8n

Create a directory for your n8n setup:

mkdir -p ~/n8n-docker && cd ~/n8n-docker

Create the docker-compose.yml file. This is covered in detail in the next section, but the core structure is:

version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=your-domain.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://your-domain.com/
      - GENERIC_TIMEZONE=America/New_York
    volumes:
      - n8n_data:/home/node/.n8n

volumes:
  n8n_data:

Start n8n:

docker compose up -d

Verify it's running:

docker compose ps
docker compose logs -f n8n

You should see n8n starting up and listening on port 5678.

Step 7: Set Up a Reverse Proxy (Caddy or NGINX)

n8n runs on port 5678, but you want users (and webhooks) to access it via standard HTTPS on port 443. A reverse proxy handles this.

Option A: Caddy (Recommended — Simplest SSL)

Caddy automatically provisions and renews Let's Encrypt SSL certificates. Add it to your docker-compose.yml:

  caddy:
    image: caddy:2
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

Create a Caddyfile:

your-domain.com {
    reverse_proxy n8n:5678
}

That's it. Caddy handles SSL automatically.

Option B: NGINX + Certbot

If you prefer NGINX, install it and use Certbot for SSL certificates. This gives you more configuration flexibility but requires more setup. The Autopilot supports both options.

Step 8: Point Your Domain

Before SSL certificates will work, your domain must point to your server:

1. In your domain registrar's DNS settings, add an A record:
   • Name: @ (or your subdomain, like n8n)
   • Value: Your Oracle Cloud instance's public IP
   • TTL: 300 (5 minutes)
2. Wait for DNS propagation (usually 5-15 minutes, can take up to 48 hours)
3. Verify: nslookup your-domain.com should return your server's IP

Step 9: Basic Security Hardening

A public-facing server needs security. These are the essentials:

Enable UFW (Uncomplicated Firewall):

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Disable password authentication (SSH keys only):

sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Install fail2ban:

sudo apt install fail2ban -y
sudo systemctl enable fail2ban
sudo systemctl start fail2ban

Enable automatic security updates:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

These four measures handle the vast majority of common server threats. The n8n Self-Host Autopilot configures all of this automatically during setup.

Docker Compose Configuration for n8n: What Each Setting Does

The Docker Compose file is the heart of your self-hosted n8n. Let's break down every important setting.

Complete Production Docker Compose

version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    container_name: n8n
    restart: always
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=your-domain.com
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://your-domain.com/
      - GENERIC_TIMEZONE=America/New_York
      - N8N_ENCRYPTION_KEY=your-random-encryption-key
      - N8N_USER_MANAGEMENT_DISABLED=false
      - N8N_DIAGNOSTICS_ENABLED=false
      - N8N_HIRING_BANNER_ENABLED=false
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=168
    volumes:
      - n8n_data:/home/node/.n8n

  caddy:
    image: caddy:2
    container_name: caddy
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data
      - caddy_config:/config

volumes:
  n8n_data:
  caddy_data:
  caddy_config:

Key Environment Variables Explained

N8N_HOST — Your domain name without the protocol. This tells n8n what hostname to expect, which is critical for webhooks to function correctly.

N8N_PROTOCOL — Set to https if you're using SSL (you should be). This ensures n8n generates correct webhook URLs.

WEBHOOK_URL — The full base URL for webhook endpoints. If this is wrong, every webhook trigger in your workflows will have an incorrect URL. Must include the protocol and trailing slash.

N8N_ENCRYPTION_KEY — This key encrypts credentials stored in n8n's database. Generate it once and never change it, or you'll lose access to all stored credentials. Generate one with:

openssl rand -hex 32

GENERIC_TIMEZONE — Sets the default timezone for scheduled workflows. Use IANA timezone names (e.g., America/New_York, Europe/London).

EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE=168 — Automatically prune execution data older than 168 hours (7 days). Without this, your database grows indefinitely and eventually fills your disk.

N8N_DIAGNOSTICS_ENABLED=false — Disables anonymous telemetry sent to n8n. Optional, but good for privacy.

N8N_HIRING_BANNER_ENABLED=false — Removes the "n8n is hiring" banner from the UI. Cosmetic, but nice.

The restart: always Policy

This is critical. Docker's restart: always policy means:

• If n8n crashes, Docker restarts it automatically
• If the server reboots (e.g., Oracle Cloud maintenance), Docker restarts all containers
• n8n effectively auto-heals from most failure scenarios

Without this policy, a server reboot would leave n8n stopped until you manually SSH in and restart it.

Volumes: Why They Matter

The n8n_data volume persists your n8n data — workflows, credentials, execution history, settings — outside the Docker container. This means:

• Updating n8n (pulling a new image) doesn't erase your data
• You can back up the volume independently
• Container rebuilds preserve all your work

Never skip the volume configuration. Without it, every container restart wipes your data.

Updating n8n

When a new n8n version releases, updating is straightforward:

cd ~/n8n-docker
docker compose pull
docker compose up -d

Two commands. Takes about 30 seconds. Your data persists through the update thanks to the volume mount.

SSL and Domain Setup: Why HTTPS Matters

Running n8n over plain HTTP is a security risk and a functional limitation. Here's why SSL isn't optional.

Why You Need HTTPS

1. Webhooks won't work. Most services (Stripe, GitHub, Slack, etc.) require HTTPS webhook endpoints. Without SSL, your webhook-triggered workflows are dead on arrival.

2. Credentials transmitted in cleartext. When you log into n8n, your password crosses the network. Without SSL, anyone on the network path can read it.

3. Browser warnings. Modern browsers flag HTTP sites as "Not Secure." If you're sharing your n8n URL with team members or clients, this looks unprofessional.

4. OAuth flows break. Many OAuth2 providers (Google, Microsoft) require HTTPS redirect URLs. Without SSL, you can't connect Google Sheets, Gmail, or OneDrive.

Let's Encrypt with Caddy: Zero-Configuration SSL

If you use Caddy as your reverse proxy (recommended), SSL is automatic. When Caddy sees a domain name in its configuration, it:

1. Requests a Let's Encrypt certificate
2. Completes the ACME challenge
3. Installs the certificate
4. Sets up auto-renewal (certificates renew before expiration)

There's nothing to configure. Your Caddyfile has one line with your domain, and Caddy handles everything.

Let's Encrypt with NGINX + Certbot

If you prefer NGINX, install Certbot:

sudo apt install certbot python3-certbot-nginx -y

Request a certificate:

sudo certbot --nginx -d your-domain.com

Follow the prompts. Certbot modifies your NGINX configuration automatically and sets up a cron job for renewal.

Verify auto-renewal works:

sudo certbot renew --dry-run

Certificate Renewal

Let's Encrypt certificates expire every 90 days. Both Caddy and Certbot handle renewal automatically. Caddy checks daily and renews when needed. Certbot's cron job typically runs twice daily.

You should still verify renewal works after initial setup. Set a calendar reminder to check in 80 days — or use monitoring (covered later) to alert you if the certificate expires.

Security Hardening Essentials

A self-hosted server is only as secure as you make it. These measures aren't optional — they're the minimum for running a public-facing service.

1. SSH Key-Only Authentication

Password-based SSH is the number one attack vector for cloud servers. Automated bots constantly try common username/password combinations. Disabling password auth and using SSH keys eliminates this risk entirely.

After uploading your public key during instance creation:

# Verify you can log in with your key
ssh -i ~/.ssh/your-key ubuntu@YOUR_SERVER_IP

# Then disable password authentication
sudo sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Test by opening a new terminal and SSH-ing in again — confirm it still works before closing your existing session.

2. UFW Firewall

UFW (Uncomplicated Firewall) blocks all incoming traffic except the ports you explicitly allow:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Check the status:

sudo ufw status verbose

You should see only three rules: SSH, HTTP, and HTTPS. Everything else is blocked.

Important: Oracle Cloud has its own network-level security lists (configured in Step 3 of the setup). UFW adds a second layer of defense at the OS level. Both are needed.

3. fail2ban

fail2ban monitors log files for repeated failed login attempts and automatically bans the offending IP addresses:

sudo apt install fail2ban -y

The default configuration protects SSH. For additional protection, create a custom configuration:

sudo tee /etc/fail2ban/jail.local << 'EOF'
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600
findtime = 600
EOF

This bans any IP that fails 3 SSH login attempts within 10 minutes, for 1 hour. Restart fail2ban:

sudo systemctl restart fail2ban

Check banned IPs:

sudo fail2ban-client status sshd

4. Automatic Security Updates

Ubuntu can automatically install security patches:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Select "Yes" when prompted. This ensures critical security patches are applied without manual intervention.

5. Non-Root User

Never run n8n or Docker commands as root. The Ubuntu user created during instance provisioning is sufficient. If you need elevated privileges, use sudo for individual commands.

Running services as root means any vulnerability in that service has full system access. Running as a regular user limits the blast radius of potential exploits.

What About a VPN?

Some guides recommend putting n8n behind a VPN (WireGuard, Tailscale). This adds security but creates a problem: webhooks from external services can't reach your n8n instance through a VPN. If you use webhook triggers, your n8n must be publicly accessible on ports 80 and 443.

The security measures above — SSH keys, firewall, fail2ban, and n8n's own authentication — provide adequate protection for a self-hosted automation platform.

Monitoring Your Self-Hosted n8n

Self-hosting means you're responsible for uptime. Here's how to keep an eye on things without making it a full-time job.

Basic Health Checks

Create a simple script that verifies n8n is responding:

#!/bin/bash
# save as ~/check-n8n.sh
if curl -sf https://your-domain.com/healthz > /dev/null 2>&1; then
  echo "n8n is running"
else
  echo "n8n is DOWN" | mail -s "n8n Alert" your@email.com
fi

Schedule it with cron:

crontab -e
# Add this line to check every 5 minutes:
*/5 * * * * /home/ubuntu/check-n8n.sh

Disk Space Monitoring

The most common failure mode for self-hosted n8n is running out of disk space. Execution logs, the database, and Docker images all consume storage over time.

Check disk usage:

df -h

Check what Docker is consuming:

docker system df

Clean up unused Docker resources periodically:

docker system prune -f

Set up a disk space alert:

#!/bin/bash
# save as ~/check-disk.sh
USAGE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$USAGE" -gt 85 ]; then
  echo "Disk usage is at ${USAGE}%" | mail -s "Disk Alert" your@email.com
fi

Memory Monitoring

n8n's memory usage depends on workflow complexity and concurrent executions. Monitor it:

docker stats --no-stream

This shows CPU and memory usage for each container. If n8n consistently uses more than 80% of available memory, consider optimizing your workflows or allocating more resources.

Execution Log Pruning

The EXECUTIONS_DATA_PRUNE=true environment variable handles this, but verify it's working. Without pruning, the n8n database grows indefinitely. A database that fills the disk crashes n8n.

Check database size:

docker exec n8n du -sh /home/node/.n8n

If you're using SQLite (the default), the database file is inside the n8n data directory. For production workloads with many executions, consider switching to PostgreSQL, which handles large datasets more efficiently.

Uptime Monitoring Services

For free external monitoring, consider:

• UptimeRobot (free tier: 50 monitors, 5-minute intervals) — Pings your n8n URL and emails you if it's down
• Healthchecks.io (free tier: 20 checks) — Cron job monitoring with heartbeat checks
• Cronitor (free tier: limited) — Similar to Healthchecks.io

These external monitors catch issues your on-server scripts might miss (like the entire server being unreachable).

The Pro+ tier of the n8n Self-Host Autopilot includes pre-configured monitoring with dashboards and alerting, so you don't have to set this up manually.

Common Mistakes to Avoid

After helping people self-host n8n through GenAI Unplugged, these are the mistakes I see most often.

1. Running Everything as Root

Logging in as root and running Docker commands directly is the path of least resistance — and the path to security disasters. Always use a non-root user with sudo privileges. If your n8n container gets compromised and it's running as root, the attacker has full system access.

2. Skipping Backups

"It's just automation workflows, I can rebuild them." Until you have 50 workflows with complex logic, custom code nodes, and credentials for 20 services. Then your disk fails and everything's gone.

Back up your n8n data volume regularly:

# Create a backup
docker compose stop
tar -czf n8n-backup-$(date +%Y%m%d).tar.gz -C /var/lib/docker/volumes/ n8n-docker_n8n_data
docker compose up -d

Schedule this weekly at minimum. Store backups off-server (Oracle Object Storage is free for up to 10GB, or use any cloud storage service).

3. No SSL Certificate

Running n8n over HTTP might "work" for basic UI access, but it breaks webhooks, exposes credentials, and triggers browser security warnings. There's no valid reason to skip SSL when Caddy makes it free and automatic.

4. Choosing the Wrong Instance Type

On Oracle Cloud, the Always Free ARM instances are VM.Standard.A1.Flex. If you accidentally select an AMD or Intel instance shape, it may not be Always Free and could incur charges. Double-check the shape name before creating the instance.

5. Forgetting the Restart Policy

Without restart: always in your Docker Compose file, a server reboot leaves n8n stopped. You might not notice for hours or days — during which time, all scheduled workflows and webhook listeners are dead.

6. Not Setting WEBHOOK_URL

If the WEBHOOK_URL environment variable isn't set or is incorrect, n8n generates webhook URLs using localhost or the internal container IP. External services can't reach these URLs, so webhook-triggered workflows silently fail.

7. Ignoring Execution Data Pruning

Without EXECUTIONS_DATA_PRUNE=true, n8n stores every execution forever. On a server with 200GB of storage, you might think this isn't a concern. But SQLite databases slow down dramatically as they grow, and a multi-gigabyte database makes n8n sluggish even if you have disk space left.

8. Not Securing the n8n UI

n8n has built-in user management. Enable it. Set a strong password. If you leave n8n's UI open without authentication, anyone who finds your URL can access, modify, and run your workflows — including any that have access to your email, CRM, databases, or other services.

9. Skipping OS Updates

Your server is on the internet. Vulnerabilities in the operating system are discovered regularly. Automatic security updates (unattended-upgrades) handle the critical ones. Skipping this is like leaving your front door unlocked because you live in a "safe neighborhood."

10. Not Testing After Setup

You finish the setup, see n8n's login screen, and declare victory. But you haven't tested:

• Can external webhooks reach your instance?
• Does the SSL certificate auto-renew?
• Does n8n restart after a server reboot?
• Are backups actually being created?

Test every critical function before relying on your self-hosted instance for production workflows.

When n8n Cloud Actually Makes More Sense

Self-hosting isn't for everyone, and this guide wouldn't be honest if it didn't acknowledge that. Here are scenarios where n8n Cloud is the better choice.

Teams That Need Zero DevOps

If you're a team of 3-10 people building automations and nobody wants to be the "server person," n8n Cloud removes the infrastructure burden entirely. Updates, backups, SSL, scaling — all handled. The $50/month Pro plan is a reasonable cost for a team's time savings.

Compliance Requirements

If your workflows process sensitive data in regulated industries (healthcare, finance), you may need SOC 2 compliance, specific data residency guarantees, or audit logging that n8n Cloud provides out of the box. Building this yourself on a self-hosted instance is possible but significantly more work.

Rapid Prototyping

If you need to test n8n for a quick project and don't want to spend 45 minutes on infrastructure, n8n Cloud's free trial lets you start building immediately. You can always migrate to self-hosted later.

High-Availability Requirements

If a workflow being down for 30 minutes would cost your business thousands of dollars, n8n Cloud's managed infrastructure with uptime SLAs provides stronger guarantees than a single Oracle Cloud free-tier instance. You can build high availability on self-hosted infrastructure (load balancers, multiple instances, database replication), but the complexity is substantial.

Users Who Truly Don't Want to Touch a Terminal

Some people have zero interest in SSH, Docker, or server management. That's completely valid. Not everyone needs to be a DevOps engineer. If the phrase "SSH into your server" makes you uncomfortable and you have no desire to learn, n8n Cloud is money well spent for the convenience it provides.

The Hybrid Approach

Some users run self-hosted n8n for their primary workflows (saving money) and keep an n8n Cloud account for specific team collaboration features or as a failover. This hybrid approach captures the cost savings of self-hosting while maintaining the safety net of a managed service.

Migrating from n8n Cloud to Self-Hosted

If you're currently on n8n Cloud and want to switch to self-hosted, the migration process is straightforward.

Export Your Workflows

1. In n8n Cloud, go to Workflows
2. Select the workflows you want to export
3. Click Export — this downloads JSON files

You can export all workflows at once or one by one.

Import Into Self-Hosted

1. In your self-hosted n8n, go to Workflows
2. Click Import from File
3. Select the exported JSON files

Your workflow logic — nodes, connections, configurations — transfers completely.

Re-Enter Credentials

Credentials (API keys, OAuth tokens, passwords) are encrypted and tied to the n8n instance's encryption key. They don't transfer between instances. You'll need to:

1. Go to Credentials in your self-hosted n8n
2. Create new credentials for each service
3. Re-authenticate OAuth connections (Google, Slack, etc.)
4. Update workflows to use the new credentials

This is the most tedious part of migration. For 10-20 credentials, budget 30-60 minutes.

Test Everything

After migration, test every workflow:

• Trigger each workflow manually and verify it completes
• Check webhook URLs — they'll have your new domain
• Verify scheduled workflows fire at the correct times
• Confirm notification and error handling workflows work

Don't disable your n8n Cloud workflows until you've verified everything works on self-hosted. Run both in parallel for a week if possible.

What's Next After Setup

Once your self-hosted n8n is running, you're ready to build. If you're new to n8n, start with our free n8n course that covers everything from basic workflows to advanced AI automations.

If you want to go deeper into self-hosting — with automated backups, monitoring dashboards, multi-cloud support, and production-grade security — the n8n Self-Host Autopilot handles the entire setup interactively through Claude Code. The Free tier covers everything in this guide. The Pro and Pro+ tiers add the features that turn a basic self-hosted setup into a production-ready platform.

Quick Reference: Essential Commands

The Bottom Line

Self-hosting n8n on Oracle Cloud's free tier gives you unlimited workflows, unlimited executions, 24GB of RAM, full root access, and complete data control — for $0/month. The setup takes under an hour. The savings compound every month.

$240/year might not sound like much. But over 5 years, that's $1,200 saved on the Starter plan or $3,000 saved on Pro. For a solopreneur or small business, that money is better spent on tools that actually require paid infrastructure — not on hosting an open-source platform that runs perfectly on free resources.

Stop paying monthly for something you can run for free.