Node.js hosting, plainly

A Node app needs five things from a host: a process that is kept running and restarted on crash, builds run from the repository against the Node version the app declares, environment variables settable without a shell, worker processes supervised with the same seriousness as the web tier, and logs that survive restarts. Hosts that clear all five are plentiful, and the brand matters less than the comparison pages imply. The decision worth deliberating is the cost shape wrapped around those five, because it decides what a quiet month costs and what a busy one bills.

The five requirements

Supervision is the foundation. node server.js in a terminal is a development habit. In production something has to own that process: start it at boot, restart it when it exits, surface the fact that it restarted. On a raw box that is systemd or a process manager like PM2; on a platform it should simply be true. The honest test is killing the process on purpose and watching what happens. If nothing happens, you have found your next task.

Builds belong at deploy time, on the host. The lockfile is the contract, a clean install against it is the ceremony, and what you are buying is a build that does not depend on the machine that wrote the code. If the host builds from Git against the .nvmrc or engines field, the runtime version stops being a surprise. Uploading a prebuilt folder works, at the price of making your laptop part of the infrastructure.

Environment variables belong in the platform's settings, per environment, with the platform keeping them out of build logs. The alternative is secrets in files inside the repository, and that alternative has a long history of ending badly.

Workers are where casual platforms reveal themselves. Any app with a queue, scheduled jobs or long imports has a second process that matters as much as the web server. Platforms that only model one process per app push that work into cron entries, and cron does not restart itself, does not stream logs anywhere useful, and fails silently on the night you ship a bug. Ask any candidate host directly: where does the worker run, what restarts it, where do its logs go.

Logs have to outlive the process and the box. The terminal gets closed, the crashed container gets replaced, the ephemeral disk goes away with the server. Logs belong somewhere all three failures cannot reach, searchable without SSH, because the first incident always starts with a question about what the process said before it died.

The four options

The per-app PaaS, the shape Heroku made normal, wraps all five requirements in a process manifest and bills per app. It is the least work to operate and the easiest bill to read. The unit price favours a small number of serious apps over a sprawl of small ones.

Managed cloud panels put a control layer over an ordinary cloud server: deploys from Git, supervised processes, provisioned databases, patching and TLS handled, one panel for several servers. This site's production servers run on one, Cloudways. What crosses the boundary between you and the server, and what that costs you in control, is covered in managed cloud hosting for developers.

A raw VPS is the same cloud server without the layer. It has the cheapest ceiling and the largest job description: patching, the reverse proxy, supervision, certificates and backups are all yours. Worth it if operating the box is the point or the habits already exist; expensive otherwise, in the currency you have least of.

Containers move the contract up a level. The image becomes the unit of deploy and the platform question shrinks to running images with logs and a restart policy. You own the runtime again, including its patching. For a first production app this is a destination, with the emphasis on eventually.

The cost shapes

Per-request serverless pricing bills a quiet app at nearly nothing and a busy one unpredictably, and it assumes the app is stateless between requests. Per-app seats simplify the bill and cap each app's ceiling, at a unit price that rewards consolidation. Flat per-server pricing gives you a ceiling and a floor: an idle app pays full price, a busy month costs the same as a quiet one, and what runs on the box becomes a resource decision instead of a line item. Cloudways bills that way, per server at a flat rate; the entry server is $14 a month for 1GB of RAM, 1 vCPU and 25GB of NVMe. Hourly VPS instances are the raw version of the same always-on shape: cheapest ceiling, floor included, hours of your month as the hidden cost.

The five requirements are checkable in an afternoon, and the checklist lives on this site: where to host an AI-built app holds candidates to all five plus rollback, database and idle-cost questions. For what living on a managed panel is like in practice, the Cloudways review is written from running real production sites on it.