What n8n Actually Is

n8n (pronounced “nodemation”) is a workflow automation platform. You build automations visually by connecting nodes on a canvas — a trigger starts the workflow, data flows through processing nodes, and actions happen at the end. No code required for most things, but you can drop into JavaScript when you need to.

Think of it this way: if you have ever built a pipeline in your head (“when Uptime Kuma detects a failure, restart the container, then send me a Telegram message”), n8n lets you actually build that pipeline and have it run automatically.

It has over 400 built-in integrations — Telegram, email, RSS, HTTP, databases, Ollama, Docker, and hundreds more. But the real power is webhooks. Any service that can send an HTTP request can trigger an n8n workflow, which means anything in your homelab can be connected to anything else.

Why self-hosted matters here: Cloud automation platforms like Zapier and Make charge per execution. Run 1,000 tasks a month and you are paying £20-50 monthly. Self-hosted n8n? Unlimited executions, forever, for free. On a Pi that costs 3p a day in electricity.

Installation on Your Pi 5

n8n runs beautifully in Docker. If you have followed the series from the beginning, you already have Docker and Docker Compose ready to go.

Create a directory for n8n:

mkdir -p ~/services/n8n
cd ~/services/n8n

Create your docker-compose.yml:

version: '3.8'

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=0.0.0.0
      - N8N_PORT=5678
      - N8N_PROTOCOL=http
      - WEBHOOK_URL=http://YOUR_PI_IP:5678/
      - N8N_BASIC_AUTH_ACTIVE=true
      - N8N_BASIC_AUTH_USER=${N8N_USER}
      - N8N_BASIC_AUTH_PASSWORD=${N8N_PASSWORD}
      - GENERIC_TIMEZONE=Europe/London
      - TZ=Europe/London
      - N8N_METRICS=true
    volumes:
      - n8n_data:/home/node/.n8n
    networks:
      - n8n-network

networks:
  n8n-network:
    driver: bridge

volumes:
  n8n_data:

Create a .env file with your credentials:

N8N_USER=admin
N8N_PASSWORD=your-secure-password-here

Start it up:

docker compose up -d

Give it 30 seconds (n8n is not the fastest to initialise on ARM), then open http://your-pi-ip:5678 in your browser. You will be prompted to create an owner account on first launch.

The Visual Workflow Editor

When you first open n8n, you are looking at the workflow canvas. It is a blank space where you drag, drop, and connect nodes. If you have ever used Visio or draw.io, the concept is the same — except these boxes actually do things.

Every workflow starts with a trigger. Something that says “start running now.” That could be:

• Schedule Trigger — run every hour, daily at 9am, every Monday
• Webhook — run when an HTTP request hits a specific URL
• Email Trigger — run when an email arrives
• Manual — run when you click the button (for testing)

After the trigger, you chain action nodes. Each one does something with the data: transform it, send it somewhere, make a decision, call an API. Data flows left to right through the chain.

Let us build your first workflow to get the feel of it.

Your First Workflow: Daily System Report

1. Click Add Workflow in the top right
2. Click the + button to add your first node
3. Search for Schedule Trigger and add it
4. Configure it to run daily at 08:00
5. Click + on the trigger’s output to add the next node
6. Search for Execute Command — this runs a shell command
7. Enter: docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" | head -20
8. Add another node: Send Email (or Telegram, which I find far easier for homelab alerts)
9. Configure it to send the output to yourself

Click Execute Workflow to test it. You should see data flow through each node, and an email or message arrive with your container status.

That is the core loop: trigger, process, act. Everything else builds on this.

Real Workflow 1: Self-Healing Infrastructure

This is the workflow that made me take n8n seriously. Instead of getting a “service down” alert and manually SSHing in to restart things, the automation handles it.

The Flow: Uptime Kuma → Restart Container → Verify → Alert

Uptime Kuma (from the monitoring guide earlier in this series) can send webhooks when a service goes down. We catch that webhook in n8n, attempt a restart, check if it worked, and notify you either way.

Step 1: Set up the webhook trigger in n8n

Add a Webhook node. Set the method to POST and note the webhook URL it generates (something like http://your-pi:5678/webhook/uptime-restart). You will need this for Uptime Kuma.

Step 2: Parse the alert

Add a Set node to extract the container name from the webhook payload. Uptime Kuma sends JSON with the monitor name and status. Map the monitor name to your actual Docker container name:

// In a Set node, extract what we need
Container Name: {{ $json.monitor.name.toLowerCase().replace(/ /g, '-') }}
Status: {{ $json.heartbeat.status }}
Message: {{ $json.msg }}

Step 3: Add a condition

Add an IF node. Only proceed if the status indicates “down” (status = 0 in Uptime Kuma). You do not want to restart containers when the “up” notification fires.

Step 4: Restart the container

On the “true” branch, add an Execute Command node:

docker restart {{ $json.containerName }}

Step 5: Wait and verify

Add a Wait node (30 seconds), then another Execute Command:

docker inspect --format='{{.State.Running}}' {{ $json.containerName }}

Step 6: Notify

Add another IF node checking if the container is now running. On success, send a Telegram message: “Container X was down, auto-restarted, now healthy.” On failure: “Container X is down, auto-restart failed, manual intervention required.”

Step 7: Configure Uptime Kuma

In Uptime Kuma, go to your monitor’s notification settings and add a webhook notification pointing to your n8n webhook URL.

This entire flow takes about 15 minutes to build. Once it is running, your Pi fixes itself at 3am while you sleep. That is not a homelab trick — that is exactly how enterprise auto-remediation works.

Real Workflow 2: AI-Powered News Digest

This workflow pulls RSS feeds, sends the articles through Ollama for summarisation, and delivers a daily digest to your inbox or Telegram. It combines three things from this series: n8n (automation), Ollama (local AI), and self-hosted infrastructure (no data leaves your network).

The Flow: Schedule → RSS Feeds → Filter → Ollama → Digest → Deliver

Step 1: Schedule trigger

Daily at 07:00. You want your digest ready before you start your day.

Step 2: RSS Feed nodes

Add multiple RSS Read nodes, one per feed. Point them at whatever you follow — tech news, security advisories, industry blogs. Set each one to fetch the last 24 hours of articles.

Feed URLs (examples):
- https://feeds.arstechnica.com/arstechnica/index
- https://www.theregister.com/headlines.atom
- https://feeds.feedburner.com/TheHackersNews

Step 3: Merge and deduplicate

Add a Merge node to combine all feeds into a single list. Then use a Remove Duplicates node keyed on the article URL.

Step 4: Limit the batch

Add a Limit node. Ollama on a Pi 5 is not fast — summarising 50 articles will take a very long time. Limit to 10-15 articles maximum. You can increase this later if you find performance acceptable.

Step 5: Summarise with Ollama

n8n has a native Ollama node. Configure it to point at your Ollama instance (http://your-pi:11434 or wherever it is running) and use a prompt like:

Summarise this article in 2-3 sentences. Focus on why it matters
for IT infrastructure professionals. Be concise and factual.

Title: {{ $json.title }}
Content: {{ $json.contentSnippet || $json.content }}

Step 6: Aggregate into a single message

Use an Aggregate node to bundle all summaries into one payload, then a Code node to format them into a readable digest:

const items = $input.all();
let digest = `📰 Daily Tech Digest - ${new Date().toLocaleDateString('en-GB')}\n\n`;

items.forEach((item, i) => {
  digest += `${i + 1}. ${item.json.title}\n`;
  digest += `${item.json.summary}\n`;
  digest += `${item.json.link}\n\n`;
});

digest += `---\n${items.length} articles processed via Ollama`;

return [{ json: { digest } }];

Step 7: Deliver via Telegram

Add a Telegram node and send the digest to yourself. You now have a private, AI-summarised news briefing that runs entirely on your own hardware.

I run a more complex version of this on my own infrastructure. It pulls from about 20 sources, filters by relevance, and produces a security-focused intelligence briefing. The pattern is identical — the only difference is more feeds and a more detailed prompt.

Real Workflow 3: Automated Backups With Validation

Backups that you never verify are not backups. They are hopes. This workflow runs your backup, checks that it actually produced output, validates the file size is reasonable, and alerts you to the result.

The Flow: Schedule → Run Backup → Validate → Alert

Step 1: Schedule trigger

Daily at 02:00. Backups should run when the Pi is least busy.

Step 2: Execute the backup

An Execute Command node that runs your backup script. For example, backing up Docker volumes:

#!/bin/bash
BACKUP_DIR="/backups/$(date +%Y-%m-%d)"
mkdir -p "$BACKUP_DIR"

# Stop containers, backup volumes, restart
for service in gitea n8n uptime-kuma; do
  docker stop "$service" 2>/dev/null
  docker run --rm -v "${service}_data:/data" -v "$BACKUP_DIR:/backup" \
    alpine tar czf "/backup/${service}.tar.gz" /data
  docker start "$service"
done

# Output results for n8n to process
ls -la "$BACKUP_DIR"

Step 3: Validate the backup

Another Execute Command to check files exist and are not suspiciously small:

BACKUP_DIR="/backups/$(date +%Y-%m-%d)"
FAILED=""

for file in gitea.tar.gz n8n.tar.gz uptime-kuma.tar.gz; do
  filepath="$BACKUP_DIR/$file"
  if [ ! -f "$filepath" ]; then
    FAILED="$FAILED $file:MISSING"
  elif [ $(stat -f%z "$filepath" 2>/dev/null || stat -c%s "$filepath") -lt 1024 ]; then
    FAILED="$FAILED $file:TOO_SMALL"
  fi
done

if [ -z "$FAILED" ]; then
  echo "OK"
else
  echo "FAILED:$FAILED"
fi

Step 4: Branch on result

An IF node. If the output starts with “OK,” send a green Telegram message. If it contains “FAILED,” send a red alert with details of what went wrong.

Step 5: Cleanup old backups

Add a final Execute Command that removes backups older than 7 days:

find /backups -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +

When this workflow fires, you wake up to a Telegram message saying either “Backups completed successfully, 3 archives, 127MB total” or “Backup FAILED: n8n.tar.gz missing.” You know the state of your backups every single day without thinking about it.

Webhooks and Trigger Architecture

Webhooks are the most powerful trigger type in n8n, and understanding them is genuinely valuable for any integration role.

A webhook is simply an HTTP endpoint that n8n creates and listens on. When something sends a POST request to that URL, the workflow fires. The data in the request body becomes available to subsequent nodes.

Common Webhook Patterns

• Uptime Kuma → n8n: Monitor goes down, sends JSON payload with monitor details
• Gitea → n8n: Code pushed to repository, triggers deployment pipeline
• Grafana → n8n: Alert fires, sends alert details for processing
• Home Assistant → n8n: Automation triggers, sends event data
• Any application → n8n: Custom webhook for anything with HTTP capability

Webhook Security

By default, n8n webhook URLs are unprotected. Anyone who knows the URL can trigger your workflow. For a homelab on a private network, this is usually acceptable. If your n8n instance is exposed to the internet (through a reverse proxy), add authentication:

# In the Webhook node settings:
Authentication: Header Auth
Header Name: X-Webhook-Secret
Header Value: your-secret-token-here

Then configure the sending service to include that header. This is basic but effective — it prevents random internet traffic from triggering your workflows.

Beyond Webhooks: Other Trigger Types

Schedule triggers run on a cron-like schedule. Daily reports, weekly cleanup, hourly checks.

Polling triggers check an external source periodically. RSS feeds, email inboxes, API endpoints. n8n handles the polling interval and deduplication.

Event triggers for specific integrations. The Telegram trigger listens for messages to a bot. The email trigger watches an inbox. These are essentially managed webhooks that n8n sets up for you.

Connecting to External APIs

Not everything has a native n8n node. For services without built-in integration, the HTTP Request node is your universal connector.

Any API that accepts HTTP requests works. You configure the method (GET, POST, PUT, DELETE), the URL, headers, authentication, and body. The response becomes available to the next node.

Example: Querying Your Pi-hole Stats

HTTP Request node:
  Method: GET
  URL: http://your-pihole-ip/admin/api.php?summaryRaw
  Authentication: None (Pi-hole API on local network)

Response includes:
  - dns_queries_today
  - ads_blocked_today
  - ads_percentage_today
  - domains_being_blocked

Chain this with a schedule trigger and a Telegram node, and you have a daily Pi-hole stats report. Simple, but it demonstrates the pattern: trigger → API call → process response → deliver.

Authentication Patterns

n8n supports credential storage for API keys, OAuth tokens, and basic auth. Store credentials once, reference them in multiple workflows. Never hardcode tokens in your workflow JSON — n8n encrypts stored credentials, but workflow exports include everything else in plaintext.

This is the same principle you will encounter in enterprise platforms. ServiceNow, Azure Logic Apps, AWS Step Functions — they all have credential vaults. Learning the habit of separating secrets from logic starts here.

Error Handling That Actually Works

Workflows fail. APIs timeout. Containers crash. The question is not whether your automation will fail — it is whether it fails gracefully or silently.

The Error Workflow Pattern

n8n has a built-in error workflow feature. Create a separate workflow that receives error data and does something with it (send a Telegram message, log to a file, create an incident). Then set every workflow to use this error handler.

Error Workflow Setup:
1. Create workflow: "Error Handler"
2. Trigger: Error Trigger node
3. Action: Telegram node with error details
4. Template: "⚠️ Workflow '{{ $json.workflow.name }}' failed
   Error: {{ $json.execution.error.message }}
   Time: {{ $json.execution.startedAt }}"
5. In every other workflow: Settings → Error Workflow → select "Error Handler"

Now every workflow failure produces a notification. No more silent failures where an automation broke three weeks ago and you only noticed when the thing it was supposed to do had not happened.

Retry Logic

For HTTP requests to external APIs, configure retries in the node settings. An API timeout does not always mean failure — sometimes the service was just slow. Setting 2-3 retries with exponential backoff handles most transient failures.

For critical workflows, add explicit retry logic with an IF node: if the first attempt fails, wait 60 seconds, try again. If the second attempt fails, escalate to an alert instead of retrying forever.

Gotchas, Pain Points, and Honest Advice

Memory Is the Bottleneck

n8n running on Node.js on a Pi 5 is not a lightweight combination. Expect 300-500MB at idle, spiking higher during complex workflows. If you are running n8n alongside Ollama, Pi-hole, Uptime Kuma, and Nginx Proxy Manager, you will need to watch your memory carefully.

Run docker stats regularly. If you start seeing OOM kills, either reduce the number of concurrent services or add swap space (which is slow on a Pi but better than crashing).

Workflow Complexity Creep

It is extremely tempting to build one massive workflow that does everything. Resist this. A 50-node workflow is nearly impossible to debug when something breaks in the middle. Break complex automations into smaller workflows that trigger each other via webhooks. Each workflow should do one thing well.

The Docker Socket Security Trade-off

Mounting the Docker socket gives n8n full control over Docker. It can stop, start, and delete any container. On a single-user homelab, this is practical and useful. In any shared or production environment, it is a significant security risk. Be aware of what you are granting access to.

Time Zone Confusion

Set GENERIC_TIMEZONE and TZ in your environment variables. If you do not, scheduled workflows will fire at UTC times, not local times. I spent an embarrassingly long time wondering why my “8am daily report” was arriving at 8am UTC (which is not 8am in the UK for half the year).

Webhook URLs Change

If you recreate the n8n container or move to a different host, webhook URLs may change. Any external service pointing at the old URL will silently fail. After any migration, check every webhook configuration in your external services. Write them down somewhere (like your Gitea repository, which we will cover in the next guide).

Backup Your Workflows

n8n stores workflows in a SQLite database inside the Docker volume. If that volume disappears, so do all your workflows. Export important workflows as JSON regularly, and store those exports in Git. n8n’s interface lets you download any workflow as a JSON file — make this part of your backup routine.

Putting It All Together

Here is what a well-connected homelab looks like once n8n is wired in:

• Monitoring: Uptime Kuma detects a container crash → n8n restarts it → verifies recovery → sends Telegram confirmation
• Intelligence: RSS feeds collected daily → filtered by relevance → summarised by Ollama → formatted digest delivered to Telegram
• Backups: Nightly backup script → validation → old backup cleanup → status notification
• Deployment: Code pushed to Gitea → webhook fires → n8n pulls latest code → rebuilds container → runs health check
• Reporting: Daily system health check → Docker stats, disk usage, Pi temperature → morning briefing message

None of these require your intervention. They run 24/7 on a computer that costs £80 and draws 10 watts. When something needs your attention, it tells you. When it does not, it stays quiet.

That is not a hobby project. That is operations.

What to Do Next

1. Build the daily report workflow first. It is simple, immediately useful, and teaches the core concepts.
2. Add the self-healing workflow if you have Uptime Kuma from the monitoring guide. This is the one that will impress in interviews.
3. Connect Ollama if you set it up in the AI guide. Even a basic summarisation pipeline demonstrates AI integration skills.
4. Export your workflows as JSON and commit them to version control — which is exactly what we cover in the next and final guide.

Next in the series: Gitea: Own Your Code, Track Your Infrastructure — version control for everything you have built so far, including those n8n workflow exports.

Previous: K3s: Real Kubernetes on a Raspberry Pi

Series hub: Raspberry Pi 5 Homelab: 10 Projects That Actually Advance Your Career