Running Node.js apps like n8n on shared hosting: what to expect

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: 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.

What these tools have in common

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, not as 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 maintains persistent connections to messaging platforms, 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 to Anthropic’s infrastructure.

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. These limits exist to protect other customers on the same server. Tools like n8n and OpenClaw routinely push against them during active use, and the OS will kill processes that exceed the allocation.

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. Shared hosting does not allow arbitrary port binding for individual accounts.

What you can realistically expect from each tool

The situation is not identical across all three tools. Each one has a different relationship with the shared hosting environment.

n8n can be made to work on shared hosting with significant effort. Version 1.x runs as a single process and fits within shared hosting constraints reasonably well. Version 2.x is harder: it runs multiple processes, uses more memory and requires workarounds to get the interface loading correctly. Core functionality works, but advanced features like the Code node do not. Reliability depends on cron-based process resurrection rather than proper process management, so if the process goes down between cron runs, scheduled workflows do not fire.

OpenClaw follows a similar pattern. It is installable with effort and functional for basic use, but the 24/7 availability it is designed around is not something shared hosting can reliably provide. If the process goes down between cron runs, messages are missed and scheduled tasks do not fire.

Claude Code is a different case. It is an interactive terminal tool, not a web app, and there is no practical way to run it as a Passenger-managed Node.js application. It can be installed on an account with SSH access, but the environment it needs, including a persistent shell, outbound API connectivity and adequate resources, 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 full root access, no shared resource limits and complete control over what runs and how. For these tools, that changes the picture entirely.

Your allocated RAM and CPU are yours, not shared with other accounts. 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 by Passenger. You can also run n8n and OpenClaw in isolated Docker containers using 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 are designed to. If you are considering that move, the guide to securing your VPS is worth reading before you start deploying services.

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.

If you are already on shared hosting and want to try running one of these tools, the shared hosting path is worth attempting first. You may find it meets your needs, particularly for n8n at lower workflow volumes. If you need something that runs reliably around the clock, a VPS is the right environment.

Take a look at UWH VPS hosting plans if you are ready to move to an environment where these tools can run properly.

If you are unsure which option fits your situation, the UWH support team can help you work through it.