Installing n8n on a Synology NAS: the Container Manager guide

Your Synology NAS is already running 24/7, it's already in your home, and it can run Docker containers: that makes it a natural candidate for hosting n8n without renting any server at all. This guide walks through the full installation via Container Manager, DSM's container management package: shared folder, docker-compose project, the classic permissions trap, clean HTTPS access with the built-in reverse proxy, backups and updates. If you're going with a regular Linux VPS instead, the general approach is covered in our n8n Docker installation guide — most of what follows is the Synology-flavored version of it.

Why host n8n on your NAS

Two arguments carry real weight against a VPS or n8n Cloud. The first is economic: the machine already runs around the clock for your backups and files, so the marginal cost of an n8n container is close to zero, where a VPS adds a few dollars a month to the bill. The second is where your data lives: your workflows, credentials and execution history stay physically at home.

That instinct isn't irrational. The study "Home is safer than the cloud!" by Iulia Ion, Niharika Sachdeva, Ponnurangam Kumaraguru and Srdjan Čapkun, presented at the SOUPS 2011 symposium (see it on Google Scholar), showed that security experts and non-expert users alike place more trust in local storage than in the cloud for their sensitive data. It's precisely one of the recurring motivations behind self-hosting — and a NAS you already own is the cheapest way to act on it.

Prerequisites: which Synology, which DSM version

Item	Recommendation
Model	x86-based NAS, typically the "+" ranges (DS224+, DS423+, DS923+, etc.)
System	DSM 7.2 or later, with the Container Manager package installed from Package Center
RAM	2GB is enough for typical workflows; 4GB or more for comfortable headroom
Access	SSH enabled (Control Panel → Terminal & SNMP) for the permissions step

The blocking factor is the CPU: Container Manager (which replaced the Docker package with DSM 7.2) is only available on x86 models. Entry-level ARM models — the DS223, DS124 and their siblings — don't get it in Package Center, and there's no clean workaround. If that's your situation, n8n on a Raspberry Pi offers an at-home alternative for a few dozen dollars.

Step 1: create the data folder

n8n stores its configuration, its SQLite database and, most importantly, its credentials encryption key in /home/node/.n8n. That directory must be mounted onto a folder on the NAS so it survives container updates.

In File Station, open the docker shared folder (created automatically when Container Manager is installed; otherwise create it via Control Panel → Shared Folder) and create an n8n subfolder inside it. The full path on the NAS side is:

/volume1/docker/n8n

Step 2: fix the volume permissions (the classic trap)

This is the number one mistake in n8n installs on Synology. The n8n container doesn't run as root but as the node user, uid 1000. A folder created from File Station, however, belongs to your DSM account, and uid 1000 has no write access to it. The result: the container starts, then crash-loops with an EACCES: permission denied error on /home/node/.n8n.

The fix goes through SSH. Enable SSH access in Control Panel → Terminal & SNMP, log in with an administrator account, then run:

# Gives ownership of the folder to uid 1000 (the container's node user)
sudo chown -R 1000:1000 /volume1/docker/n8n

Do this before the first start: it saves you a round trip through the logs.

Step 3: create the project in Container Manager

Open Container Manager → Project → Create. Name the project (n8n), pick /volume1/docker/n8n as the path (or a dedicated projects folder if you prefer keeping compose files and data apart), select "Create docker-compose.yml" and paste:

services:
  n8n:
    image: n8nio/n8n:latest
    container_name: n8n
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      # Timezone for scheduled triggers (Cron, Schedule)
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      # Allows the session cookie over plain HTTP — only for
      # initial local access, remove once HTTPS is in place
      - N8N_SECURE_COOKIE=false
    volumes:
      # Folder created in step 1, owned by uid 1000
      - /volume1/docker/n8n:/home/node/.n8n

Click through the remaining wizard steps (the web portal DSM offers isn't needed) and start the project. Container Manager pulls the image and starts the container; the container's Log tab should show Editor is now accessible.

A word on N8N_SECURE_COOKIE=false, which often catches people out: by default, n8n marks its session cookie as secure, meaning HTTPS-only. Since the first access happens over HTTP on the NAS's local IP, without this variable the login screen stubbornly refuses to let you in. It's a temporary relaxation, to be removed in step 5. The other useful variables (PostgreSQL database, executions, logging) are catalogued in our n8n environment variables guide.

Step 4: first start

Open http://nas-ip:5678 (for example http://192.168.1.20:5678). n8n prompts you to create the owner account — the instance's administrator. Use a real email address and a strong password: this step only happens once.

At this point, the instance works for everything triggered from the inside: scheduled triggers, manual workflows, outbound API calls. What doesn't work yet: inbound webhooks from the internet, which need a public HTTPS URL.

Step 5: clean HTTPS with DSM's reverse proxy

DSM ships everything needed to expose n8n cleanly on a subdomain, with no extra container. Three sub-steps:

1. The certificate. Control Panel → Security → Certificate → Add: request a Let's Encrypt certificate for your subdomain (say n8n.yourdomain.com), whose DNS record points at your public IP. Ports 80 and 443 must be forwarded to the NAS on your router for validation and traffic.

2. The reverse proxy. Control Panel → Login Portal → Advanced → Reverse Proxy → Create:

• Source: protocol HTTPS, hostname n8n.yourdomain.com, port 443
• Destination: protocol HTTP, hostname localhost, port 5678

In the Custom Header tab, click Create → WebSocket: DSM adds the Upgrade and Connection headers the n8n editor depends on (without them, the UI freezes or loses live execution results).

3. The n8n variables. Go back to the Container Manager project and adjust the environment:

    environment:
      - GENERIC_TIMEZONE=Europe/Paris
      - TZ=Europe/Paris
      - N8N_HOST=n8n.yourdomain.com
      - N8N_PROTOCOL=https
      # Public URL used to generate webhook addresses
      - WEBHOOK_URL=https://n8n.yourdomain.com/
      # N8N_SECURE_COOKIE removed: HTTPS is in place

Rebuild the project (Action → Clean, then Build, or simply stop/start after editing). Without WEBHOOK_URL, n8n would keep advertising webhook URLs like http://localhost:5678/…, unreachable from any third-party service. Once your webhooks are public, remember to protect them — secret header, signature validation: our guide to securing n8n webhooks walks through the options. And if you can't or don't want to open ports 80/443 on your router (dynamic IP, CGNAT), a Cloudflare Tunnel exposes the instance without opening a single port.

Backups: Hyper Backup does the job

The instance's entire state lives in /volume1/docker/n8n: the SQLite database (workflows, encrypted credentials, execution history) and the encryption key. A Hyper Backup task that includes the docker shared folder — to a USB drive, a second NAS or remote storage — therefore covers n8n, with versioning and scheduling included. One precaution: the SQLite database may be mid-write during the copy; schedule the backup at a quiet hour (overnight, away from scheduled executions) or stop the container for the duration of the task for a perfectly consistent copy.

Updating the n8n image

Container Manager flags new images but won't update a project on its own. The safe procedure:

1. Back up /volume1/docker/n8n (or check that Hyper Backup ran recently).
2. In Container Manager → Image, download the new version of n8nio/n8n.
3. Open the project, Action → Clean, then start it again: the container comes back on the new image, and the data stays in the volume.

n8n applies its database migrations on startup, which makes rolling back tricky without a backup. Pinning an exact version (n8nio/n8n:1.x.y) rather than latest avoids jumping several major versions on the wrong day — the full reasoning is laid out in updating n8n on Docker without breaking anything.

The honest limits of n8n on a NAS

A NAS is not an application server. Three limits worth knowing before betting everything on it:

• RAM. 2GB models share that memory between DSM, Synology packages and your containers. Workflows that parse large files or chain AI model calls can saturate the machine — for those heavy use cases, a dedicated VPS (see the standard Docker installation guide) remains the right tool.
• CPU. The embedded Celeron/Ryzen chips handle dozens of API and email workflows with ease, but far less so heavy data crunching in Code nodes.
• Residential availability. Power cuts, router reboots, changing IP addresses: nothing disqualifying for personal use or a small team, but a critical service billed to clients deserves infrastructure designed for it.

For the vast majority of cases — personal automations, monitoring, syncing, notifications, lightweight AI workflows — the NAS is on the contrary an excellent host: already paid for, already powered on, data at home.

What's next?

Your n8n runs on the NAS, over HTTPS, backed up by Hyper Backup: all that's left is to fill it. This is exactly the kind of instance our workflow packs import onto in minutes — the AI Inbox Pack ($79), for instance, adds automatic email triage and reply drafts to your mailbox while keeping the processed emails on a machine you own. Hard to be more consistent with the reasons that made you choose self-hosting in the first place.