Does anyone know why my self-hosted? Dragging nodes, opening nodes, typing… it feels like I’m using a Pentium 1! I’m using a VPS.
Welcome back!
I totally understand the frustration when the n8n editor gets sluggish
I’d feel the same way!
I’m not aware of any recent n8n update that directly causes self-hosted instances to slow down, though it’s always possible. What I do know is that slowdowns like this are typically tied to resource constraints or configuration issues rather than the update itself.
Common Causes on Self-Hosted VPS
Insufficient Resources (CPU/RAM)
Very small VPS instances (e.g., 1 vCPU / 1 GB RAM) struggle with the UI, especially on newer n8n versions that use a bit more memory. Community recommendation: At least 2–4 GB RAM and 1–2 vCPUs for a smooth experience.
Memory Pressure / OOM (Out of Memory)
Large workflows, manual executions with lots of data, or heavy Code nodes can consume significant memory and cause the UI to “stutter.”
Large Executions Running in the Editor
When you manually execute big workflows, all the results need to be sent to your browser, which directly impacts UI performance.
Non-Recommended Configuration (Task Runners)
Having N8N_RUNNERS_ENABLED=true on a simple single-instance setup has caused slowdowns and errors in several community-reported cases.
Upgrading on a Very Small VPS
Some users noticed increased CPU/RAM usage after upgrades. The issue resolved itself when they scaled up resources—confirming it wasn’t a bug, just resource constraints.
If you’d like me to dig deeper, feel free to share:
- VPS specs (CPU/RAM)
- n8n version
- Whether you’re manually executing large workflows
- Whether you’re using runners or queue mode
Happy to investigate further once I know more! 
Which hosting provider do you use?
VPS Contabo
I allocated 2GB for the editor, 1GB for Work and each webhooks, and 512MB for runners.
Contabo typically has very limited CPU for applications with rich UIs like the n8n editor. Even with sufficient RAM, CPU becomes the bottleneck.
My recommendation:Test on another VPS provider or upgrade to a plan with dedicated CPU to validate whether that resolves the slowness.
This will help confirm if it’s a resource constraint specific to your current setup. Let me know how it goes!
I set up the VPS 2 months ago…it was working fine until about 15 months ago. Even so, could it be the CPU?
Is there a way to clean up the n8n Dockerfile to see if anything is causing the slowdown?
There’s no documentation saying this will work, but you can try these validations and if nothing works out, follow this path.
The official workaround is to separate the editor from execution load. The architecture recommended by n8n is to have a main instance for the editor, workers for executions, and queue mode with Redis.
To reduce the editor’s load with simple and supported actions, you can limit large manual executions in the editor, disable excessive execution saving if it’s not necessary, and avoid keeping giant workflows open on the canvas for long periods. These practices reduce reprocessing on the frontend.
The editor slowness isn’t related to a “dirty” Dockerfile or any internal n8n procedure. The behavior is consistent with a CPU bottleneck, which is very common on Contabo VPS instances due to shared CPU. The n8n documentation doesn’t recommend image customization for performance. The only supported workarounds are validating CPU resources, separation via queue mode and workers, and using infrastructure with dedicated CPU.
Feel free to reach out.
Hi @brauliodiasribeiro Welcome Back!
N8N was also slow for me although i was not even using VPNs , but the problem was the tunneling service i was using and the hardware, i recommend switching to a better hardware and tunnel if that is the problem hope this helps.
I’ll try…thank you
1 Like
My N8N is in queue mode… I’ll try those options, thanks.v
Sure 
Translation:
Look at the slowness I’m talking about… you can’t even use it.
I see @brauliodiasribeiro , have you tried running n8n on npm? Give it a shot you would see the difference. This would help.
I found something out… my domain is on Cloudflare.
I removed Traefik from n8n and I’m accessing it directly via the VPS IP… the freezes stopped.
Cloudflare is causing some issue during this transition.
Umhm! It can be a solid fix i thought it was a server issue to checking with local npm version would be nice, but as you are using everything on cloudFlare this makes sense. Direct tunneling might make this really faster, give it a shot i use that only.
It became slow again and started visually freezing.
I also have a local instance that is freezing as well—it even takes a long time just to execute the nodes. I give up.
I’ve noticed that n8n has been breaking a lot with each new update. Something always changes, and the learning curve ends up being quite steep.
It used to be more stable in the past.
@brauliodiasribeiro That’s something which should not happen I’d recommend against wiping all just yet. Because you notice the same “Pentium 1” sensation on a VPS, I would be checking a few things first
Try another browser or incognito, check whether your VPS has at least 2,4 GB RAM and is not hitting the CPU max, and check whether smaller test workflows feel quicker than your main ones. Usually, this indicates whether it’s a resource/UI issue or something deeper, in which case a fresh install or other tunnel might be worth it. Like i have never faced something like this that it is working so slow, and as you have tried NPM version of n8n on your PC and it behaves the same i do not think it should be freezing and lagging that much on your PC, have you tried the npm’s version with it’s installation guide?
And if nothing works in your end, you can try cloud!
I’m facing a similar issue in my setup. I have two primary environments: beta and production, where a self-hosted n8n instance is available to users in Amazon ECS.
My current configuration includes:
-
One main service and one worker service, both with auto-scaling enabled (up to 5 instances each).
-
Each main and worker instance is provisioned with 4 vCPUs and 8 GiB RAM.
Initially, I suspected the issue was related to the lack of caching (for example, via CloudFront or ALB caching). However, when I performed load testing in the beta environment using production-equivalent configurations and without caching enabled, the n8n instance handled the load without any issues. [ Basically not able to reproduce the “Page Unresponsive” issue in beta , so its not because of caching ]
But my DB blew up,
Its CPU Utilization was more, so, increased the config, and now, its down to 20%.
Still the “Page Unresponsive” Issue Persists.
Would be helpful if this issue is resolved 