Use n8n on Synology: Avoid These Pitfalls

❗️This article was translated from the Chinese version by Google Gemini, and the information may be biased.❗️

n8n is an open-source low-code platform that allows you to create automated workflows without writing a single line of code. I have previously experimented with it in my projects on building a smart home and creating a reading system with AI.

Over the past year, with the rise of large language models, n8n has become increasingly popular. After all, it’s the most convenient and cost-effective way for average users to build their own AI tools instead of relying on others.

I had been running n8n on my Synology NAS, hoping to save on subscription fees and avoid storage limitations. I also thought it would be a good way to utilize my NAS’s idle CPU power.

However, I encountered some issues while using n8n on Synology.

To cut to the chase: I would advise against it. You’re better off getting a dedicated server from CloudCone using my referral link – they start at just $17.12 per year.

But if you’re determined to go ahead with it, this article outlines some of the pitfalls I encountered. This is not a deployment guide, as n8n is highly adaptable and can be easily deployed on Synology with a single click. If you’re familiar with Docker on Synology, simply search for n8n and create a container.

Pitfall #1: Unresponsive Editor

This is a strange bug where the Editor fails to display the real-time execution progress of a workflow. Clicking the “Stop” button has no effect, and attempting to stop it again results in an error message stating that you cannot stop an already stopped workflow.

However, upon checking the execution logs, you’ll find that the workflow actually ran and stopped as expected. While this bug doesn’t impact the workflow’s functionality, it makes debugging incredibly difficult during development. The inability to see execution results prevents you from dragging and dropping variables from one node to another, essentially hindering n8n’s visual low-code capabilities.

I searched extensively online and found a related issue on n8n’s GitHub repository, but the different environment meant the solution didn’t apply to my situation.

The actual solution: Do not use Synology Web Station as the web portal for n8n’s external access.

Instead, use the reverse proxy server under Control Panel > Login Portal > Advanced > Reverse Proxy Server to configure n8n’s external access. The configuration is straightforward:

However, this alone doesn’t solve the issue, as the root cause lies in n8n’s frontend being unable to communicate with the backend via WebSocket. To resolve this, click on “Custom Header” and select Create > WebSocket:

This will automatically add proxies for two methods: “Upgrade” and “Connection.” Simply save the settings. If they’re not automatically filled in future DSM versions, manually enter the following:

Header Name	Value
Upgrade	$http_upgrade
Connection	$connection_upgrade

With that, you’re done! Your n8n Editor should now respond to the running status correctly.

I actually derived this method from this tutorial.

That tutorial focuses on installing n8n on Synology, but you can disregard those instructions as it involves installing a third-party Docker manager called Portainer, which is unnecessary. If you haven’t deployed n8n yet, simply search for it directly in the built-in Container Manager in DSM 7.0 or later.

You can refer to my environment variable settings:

Variable	Value	Remarks
N8N_PORT	5678	Docker port
N8N_PROTOCOL	https	Enable HTTPS access
N8N_HOST	yourname.familyds.net	Your DDNS address for external access (without the port). If you don’t need external access, you can leave this blank.
N8N_WEBHOOK	https://yourname.familyds.net:5680/	n8n’s webhook address, which should be the same as your external access address for n8n. Include the protocol prefix.
GENERIC_TIMEZONE	Asia/Shanghai	Set n8n’s default timezone

Additionally, make sure to configure persistent storage:

In Synology, select a directory and map it to /home/node/.n8n/ in the n8n Docker container. Otherwise, while n8n will function normally, all your data and workflows will be wiped out when you upgrade n8n using Docker next time.

Pitfall #2: External Access

This isn’t really a pitfall, but some people might be confused about how to configure the ports for external access to n8n on Synology.

Let me briefly explain.

First, your Synology NAS itself needs to be accessible from the internet. There are a few prerequisites for this:

1. If you’re on a home broadband connection, you’ll need a public IP address. You can request this by contacting your ISP’s customer service. There are plenty of tutorials online.
2. Add a new DDNS entry under Control Panel > External Access > DDNS. You can use Synology’s own DDNS service for convenience.
3. To make your Synology NAS publicly accessible, you have two options:
   • UPnP (recommended): Enable UPnP under Control Panel > External Access > Router Configuration.
   • DMZ: In your router settings, set the DMZ to your Synology NAS’s internal IP address.

I don’t recommend using DMZ due to security concerns. UPnP offers better control over which ports on your NAS are exposed to the internet.

When using UPnP, the IP configuration can be a bit tricky.

In our environment variables above, we set the N8N_PORT to 5678, which is the Docker port (container port). However, Docker typically uses a bridge network with the host, meaning you also have a local port. Finally, you’ll need an external port for external access.

The network path looks like this:

N8N ➡️ Synology Local ➡️ Router (Internet)

When installing n8n on Synology using Docker, if you accidentally checked the option to proxy n8n through Web Station, you’ll find that port 5678 is permanently occupied in the n8n project settings:

Don’t worry, though. Simply add a new port forwarding rule. In the container port field, enter 5679. Then, in the local port field, enter 5679 as well. If you used a non-default container port, adjust this accordingly based on your environment variable settings.

The local port doesn’t have to be the same as the container port.

Once this is done, go to Control Panel > Login Portal > Advanced > Reverse Proxy Server and configure it as shown in the screenshot for Pitfall #1. The “Source” should be your DDNS address, and the “Port” should be the port you want to use for accessing n8n externally (the external port). The “Destination” should be “localhost,” and the “Port” should be your local port.

Finally, go to Control Panel > External Access > Router Configuration and set up UPnP. Here, you should be able to add a new “Built-in Application” and select the n8n reverse proxy you just created.

Pitfall #3: Connecting to Large Language Models

This is the biggest headache. If your Synology NAS is located in mainland China and you want to connect n8n to a large language model, I’d advise you to abandon that idea altogether. For starters, setting up a proper internet connection on Synology in mainland China can be a challenge in itself.

But even if you manage to get a working internet connection, you might find that n8n still can’t access certain websites. Despite setting the HTTP_PROXY and HTTPS_PROXY environment variables, some n8n nodes still won’t be able to bypass the restrictions.

The reason behind this is that some n8n nodes use a library called Axios for making network requests. And Axios has a longstanding issue (for over 4 years!) where it cannot proxy HTTPS connections over HTTP. It requires the address specified in HTTPS_PROXY to be a valid HTTPS address with a certificate, not the local IP address of your proxy server. This means that many popular proxy methods commonly used in China won’t work.

There are workarounds to address this issue in Axios itself, but these solutions aren’t implemented in the version bundled with n8n.

There are three temporary solutions:

1. Use a secondary router to route all your internet traffic through a proxy server, effectively giving your entire network (including your Synology NAS) unrestricted internet access.
2. In the workflow settings, change the “Execution Order” to “v0 (legacy).”
3. Use the “HTTP Request” node instead of the dedicated “LLM” node and send requests to the large language model directly.

Out of these three, only the first one is a complete solution, but it’s also the most difficult to implement for most users.

The second method has its drawbacks: some nodes, such as “RSS Read” and “RSS Feed Trigger,” might still ignore the proxy settings even in “v0 (legacy)” mode. Moreover, this is n8n’s execution engine from before version 1.0, so there’s no guarantee how long it will be supported.

The third method is limited because n8n’s “AI Agent” node cannot connect to the “HTTP Request” node, meaning you can’t use it for workflows involving chatbots or LangChain.

Therefore, deploying n8n on Synology, particularly in mainland China, comes with its fair share of challenges. If you’re serious about using n8n with large language models and integrating them into your workflows, consider getting a dedicated server from a provider outside mainland China. It’s a worthwhile investment, costing around $40 per year.

CloudCone is currently running a 2024 promotion where you can get a 4 CPU, 4GB RAM, 220GB storage VPS for just $55.9 per year. If you’re interested, you can check it out through this link (it also gives me a small commission). Besides this particular plan, they offer even more affordable options that are more than capable of running n8n: