n8n on Synology NAS (Container Manager, Postgres)

Anyone who wants to run n8n on a Synology NAS today sets up the automation platform via Container Manager as a Docker Compose project, adds a Postgres database instead of the bundled SQLite file for productive use, and maps the data and configuration folders to fixed NAS shared folders. Container Manager is the successor to the former Docker package and requires DSM 7.2 or newer; the official n8n Docker documentation is now located at a new address under "Deploy" instead of the old "Hosting" path. As of: July 2026.

Container Manager instead of Docker package

With DSM 7.2, Synology replaced the previous Docker package with Container Manager. Technically, Docker still runs in the background, but the interface has been extended with a Project function that allows multiple containers to be managed together via a docker-compose.yml. This is exactly relevant for n8n with Postgres, because two containers need to work together: the database and the n8n application itself. It is also important for planning that, according to Synology's community practice, there is no predefined default folder for container data; a dedicated shared folder such as "docker" on a volume is therefore advisable before the first project is created.

n8n with Postgres instead of SQLite

Without further configuration, n8n stores credentials, workflows and execution histories in a local SQLite file. For the switch to Postgres, the n8n documentation on the Docker installation provides a fixed set of environment variables: DB_TYPE must be set to postgresdb, plus DB_POSTGRESDB_HOST, DB_POSTGRESDB_PORT, DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_USER and DB_POSTGRESDB_PASSWORD. A suitable docker-compose template with a Postgres service is provided by n8n in the official n8n-hosting repository, where the default user and password are adjusted in an .env file before the first start. Important to know: even with an external Postgres database, the n8n-specific data folder under /home/node/.n8n remains relevant; it contains, among other things, the encryption key for stored credentials and the instance logs, so this folder should still be mounted as a volume and backed up.

Creating a project and mapping volumes to NAS shared folders

In Container Manager, a new project is created under "Project", which is assigned a name and a path as the working directory, for example a subfolder on an existing volume. The docker-compose.yml can then either be uploaded or inserted directly in the built-in editor. For data storage, the container paths are mapped to fixed directories on the NAS: a local path on the shared folder, for example for the n8n data and for the Postgres data directory, is each mapped to the corresponding mount path in the container. This separation ensures that container updates do not affect the actual data, and that backups of the NAS shared folder automatically back up the n8n instance as well.

External access via reverse proxy

For access via a custom domain instead of just via IP address and port, DSM comes with its own reverse proxy, accessible via Control Panel, Login Portal, Advanced. There, a rule is created with source protocol, hostname and port as well as the corresponding destination port of the n8n container. Since n8n relies on WebSocket connections for the editor interface and for webhook delivery, the rule must be enabled for WebSocket accordingly, otherwise certain interactions in the browser will not work reliably. A valid HTTPS connection additionally requires a domain name that points to the NAS, for example via DDNS or a dedicated A record, as well as a suitable certificate in the DSM certificate management.

Limits of this solution

A NAS is not a dedicated server system, so you should keep an eye on hardware resources when several workflows run simultaneously or the Postgres database grows. You should also not let updates of the n8n image and the Postgres image run automatically in the background, but perform them deliberately with a prior backup of the volumes, since a failed database update could otherwise endanger the entire workflow inventory. Anyone using n8n not just privately but for business processes should also clarify who in the company is responsible for backups, updates and the reverse proxy before productive workflows run on it. NordFlux supports the setup and ongoing operation of n8n, more on that at n8n automation.

Frequently asked questions about n8n on Synology NAS

Do I necessarily need Postgres, or is SQLite enough on the NAS?

For simple, lightly used workflows, the bundled SQLite file also works on the NAS. As soon as multiple users, many parallel executions or productive processes are added, Postgres is the more robust choice according to the n8n documentation, because SQLite reaches its limits with concurrent write access.

Which DSM version do I need for Container Manager?

According to Synology, Container Manager is available from DSM 7.2 onwards. On older DSM versions, the corresponding application is still called Docker and does not offer the project function for docker-compose files in the same form.

Do I have to make my NAS publicly accessible for webhooks to work?

For incoming webhooks from external services, n8n must be reachable via a fixed, externally accessible address, usually via the DSM reverse proxy with its own domain and a valid certificate. Anyone working only internally and not needing external webhooks can also run n8n exclusively on the local network.

Where do I find the current official Docker guide from n8n?

The old address under /hosting/installation/docker/ no longer exists; the current Docker installation guide at n8n is now located at /deploy/host-n8n/install-options/install-with-docker. Anyone who still comes across the old path via a search engine should go directly to the current documentation to avoid relying on outdated information.