Installing n8n on a Raspberry Pi: the complete guide (Docker, ARM64)

A Raspberry Pi gathering dust in a drawer can become a full automation server: n8n runs very well on ARM64, the official Docker image is published for that architecture, and at a few watts of power draw it is probably the cheapest self-hosted n8n you can keep running around the clock. This guide covers the setup end to end — picking the model, preparing the OS, Docker, a Pi-tuned docker-compose.yml — then the questions most tutorials skip: the SD card, what a Pi can realistically handle, and HTTPS access from outside when the instance lives behind a home router. If you're new to n8n on Docker in general, start with our n8n Docker installation guide: this one is its Raspberry Pi-specific follow-up.

Which Raspberry Pi to choose (and why 64-bit is mandatory)

Two models are solid candidates:

Model	RAM	Verdict for n8n
Raspberry Pi 4	4GB	The comfortable minimum for n8n alone
Raspberry Pi 4	8GB	Headroom for n8n + other services
Raspberry Pi 5	4-8GB	Faster, recommended for a new purchase
Pi 3 and older	≤ 1GB	Avoid: too little RAM, and often 32-bit

The knockout criterion isn't horsepower but architecture: the official n8nio/n8n Docker image is published for amd64 and arm64 only. A 32-bit Raspberry Pi OS (armv7) — even on a Pi 4 that's perfectly capable of 64-bit — cannot run the container; Docker will fail with a platform error. Make sure you install the 64-bit variant of the OS.

Using the Pi as a serious server is hardly a stretch, by the way: back in the board's early days, Simon J. Cox and his team at the University of Southampton assembled "Iridis-pi", a working compute cluster built from 64 Raspberry Pis, described in the journal Cluster Computing in 2014 (see the study on Google Scholar). Their demonstration established exactly what matters here: the Pi is viable as a very low-cost, very low-power server node. A single one is plenty for n8n.

Preparing Raspberry Pi OS Lite 64-bit with SSH

The easiest route is the official Raspberry Pi Imager (Windows, macOS, Linux):

1. Pick the Raspberry Pi OS Lite (64-bit) image — "Lite" because a server needs no desktop environment, which frees up RAM and CPU.
2. Before writing the card, open the Imager's advanced settings: set the hostname (say n8n-pi), enable SSH, create your user, and configure Wi-Fi if the Pi won't be on Ethernet (Ethernet is still preferable for a server).
3. Write the image, insert the card, power up the Pi.

After a minute or two, connect from your machine:

ssh your-user@n8n-pi.local

# Confirms the OS really is 64-bit: must print "aarch64"
uname -m

# System updates before installing anything
sudo apt update && sudo apt full-upgrade -y

If uname -m prints armv7l, the installed OS is 32-bit: redo the imaging step with the right image — nothing else will work properly.

Installing Docker and the Compose plugin

Docker's official script handles the ARM architecture automatically:

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

# Lets you use docker without sudo (log out and back in afterwards)
sudo usermod -aG docker $USER

# Checks
docker --version
docker compose version

As on a VPS, use docker compose (the v2 plugin, no hyphen) rather than the old, deprecated docker-compose binary.

The docker-compose.yml for Raspberry Pi

On a Pi, there's no need to deploy PostgreSQL from day one: SQLite, n8n's default database, is a good fit here — a single user, a modest execution volume, and one less service to squeeze into RAM. Create a /opt/n8n directory and drop in this file:

volumes:
  n8n_data:   # encryption key, config, SQLite database

services:
  n8n:
    # Multi-arch image: Docker picks the arm64 variant automatically
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      # Timezone for scheduled triggers (Cron, Schedule)
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      # Public URL once remote access is set up (see below)
      - N8N_HOST=n8n.yourdomain.com
      - WEBHOOK_URL=https://n8n.yourdomain.com/
    volumes:
      - n8n_data:/home/node/.n8n

Then:

cd /opt/n8n
docker compose up -d
docker compose logs -f n8n   # wait for "Editor is now accessible"

The editor answers on http://n8n-pi.local:5678: create the owner account and the instance is live. The n8n_data volume holds the credentials encryption key and the SQLite file: that's what you'll be backing up (more below). If your instance ever grows enough to justify PostgreSQL, the general Docker guide provides the full compose file with a dedicated database.

SD card or USB SSD: the real reliability question

This is the point most tutorials gloss over. n8n writes to its SQLite database on every workflow execution: status, intermediate data, history. On an SD card, those small repeated writes wear out the flash memory cells, and SD card corruption is the number one failure mode of Raspberry Pis running 24/7. The classic symptoms after a few months: a read-only filesystem, a corrupted database, an instance that won't come back up.

Recommendations, in order of robustness:

1. USB SSD (recommended): a SATA SSD in a USB 3 enclosure or a small NVMe USB drive, generally under $50. Since the Pi 4, you can boot straight from USB: flash the OS onto the SSD instead of an SD card and the problem disappears entirely — with markedly faster disk access as a bonus.
2. A quality SD card plus precautions: if you stick with SD, get a "High Endurance" card (designed for dashcams), and cap n8n's execution history retention with EXECUTIONS_DATA_MAX_AGE to reduce writes.
3. Either way: regular backups of the n8n_data volume, because every storage medium eventually dies.

What a Raspberry Pi handles well — and its limits

A Pi 4/5 with 4GB of RAM is perfectly comfortable with the workloads that make up the daily life of most personal instances:

• Webhooks: receiving events (forms, GitHub, Stripe...) and reacting to them.
• Scheduled workflows: reports, follow-ups, periodic syncs.
• Light API calls: reading/writing Notion, Google Sheets, Telegram, sending emails.
• Home automation: the Pi's natural playground — n8n talks fluently to Home Assistant (webhooks and REST API) and MQTT, often on the same local network, or even the same machine with 8GB of RAM.

The limits are just as clear-cut:

• Heavy AI and RAG workflows: embedding documents, running agent chains, handling long contexts — RAM vanishes fast and the ARM CPU struggles under sustained loads like these.
• Large binary data: processing PDFs of tens of megabytes, videos or image batches pushes memory and storage beyond what's reasonable for a Pi.
• High concurrency: dozens of simultaneous executions call for a real server, possibly in queue mode.

If your needs lean that way, a small dedicated server stays affordable: our guide to choosing a VPS for self-hosted n8n and our breakdown of the real cost of self-hosted n8n help you size things without overpaying. The Pi and the VPS aren't mutually exclusive, either: many people keep the Pi for local home automation and offload heavy workflows elsewhere.

Remote HTTPS access: Cloudflare Tunnel or a reverse proxy

A Pi behind a home router faces two problems a VPS doesn't: the public IP changes (or doesn't really exist, with some ISPs' CGNAT), and forwarding ports on your router exposes your home network.

Cloudflare Tunnel is the recommended solution in this context: a small daemon (cloudflared, available for arm64) runs alongside n8n and opens an outbound connection to Cloudflare, which publishes your subdomain over HTTPS. No open ports on the router, automatic certificate management, home IP invisible. The full setup, including adding the cloudflared service to the compose file, is covered in our n8n + Cloudflare Tunnel guide.

The classic alternative — a Traefik or Caddy reverse proxy with a Let's Encrypt certificate — also works on the Pi, but assumes a reachable public IP and ports 80/443 forwarded on the router. The procedure is the same as on a VPS: follow our guide to running n8n over HTTPS with a domain name. In both cases, remember to align N8N_HOST and WEBHOOK_URL with the public URL, or your webhooks will display unreachable addresses.

And if the instance only serves local home automation, the safest option is to expose nothing at all: n8n then remains reachable only on your home network (or through a VPN like WireGuard/Tailscale).

Backups and updates

With SQLite, everything lives in the n8n_data volume: database, encryption key, configuration. A backup boils down to archiving that volume, ideally onto another machine — a Pi is no place to store its own backups:

# Brief stop for a consistent copy of the SQLite database
docker compose stop n8n
docker run --rm -v n8n_n8n_data:/data -v $(pwd):/backup alpine \
  tar czf /backup/n8n-backup-$(date +%F).tar.gz -C /data .
docker compose start n8n

Then copy the archive off the Pi (scp, rclone to cloud storage...) and schedule the whole thing with cron. If you ever migrate to PostgreSQL, the backup mechanics change (pg_dump rather than a file copy), but the principle stays the same: database and encryption key, always together.

For updates, the rule is the same as for any Dockerized n8n: pin an exact version rather than latest, back up first, then docker compose pull && docker compose up -d. The detailed procedure — and the pitfalls of version jumps — are in updating n8n on Docker without breaking anything.

The real selling point: an instance that costs a few watts

It was already the Iridis-pi team's conclusion: the Raspberry Pi shines where cost and power consumption come first. A Pi 4 or 5 under light load draws on the order of a few watts — versus dozens for an old PC recycled as a server — which translates into a few dollars of electricity per year for an always-on instance. Add a USB SSD and the total hardware bill stays comfortably low, with no monthly subscription.

For webhooks, scheduled workflows and home automation, that is very hard to beat. And the day your workflows outgrow the machine, everything you've built — the compose file, the exported workflows, the backups — moves as-is to a VPS: that's precisely the portability Docker guarantees, and what our n8n Docker installation guide describes on the server side.