Node.js hosting on your own server, supervised by the panel
Choose the Node.js application runtime and your program becomes a website: started on boot, restarted when it exits, with its domain, its certificate and its dependencies handled for it.
What the panel does for it
The parts of Node.js hosting nobody enjoys.
Kept running
Started when you apply it, started again after a reboot, and restarted if it exits: a crash, an unhandled rejection, an out-of-memory kill.
Dependencies installed
Install from the panel and it runs npm as the website's own account, using your lock file when there is one, so the versions that install are the versions you committed.
Stop and restart
Deploying new code is a button. So is stopping an application that is misbehaving while you work out why.
Environment variables
Edited as the lines they become, one name and value per line. Your database credentials and your API keys go here rather than into the repository.
Your certificate, free
The domain and its Let's Encrypt certificate belong to nginx. Renewal is not your application's problem and never was.
Watched
Runtime monitoring samples the application once a minute and keeps seven days, so "it was slow last Tuesday" is a question with an answer.
The one rule
Listen on the port you are given.
Your application must listen on the port the panel assigns it, on loopback. An application hard-coded to port 3000 will not be reached. Read the port from the environment, which is what every deployment guide already tells you to do, and the same code runs here and everywhere else.
In exchange, nothing about certificates, virtual hosts or ports in the firewall is yours to think about. WebSockets work: the upgrade is passed through and the connection kept open, so an application that upgrades a request behaves as it would anywhere.
Node.js 20, 22 and 24 are the versions a server can offer, and the version is chosen per website rather than for the machine. Two applications on one server can want different majors.
What it can reach
Its own website, as its own account.
A Node.js application runs as the website's own Unix account, inside the website's directory, exactly as a PHP site does. It reads and writes its own files and reaches its own database. It cannot read another website's files, and the account has no shell.
A database is made the same way as for any other website: create one with its own account and pass the credentials in as environment variables. Mail, DNS, scheduled tasks and backups all work on a Node.js website, because none of them care what the site runs.
If you need more than that, because of a language or a system library this server does not install, a container website runs an image of your own instead. That is a different runtime with different trade-offs, and it needs an administrator to approve the image first.
Being honest about it
What supervision is not.
Restarting a process that exits buys time, not correctness. An application that crashes on every request restarts on every request, and the website is still down. What it prevents is the other case, the one that actually happens: a single bad request at two in the morning taking the site off the air until somebody notices in the morning.
And a Node.js application shares the machine with every other website on it. The isolation is the Linux account and the limits on the service, which is the same isolation a PHP site has and is described in full. It is not a virtual machine, and nothing on this site will tell you it is.
Your servers, with nothing on them counted.
Dashmox launches 13 October 2026: the whole panel free on one server, and Pro for up to five. Neither counts websites, mailboxes, DNS zones or customer accounts.