Node.js Hosting Built for Developers

Pick the Node.js version your application needs and switch it from the control panel. LTS releases such as 18 and 20 sit alongside newer current builds, so a dependency that requires a newer runtime — or a legacy package that breaks on one — stops being a support ticket and becomes a choice you make yourself.

Nothing upgrades underneath you. Your app stays on the version you selected until you decide to move, so the usual pattern is to bump the version, restart, and watch the logs. If something in your dependency tree is not ready yet, switching back takes the same few seconds.

A Node process that exits takes your site with it. PM2 is available on every Node plan and handles exactly that: it restarts your application after an uncaught exception, brings it back after a server reboot, and keeps it running once your SSH session closes.

It also gives you somewhere to look when things go wrong. Process status, memory use and the stdout and stderr logs are reachable over SSH, so a crash loop is something you read rather than guess at. For CPU-heavy work, PM2 cluster mode spreads requests across several workers.

Database passwords, API keys and third-party tokens do not belong in your repository. Custom environment variables are set per application from the panel, injected into the process at startup, and read through process.env exactly the way they are in local development.

Keeping configuration outside the codebase also makes the same build portable. A staging copy and the live one can run identical code against different values — staging sites are included on every shared plan — and rotating a leaked key becomes editing one variable and restarting the process instead of pushing a commit.

Most Node applications need somewhere to keep state. MariaDB databases can be created and managed directly from the hosting panel, which is the shortest path if you are working through an SQL layer such as Prisma, Sequelize or Knex.

You are not limited to that. An application can just as easily talk to a database you run somewhere else — MongoDB, PostgreSQL or a hosted service — as long as it is reachable over the network. Whichever you pick, the connection string belongs in an environment variable rather than in your code.

Chat, live dashboards, shared game state and notification feeds all depend on a connection that stays open. WebSocket connections are supported, so Socket.IO, ws and the frameworks built on top of them work without a workaround and without falling back to polling.

Long-lived connections do change how you size an application. Every open socket holds memory for as long as it lives, so an app with thousands of concurrent listeners is measured in connections rather than in requests per second — useful to know before a launch instead of during one.

Connect GitHub, GitLab or Bitbucket and every push can deploy automatically, which is the workflow most teams want. If you would rather stay manual, SFTP and the built-in file manager both work, and SSH access lets you run npm or Yarn on the server itself.

Applications with a build step — a Next.js production build, a TypeScript compile, a bundler pass — run it before the process starts, either on the server over SSH or in your own pipeline with the output uploaded. Then you set the startup command and the app is live.