Hello @andreasdueren Thanks for the input. I have tested this and what you have stated is indeed correct. So yes we can add this feature, but the alias will still redirect to n8n itself. If that is okay, I can create an app update for N8N.

@alwynispat SQLite is not as brittle as you think.

Hello @jkammerer It should be working.

Hi @james, thank you very much for the quick implementation and for adding Queue Mode support to the Cloudron n8n package. I have tested it now, and the difference is very noticeable. The n8n UI stays stable and responsive while larger executions are running, and the workload can finally make use of multiple CPU cores through the worker processes. This is exactly the behavior I was hoping for. In my case, it makes larger workflows much more usable and stable compared to running everything in a single n8n process. Especially with workflows that process large amounts of data, Queue Mode helps a lot because the main process no longer gets blocked by all the execution work. So far, the setup works well for me. Being able to configure the number of workers through the Cloudron package is very useful, and I think this is a great improvement for people running heavier n8n workloads on Cloudron. Thanks again Cloudron team for the fast response and implementation!

Hello @chrishvd I was not able to reproduce your issue. Please contact support@cloudron.io so we can look deeper into this.

I didn't realize! Thank you!

@zigmasdirigeant said: Btw, this shouldn't be inside N8N. This is more a request for an app, not N8N alone. I agree, I'm not even sure how I did that, I tried changing it but couldn't find how.

@umnz same thing happened with me i updated and n8n when into broken state i restarted and it worked

Hello @bedrijfstak14 Great to read that the Cloudron update 9.1.7 resolved this issue.

the update is live, thanks!

I did a clean install of n8n and it installed quickly. So something is/was up with my old n8n instance. Not a huge problem, I'll just migrate my workflows to the new and archive the old instance.

Hello @ekevu123 Disabling is not actually disabling, but more disabling a custom override of the default which is 300 seconds.

Glad to hear it! Thanks @nebulon.

Looks like this is working. However, some of my disk read/write nodes were broken after this update. I was able to fix it by updating the paths inside the nodes to explicitly include "/app/data/". Otherwise the error I get is something like "Problem in node ‘Write Files to Disk‘ EROFS: read-only file system, open: xxx". Other than that, it appears the update is working correctly and binary form data is working again! Thanks for your help!

[image: 1772054312996-screenshot-2026-02-25-at-21.18.14-resized.png]

@msbt said in Issue with Read/Write node: export N8N_RESTRICT_FILE_ACCESS_TO="/app/data" This solves it Thank you

Thank you @james We performed these steps and it was successful: Add these lines in env.sh export NODES_EXCLUDE="["ExecuteCommand", "LocalFileTrigger"]" Restarted N8N Performed the test using these steps: (+) - Execute command Execute Once: ON Command: ffmpeg -version Test step Check the OUTPUT - ok (screenshot attached) [image: 1767355746616-screenshot-from-2026-01-02-13-03-11-resized.png]