Skip to main content
.com domains from $2.99 — free WHOIS privacy on every name

Developer Buying Guide

Node.js app hosting — Node.js hosting, chosen by how it behaves when a process dies

The interesting question is not whether Node runs. It is who notices, and how quickly, when it stops.

The short answer

Judge Node hosting on its failure behaviour, not its feature list. Run a conventional application on the Node support built into Business hosting, and move to a VPS with PM2 behind nginx when you want the entire process tree answering to you — the deciding factor is how much of the restart, logging and supervision path you need under your own control.

Below is the working: how this goes wrong in practice, the instrumentation that catches it before a customer does, the platform requirements that follow, and the checks to run on us before any money moves.

By the HostingFast team · Reviewed 24 August 2026

NVMe

Storage on every plan

Free

Domain, first year

99.9%

Uptime target, monitored

Flat

Renewal pricing

Written for people shipping APIs, bots and server-rendered applications, who have already learned that uptime is a property of the supervisor rather than the runtime.

The quality of Node hosting only reveals itself the first time a process exits unexpectedly. Proper supervision restarts it within seconds and records why. An afterthought leaves the port closed until somebody outside the company notices, and by then the log has rotated.

How Node hosting actually fails

An unhandled rejection kills the process. Nothing restarts it. The port stops answering and the health check, if there is one, checks the web server rather than your application, so it keeps reporting green.

Or the process survives but leaks: heap grows steadily across a week, garbage collection pauses lengthen, response times drift upward, and the eventual out-of-memory kill looks like a random outage instead of the end of a slow curve.

Or the runtime moves. An LTS branch goes end of life, the host upgrades the shared interpreter, a native module built against the old ABI stops loading, and the deploy that broke it happened three weeks earlier.

Every one of those is survivable with supervision and logs, and expensive without them.

Instrument it before you need to

Put a route on the application that reports process uptime, resident memory and event-loop lag, and poll it from outside. Event-loop lag above roughly 50 milliseconds under normal load means you are doing synchronous work on the wrong thread, and no amount of extra CPU disguises it for long.

Keep restart counts where you can see them. Under PM2 the restart column is the single most informative number on the dashboard: a steadily climbing count is a crash loop that has been hidden by the very thing meant to protect you.

For memory, take two heap snapshots an hour apart under steady traffic and compare retained size. A leak shows up as growth in one constructor, which is a far more useful answer than a graph that only slopes upward.

The platform requirements those measurements imply

Supervised processes as a first-class feature rather than an interpreter left on the filesystem for you to find.

Control over the runtime version, so an LTS transition is something you schedule rather than something that happens to you.

A sane arrangement for ports and whatever reverse proxy sits in front of them, with TLS terminated somewhere you can configure.

Readable logs and self-service restarts. If restarting your own process requires a support ticket, your mean time to recovery is somebody else's queue length.

Our pick, and the checks to run on us

Overdrive is where this page lands for a standard Express or Next application: Node deployed natively alongside PHP if you need both, SSH from signup, 3.5 cores and 2.5 GB of RAM, PostgreSQL and MySQL, and cron for the scheduled half of the workload.

Move to a VPS when you want PM2, the firewall and the whole process tree under your own root — our KVM range runs from one core upward, with snapshots on demand and DDoS filtering in front.

Before paying, send support a genuinely hard question at an inconvenient hour and judge the reply. Compare the renewal rate with the order rate. Read the refund terms for carve-outs. Look the company up. We would do all four to a supplier and we would rather you did them to us.

A developer working against a hosted server over SSH

Our commercial interest, stated in the body copy

We sell hosting, so treat this page as an argument rather than a survey — an argument built from mechanisms you can verify yourself rather than a ranking somebody paid for.

Mailboxes on your own domain are part of the plan rather than a checkout line item, which matters more than it sounds when your application sends transactional mail.

  • Checks written so you can run them yourself
  • Self-service restarts, no ticket in the path
  • Migration free, so testing costs nothing
  • Renewal billed at the rate you ordered at

Why HostingFast

Standard on every plan

Restarts you perform yourself

Recovery time should be measured in seconds of your own action rather than in somebody else's queue length.

Node, Python and Ruby natively

The Business tier deploys all three alongside PHP, so a polyglot stack does not force a second supplier.

Root when you actually need it

KVM virtual servers from one core upward, with snapshots on demand and DDoS filtering absorbed in front of them.

The Overdrive tier, specified

500 GB of disk, 3.5 cores, 2.5 GB of RAM and the full developer toolbelt at a single published monthly rate.

Support with a real scope

Mailbox setup, DNS records, restores and awkward practical questions — not a reply that says the server is up and closes the ticket.

On the public register

Vitalcare at Home Ltd, registered in England and Wales — a registration number you can check in a minute.

Quick Start

From order to online

  1. 1

    Write the health route first

    Uptime, resident memory and event-loop lag on one endpoint, polled from outside. It costs twenty minutes and it is the only honest source for every argument that follows.

  2. 2

    Establish the failure budget

    Decide how long the application may stay down before it matters. That number, not your request rate, tells you whether managed supervision is enough or you need root.

  3. 3

    Take the renewal rate, not the offer

    Renewal rate times the term, plus anything you would genuinely enable. Introductory pricing never survives that multiplication.

  4. 4

    Kill the process on purpose

    During the refund window, terminate it deliberately and time the recovery. That single test tells you more than every uptime badge on the provider's homepage.

Built In

Loaded onto every plan

  • Node processes supervised, not merely permitted
  • Runtime version selectable, so an LTS change is scheduled
  • SSH from signup with Git already on the path
  • Application logs readable without opening a ticket
  • Restarts performed from your own panel or shell
  • cron available for the scheduled half of the workload
  • NVMe SSD storage on every tier, not only the top one
  • DDoS filtering absorbed out at the network edge
  • Renewal charged at the rate you ordered at
  • In-place upgrades, so growth is not a migration

Frequently Asked

What people ask us most often

How long should a crashed Node process take to come back?

Seconds, and it should be automatic. Under PM2 or an equivalent supervisor a restart is effectively immediate; what varies is how long the application takes to warm up afterwards. Time it deliberately on the plan you are evaluating rather than assuming, because the honest answer is often a lot longer than the marketing implies.

What does event-loop lag tell me that CPU usage does not?

CPU tells you the machine is busy. Event-loop lag tells you your own code is blocking. A server at 30% CPU with 200 milliseconds of lag is doing synchronous JSON parsing or crypto on the main thread, and the fix is a worker thread or a stream — not a larger plan.

Do I need a reverse proxy in front of Node?

In production, yes. It terminates TLS, serves static assets without waking your process, buffers slow clients so a trickling upload cannot occupy a connection you need, and gives you one place to apply rate limits. Node can do all of it, but every request spent on that work is a request not spent on your application.

When is a managed account no longer enough?

When you need to choose your own supervisor, hold sockets open for high websocket concurrency, install system packages, or pin an unusual runtime build. Those four requirements are the honest boundary; below them a managed account is less work for the same result, and above them you want root and a VPS.

Keep reading

  • Website Builder vs WordPress

    Drag-and-drop against a real platform, compared on what you can control afterwards.

  • News Site Hosting

    Publishing under deadline and under load, with the surge behaviour costed.

  • Uptime (Glossary)

    What uptime figures mean in practice, and what they quietly exclude.

  • Node.js Hosting

    Run Node.js apps alongside your sites, with SSH and Git included.

  • VPS Hosting

    KVM virtual servers with root access, snapshots on demand and one flat monthly rate.

Changing hosts? Run through our checklist first.

A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.

You'll get the checklist email, then occasional pointers on keeping a site running fast. Unsubscribe the moment you want out — the privacy policy covers the rest.

Ship it behind a supervisor.

Node supervised, logs readable, restarts in your own hands — on NVMe hardware at a rate that never moves on you.

View Node.js Hosting plans