Public launch 13 October 2026. Every plan opens that day.

See the plans

Every website declares its runtime, and gets only what it needs

A website runtime is what answers a request: files on disk, PHP, a Node.js application, a container, or a name that forwards somewhere else. Dashmox asks when you create a website, and gives it exactly that and nothing more.

The part in front is the same for every website. What differs is the one line behind it, and that line is written from the runtime you chose.

The five

What a website can be.

Chosen when the website is created, and changeable afterwards without rebuilding anything.

Static files

The website serves what you upload and nothing runs on the server. Nothing to keep running, nothing to update, nothing to be compromised.

PHP

The only runtime that comes with a database, the one-click installer and a choice of extensions. WordPress, Joomla, Laravel and anything else in PHP. PHP settings

A Node.js application

A program of your own, started, supervised and restarted by the server, with your certificate in front of it. Node.js hosting

A container

An image an administrator has approved, run with no privileges and a read-only root filesystem. Docker hosting

Forward somewhere else

The name answers here and every request is passed to an address you give. Administrators only. Reverse proxy

Why ask at all

Because a server that guesses runs more than it has to.

The usual arrangement is that every website is a PHP website, whether or not it has ever contained a line of PHP.

That is a reasonable default and an expensive one. The PHP processes exist for a site that is three hundred HTML files. The interpreter is reachable at any path that ends in .php, on a website that has none. The settings pages offer versions and extensions for something that does not run. None of it is doing harm on the day you set it up, and all of it is surface that nobody is watching.

Saying what a website runs turns that around. The question is asked once, in the form where you are already naming the site, and everything downstream follows from the answer.

  • A static website has no PHP service at all. Not a disabled one: there is no pool, no socket and no .php handler written into its configuration. The one line behind it is try_files, which serves a file or answers 404.
  • A PHP website gets a pool of its own, running as that website's Linux account, reachable on a socket of its own. Its memory limit, its upload size, its execution time and its version belong to it, and raising one for a demanding application raises it for that application.
  • An application runtime is supervised rather than hoped for. A Node.js application or a container is started by the server, restarted if it exits, and started again after a reboot. Nothing depends on somebody having left a terminal open.
  • The panel offers the right pages and hides the wrong ones. The installer and the extensions page belong to PHP websites. A website changed away from PHP loses those two pages and nothing else: it keeps its files, its domains, its certificate, its mail and its backups.
  • The limits are enforced where the runtime is. CPU, memory and process limits are applied to the thing that actually runs, so a busy website is bounded rather than noisy.

The result is that the attack surface of a website is the surface of what it does. A static marketing site on a Dashmox server is a directory and a web server, and the long tail of PHP vulnerabilities is not a thing that can happen to it, because the interpreter was never put in front of it.

Changing your mind

A runtime is a setting, not a rebuild.

Open the website, choose a different runtime, press Apply runtime. It is the same website with a different engine behind it: the domains stay, the certificate stays, the files stay where they are, the mailboxes are untouched, the backups still restore.

That matters more than it sounds, because the alternative is what people actually do, which is to create a second website, copy everything into it, move the domain, reissue the certificate and hope they have not forgotten the DNS. A setting you can change is a setting you will change when the application changes. A setting you cannot is a reason to leave a static site on PHP forever.

One rule: a website has to be finished and well before its runtime changes. A site still being created, or sitting in an error, is asked to settle first, because changing what runs underneath a half built website is how you get a website that is neither thing.

What is the same whatever you choose

The parts in front of your application.

  • Its own Linux account. Every website runs as a user of its own and cannot read another website's files, whichever runtime it uses.
  • Its domains and a free certificate. nginx holds the names and the Let's Encrypt certificate and renews it. Your application never learns what TLS is.
  • Mail, DNS, backups and scheduled tasks. None of these care what the website runs. A Node.js application can have mailboxes on its domain and a nightly backup, like any other site.
  • The same isolation. The protections on the security page apply to every runtime, and the ones specific to PHP, such as turning off the functions a web shell needs, simply do not arise where there is no PHP.

Every feature

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.