Control panel security built so one website cannot reach the next
Somewhere on a busy server, a website will run an outdated plugin. Good control panel security decides what happens next. Dashmox is built so the answer is: very little.
How it is put together
The panel you sign in to has no root.
Dashmox is two programs. The panel, which answers your browser, runs as an ordinary unprivileged account. Anything that needs root is asked of a separate agent.
- The agent listens only on a restricted local socket, never on the network.
- It accepts a fixed list of typed operations, and never a shell command it was handed.
- It works out every path and Linux account itself from an internal identifier, so a request cannot point it somewhere else.
- Every request is authorised on the panel against the resource it touches.
- Your browser reaches it on the panel's own port, never the one your customers' websites answer on.
Every website
Protection that is on before you think to turn it on.
Its own account
Each website runs as its own Linux user with its own PHP pool and socket, and cannot read another website's files.
Mail kept apart
Mail is stored under a dedicated account outside the website, so a compromised website cannot read its customer's mailboxes.
No scripts from uploads
Nothing runs from a folder an application writes to, so an uploaded file cannot become a program.
PHP cannot run commands
The functions a web shell needs are switched off, which is what most compromised websites are used for.
Scanners turned away
The paths vulnerability scanners ask for, and files that are never web content, are refused outright.
Password guessing slowed
Repeated sign-in attempts against a website's login pages are rate limited, per website.
Unknown names refused
A name this server does not hold a certificate for is refused as the secure connection is set up, rather than being answered by whichever website came first.
You and your customers
Signing in, and staying in control.
Two-factor sign-in
Codes from any authenticator app. Scan a code to set it up, or type the key by hand. Single-use recovery codes, stored only as hashes.
Strong password storage
Passwords are hashed with Argon2id. There is no default password: the first account is created with a single-use token.
Rules for the whole server
Set password and sign-in requirements for everybody who signs in to your server.
A firewall that will not lock you out
A rule that would cut off the address you are connecting from is refused by name, and the ports the server must answer on are kept open.
Signed updates
An update is refused unless Dashmox signed it. It installs when you press the button, snapshots the panel first, and tries to put everything back if it fails.
Your hosting outlives your licence
A licence that runs out puts the server on the free plan. It never takes a website, mailbox or zone offline.
What this is for
The attack this is built around.
Not somebody breaking into your server. Somebody breaking into a website on it.
A hosting server is a machine running code that other people wrote, updated on other people's schedules. A plugin goes a year without an update. A theme has a file upload nobody tested. A password is reused. None of that is unusual and none of it is your fault, and on a busy server it is a question of when rather than whether.
So the useful question is not how to stop it. It is what an attacker holds once it has happened. They are running code as that website: reading its files, writing to its folders, opening connections. Everything after that depends on what the machine lets that account touch.
Three answers matter, and Dashmox is built so that all three are no.
- Can it read another customer's websites, mail or backups? Each website is its own Linux account with its own PHP service and socket. Another customer's files are not readable by it, and neither are their mailboxes, their database credentials or their TLS private keys.
- Can it reach something that runs as root? The panel you sign in to has no root at all. The one program that does listens on a local socket a website's account cannot open.
- Can it become root? The directories that would give it away, the ones holding web server configuration and system services, are not writable by it.
Those are not arguments. On 29 September 2026, on a server running release 0.97.128 and hosting thirty five websites, fifteen probes were run from one website's own Linux account against another's: the registry mapping every account, the privileged socket, the DNS control key, the backup credentials, another customer's backups, container environment files, another customer's TLS private keys and mail, the panel's own configuration, the system password file, another customer's home directory, and two attempts to write into the web server's and the service manager's directories. All fifteen were refused. The run checks first that the account could read its own document root, because a probe run as the wrong account is denied everything and proves nothing.
The privileged half
What the root program will actually do.
It answers a list of named jobs. There is no entry on that list for running a command.
Splitting a panel in two only helps if the privileged half is narrow. A root program that accepts "run this" is a panel with root, with an extra step.
Dashmox's agent accepts 136 named operations and nothing else. Each is a job with a shape: create this website, issue a certificate for it, write this DNS record, restore this backup. A request naming anything not on the list is refused before it is read.
- It takes identifiers, not paths. A request names a website by its internal identifier and the agent works out the directory and the Linux account itself. There is no field in which to send a path, so there is nothing to point somewhere else.
- It never receives a command line. Where it has to run a program it builds the arguments itself from values it has already checked.
- It listens on a local socket only, owned by root, in a directory a website's account cannot enter. It is not on the network at any address.
- The panel authorises first. Every request is checked against the person making it and the thing it touches before the agent is asked at all.
The number is worth stating plainly because it is the honest measure of the boundary. A smaller list would be a smaller panel. What matters is that the list exists, that every entry is a job rather than an instruction, and that adding to it is a change somebody has to make on purpose.
Updates
An update has to prove it came from us.
An update is the most dangerous thing a panel does, because it is the one moment the machine willingly replaces its own code. A panel that installs whatever it is handed has a back door with a progress bar.
- The signature is checked over the archive itself, not over a description of it. A signature on a list of checksums is only as good as the link between the list and the bytes, so Dashmox signs the bytes.
- Against a key built into the release you are already running. The key is not fetched, so a service that had been taken over could stop answering and could not sign anything your server would accept.
- Nothing installs itself. The panel says an update is available. An administrator presses the button. That is the whole of it, on every plan, including the free one.
- It snapshots before it starts, and puts the previous release, its configuration and its database back if the new one does not come up healthy. A failed update does not consume its version number: the corrected build installs under the same one.
- A damaged release is refused rather than repaired around. If a file inside the installed release does not match what the release vouches for, the panel says so, names the file, and tells you which archive to supply.
Security fixes are not a paid feature. Every installation is offered every release whatever plan it is on.
Being honest about it
What this does not protect you from.
A security page that only lists strengths is an advertisement. These are the limits, in the same words we use internally.
- A compromised website is still compromised. Nothing here saves the site that ran the outdated plugin. Its files, its database and its visitors' sessions belong to whoever got in. What is bounded is how far that reaches.
- Root is root. Anybody who signs in to your server as root, or who holds a key that does, is past all of this. So is anybody holding the owner account with its second factor.
- Your provider is underneath you. Whoever runs the hardware or the hypervisor can reach the disk. That is true of every panel on every host.
- We do not patch the applications you install. Dashmox tells you when one has an update and installs it when you say so. Keeping them current is yours.
- Email is the usual caveat. Mail is stored apart from the website and sent over TLS, and a message in transit between two other servers is not ours to protect.
The comparison worth drawing is not with any particular product. It is with the shape: a panel whose web interface runs as root has no boundary to describe, because a flaw anywhere in it is a flaw with root. That is the arrangement Dashmox exists to avoid, and the reason the answer to "what can a compromised website reach" is a list of refusals rather than a reassurance.
Your servers, with nothing on them counted.
The whole panel is free on one server, with no limit on websites, mailboxes, DNS zones or customer accounts. Pro carries five servers and Business as many as you run.