Can You Run n8n on Shared Hosting? No — Even the Node.js Kind

No. n8n is a long-running process that must stay resident to fire schedules and receive webhooks. Shared hosting starts your code when a request arrives and stops it when the response is sent — that’s the entire architecture, and it’s incompatible with what n8n is.

The interesting part is that Node.js support doesn’t rescue it, which is where most people get stuck.

Why Node.js support isn’t the answer

Plenty of shared hosts do offer Node.js, and it’s reasonable to assume that settles it. It doesn’t.

Shared hosting runs Node the same way it runs PHP: per request. A process spins up to handle an incoming HTTP request, returns a response, and is reaped. Some hosts keep a worker warm for a few seconds. None of them let you run a daemon that stays up for weeks.

n8n needs exactly that, for two reasons:

Schedules. A workflow set to run at 3am requires something awake at 3am. With no resident process there is nothing to fire the trigger — and no request arrives to wake it, because the trigger is the event.

Webhooks. n8n’s core use is receiving calls from other services. That needs a listener bound to a port, holding a public HTTPS endpoint continuously.

The other blockers, any one of which is sufficient on its own:

• No port binding. n8n listens on a port (5678 by default). Shared accounts don’t get to bind ports; the provider’s web server owns them.
• Background processes get killed. Shared hosts actively reap long-running user processes, because one tenant hogging CPU degrades everyone on the box.
• Database access is constrained. n8n wants Postgres or SQLite with persistent connections and write access to its own store — not a per-request MySQL connection with a query cap.
• You don’t choose the Node version. n8n pins its supported range; shared hosting gives you what the provider installed.

The one-line test: if you can’t SSH in and run something with systemd or Docker that survives your logout, you can’t run n8n. That’s the same structural boundary as Docker, reached by a different route.

The webhook problem that catches people out

This is the one worth reading even if you’ve already accepted the shared-hosting answer, because the usual fallback doesn’t work either.

“I’ll just run it on a Raspberry Pi at home.” For scheduled workflows that only make outbound calls, that’s fine.

For webhooks it isn’t, because a service like Stripe or GitHub has to reach your n8n. A device behind a home router has a private address and no inbound route — the webhook has nowhere to arrive. And most residential connections give you a dynamic IP that changes, with inbound ports commonly blocked by the ISP.

The workarounds are real but they’re infrastructure, not a shortcut: a tunnelling service that gives you a public HTTPS endpoint mapped to the local instance. That works, it’s what tunnels are for, and it adds a dependency your automation now relies on.

So the honest framing: if every workflow you’ll ever run is outbound and scheduled, a Pi is a legitimate free option. The moment one workflow needs a webhook, you need a public endpoint — and at that point a small VPS is simpler than a tunnel plus a Pi.

Three options that actually work

Ranked by effort, with real monthly costs.

1. A small VPS with Docker Compose

The cheapest and the most control. n8n plus Postgres in a Compose file on a 2–4GB box.

Budget 2GB minimum and 4GB if you’ll add community nodes, which are the usual cause of memory pressure. The Compose setup is documented and takes an evening the first time.

The cost you’re not paying in money you’re paying in responsibility: patching, backups and being the person who notices when it stops.

2. A PaaS with a persistent service

Deploy from a repo, no server to manage. The caveat is specific and it bites n8n harder than most apps.

Railway bills per second of resource time — and n8n is resident by definition, holding schedules and a webhook listener around the clock. You’re billed for residency rather than for work done, so an idle n8n costs nearly the same as a busy one. We priced that against a flat VPS, and the convenience is real but so is the premium.

Also check the platform’s sleep behaviour. Anything that idles containers to save resources will break scheduled triggers, and it does so silently — the workflow simply doesn’t run.

3. n8n Cloud

No server at all. n8n’s own tiers run €20/month for 2,500 executions (Starter) and €50 for 10,000 (Pro), with Enterprise far above.

Against a $8.97 VPS that’s well over twice the hosting cost — but it includes the maintenance, the upgrades and the uptime that you’d otherwise own. We mapped where the break-even sits, and it’s a curve rather than a number, because Cloud prices per execution while a VPS is flat.

The rule of thumb: Cloud wins at low volume or when your time is worth more than $20/month. Self-hosting wins as executions grow, and wins by a lot at high volume.

What to buy

Hostinger — the low-effort self-hosted route, at $6.49 promotional and $11.99 renewal for 4GB, with a one-click n8n template that skips the Compose file entirely. This is the direct answer for most people moving off shared hosting — the 4GB tier gives room for community nodes, and the template removes the install step where first attempts usually fail.

Hetzner — German company and data centres if jurisdiction matters. Check the price before assuming it’s cheap: its 2GB CPX11 is €11.99 and the cheap tier has been unavailable since the 2026 repricing.

DigitalOcean — $24 for 4GB, dearer than the rest, bought for documentation and predictable APIs. Good if you’re learning the stack rather than just running it.

Railway — the no-server option, with the residency billing caveat above. Genuinely fast to deploy; check the numbers against a flat VPS before committing to an always-on workload.

Cloudways — managed hosting on top of DigitalOcean, AWS or Google Cloud from $11 for 2GB, billed monthly with no term. A reasonable middle if you want someone else patching the server but still want a real server.

For the fuller comparison, the best VPS for n8n covers the tiers, and what n8n actually costs to self-host has the figures including the database.

How we checked this

The architectural argument is about how shared hosting works rather than a test we ran. Shared accounts execute code per request and reap long-running user processes; n8n requires a resident daemon holding schedules and a bound port. We have not attempted an n8n install on a shared account, because the conclusion follows from the model — without a persistent process and a bound port there is no mechanism for a scheduled trigger to fire or a webhook to arrive.

The specific blockers — port binding, background process reaping, constrained database access and pinned Node versions — are the standard constraints of shared hosting rather than provider-specific findings, and we have not audited any named shared host against them. The one-line test in that section is what we’d apply.

The webhook and NAT point is a property of home networks rather than something we measured: a device on a private address has no inbound route without a tunnel or port forwarding, and residential connections commonly use dynamic addressing with inbound ports blocked. We haven’t tested any specific tunnelling service with n8n.

Pricing is from our research across this series in August 2026: Cloudzy at $8.97 for 2GB, Hostinger’s KVM 1 at $6.49 promotional and $11.99 renewal with the VPS rates verified live on 17 August 2026, Hetzner’s CPX11 at €11.99 converted at approximately 1.08, DigitalOcean at $24 and Cloudways from $11. n8n Cloud’s tiers of €20 for 2,500 executions and €50 for 10,000 are the figures established in our cloud-versus-self-hosted analysis, and Railway’s per-second residency billing in our Railway comparison.

The 2GB minimum and 4GB recommendation reflect the RAM figures used across our n8n coverage, driven by community nodes rather than n8n’s base footprint. We have not measured n8n’s resident memory ourselves.

What we did not do: install n8n on any platform for this article, test a tunnelled home deployment, or verify n8n Cloud’s current pricing directly.

The host links above are affiliate links. The article’s third option is n8n’s own Cloud product, which we don’t earn from — and it’s the right answer for low-volume users whose time is worth more than the difference.

FAQ

Can I run n8n on shared hosting?

No. n8n needs a process that stays resident to fire schedules and hold a webhook listener, and shared hosting runs code per request and reaps long-running processes.

What if my shared host supports Node.js?

It still won’t work. Shared hosts run Node per request in the same way they run PHP — there’s no facility for a daemon that survives your logout, which is what n8n requires.

Can I run n8n on a Raspberry Pi instead?

For scheduled, outbound-only workflows, yes. For webhooks, no — a device behind a home router has no inbound route, so the webhook can’t reach it without a tunnelling service providing a public HTTPS endpoint.

What’s the cheapest way to self-host n8n?

A 2GB VPS with n8n and Postgres in Docker Compose, from about $8.97/month. Budget 4GB if you’ll install community nodes, which are the usual cause of memory pressure.

Is n8n Cloud cheaper than self-hosting?

At low volume, effectively yes once your time counts — its Starter tier is €20/month for 2,500 executions against roughly $9 for a VPS you maintain yourself. Self-hosting wins as execution volume grows.

Why is a PaaS expensive for n8n specifically?

Because platforms like Railway bill for resource residency, and n8n is resident by definition — holding schedules and a webhook listener around the clock. An idle instance costs nearly what a busy one does.

What’s the simplest working setup?

A 4GB VPS with a one-click n8n template. It avoids both the Compose file and the shared-hosting dead end, and leaves headroom for community nodes.