Tools like n8n, OpenClaw and Claude Code need to keep running in the background, and shared cPanel hosting is built around a request finishing and the process ending. Memory limits are the other wall. You can get some of them working for short stretches, but not reliably, which is why a persistent workload belongs on a VPS.
On this page
▾
Self-hosting tools like n8n, OpenClaw and Claude Code are increasingly popular with developers and small business owners who want more control over their workflows and AI tooling. The first question most people ask is whether they can run them on the hosting they already have. If that hosting is a shared cPanel account, the honest answer is that it depends on the tool, and for most of them, not reliably.
This post explains why shared hosting struggles with these tools, what you can realistically expect if you try, and when moving to a VPS makes more sense.
n8n, OpenClaw and Claude Code are all Node.js-based applications, but the more important detail is that they are designed to run as persistent background processes rather than traditional web applications.
A standard website or PHP app only does something when a visitor requests a page. These tools work differently. They need to keep running continuously:
- n8n polls for trigger events, listens for incoming webhooks and executes scheduled workflows whether or not anyone is browsing to it.
- OpenClaw is a self-hosted gateway between messaging platforms and AI agents. It holds open connections to services like Slack, Discord, Telegram and WhatsApp, runs scheduled heartbeats and responds to messages in real time.
- Claude Code runs as an interactive terminal session, reads and writes files, and makes continuous outbound API calls.
That persistent process requirement is the core reason shared hosting is a difficult fit.
Why shared hosting works against persistent processes
UK shared hosting built on cPanel with CloudLinux is architected around the request/response model. A visitor hits your site, the web server handles the request and returns a response. That is the entire lifecycle of a process. Several layers enforce this model, and each one creates a problem for tools like n8n.
Phusion Passenger manages Node.js apps on cPanel. It is designed for web apps: it starts a worker process when HTTP traffic arrives and kills idle processes when traffic stops. A background automation tool that is not receiving web requests looks idle to Passenger, and Passenger will terminate it.
CloudLinux LVE (Lightweight Virtual Environment) enforces hard per-account limits on CPU, RAM, I/O and the number of concurrent processes. The operating system kills processes that exceed the allocation, and it does so without warning, which is the behaviour that catches out anything expecting to run indefinitely.
CageFS virtualises the filesystem per user account, isolating each customer in their own environment. This affects how processes see system paths, which can cause unexpected behaviour when running non-standard tooling such as NVM-installed Node.js versions.
There is also no persistent port binding available on shared accounts. Tools like n8n bind to a specific port and hold that binding open, and shared hosting does not allow arbitrary port binding for individual accounts.
Tip: If you want to understand how LVE resource limits work on shared hosting accounts, the LVE explainer in the UWH knowledge base covers what each limit means and when you are likely to hit it.
The memory problem, specifically
The LVE limits matter more than they first appear, because n8n’s memory use is not steady. At idle the process sits at roughly 100MB, which is unremarkable. The spikes are the problem.
When a workflow pulls in a large JSON response, the Code node duplicates that payload in memory, and a single execution can reach around 800MB. Three such workflows running in parallel can exceed 2GB. On a shared account, that is not a slow request. It is a process termination, and any workflow mid-execution goes with it.
This is also the mechanism behind a limitation that often gets reported without explanation. From version 2.0, n8n runs code in Task Runners that isolate execution in a separate process by default. Isolating work into additional processes is precisely what per-account process limits are designed to prevent, which is why the Code node is the first thing to stop working in a constrained environment.
The situation is not identical across all three tools.
n8n can be made to work with significant effort. Version 1.x runs as a single process and fits within shared hosting constraints reasonably well. Version 2.x is harder for the reasons above: more processes, more memory, and workarounds needed to get the interface loading correctly. Core functionality works and advanced features like the Code node do not. Reliability depends on cron-based process resurrection rather than proper process management, so if the process dies between cron runs, scheduled workflows simply do not fire until the next one.
OpenClaw has the same failure mode with a worse consequence. It is installable with effort and functional for basic use, but the continuous availability it is designed around is not something shared hosting can provide. A missed window here means missed messages, not just a delayed workflow, and there is no queue holding them for you.
Claude Code is a different case. It is an interactive terminal tool rather than a web app, so there is no practical way to run it as a Passenger-managed Node.js application at all. It can be installed on an account with SSH access, but the environment it needs, meaning a persistent shell, outbound API connectivity and headroom on memory, is fundamentally a VPS proposition.
Why a VPS removes these constraints
A VPS (Virtual Private Server) gives you a dedicated slice of a server with root access, no shared resource limits and control over what runs and how. For these tools, that changes the picture entirely.
Your allocated RAM and CPU are yours rather than shared with other accounts, so an 800MB spike is a normal event instead of a fatal one. systemd and PM2 work as intended, with genuine auto-restart on reboot rather than cron workarounds. You can bind to whatever port you need. Background processes are not terminated for looking idle. You can also run n8n and OpenClaw in isolated Docker containers from a single Compose file, which makes installation, upgrades and backups considerably more manageable.
The practical difference is the gap between a workaround and a proper installation. On shared hosting you are working against the environment. On a VPS these tools run the way they were designed to.
For a broader look at when shared hosting stops being the right fit, this post on upgrading your hosting plan covers the signals worth paying attention to, and the guide to securing your VPS is worth reading before you start deploying services on one.
If you are running n8n at low workflow volumes and can tolerate an occasional missed schedule, a shared account may genuinely be enough, and it costs nothing to find out. The moment any of this becomes something you depend on, the constraint stops being memory or ports and becomes trust: a process that can be killed for looking idle is not somewhere to put work that has to happen. That is the point at which UWH VPS hosting stops being an upgrade and starts being the correct tool.
