Docker hosting for the applications your panel does not ship
A container website runs an image an administrator has approved, as the website's own account, with no privileges and a read-only root filesystem. It is how you host something written in a language this server does not install.
When to reach for one
When the runtime you need is not on the menu.
Static, PHP and Node.js cover most of what people host, and they need no image and no approval. A container website is for the rest: a language this server does not ship, a system library an application needs, a service that arrives as its own base image.
It is also the answer to "can I run this one thing" without turning the server into a machine that runs anything. The list of what may run is a list, and somebody decided what is on it.
Approving an image
An administrator adds it, with an explicit tag.
Nothing can run as a container website until an image is added. Under Container images an administrator approves one, and each entry needs an explicit tag, never latest, so the version that runs cannot change underneath you. A rebuild upstream does not silently become a deployment here.
That is an administrator's job rather than a customer's on purpose. An image is code running on the machine, so what may run is a decision for whoever owns the server, and a free text field would make it a decision for whoever has an account on it.
What a container may do
Less than you might expect, deliberately.
- No privileges, and a read-only root filesystem. An image that expects to install packages at boot or write across its filesystem will need adjusting.
- Its memory, CPU and process limits are enforced by Docker, from the same allowance the website has.
- It reaches the network through the web server only, on a port of its own. Nothing publishes it directly.
- It runs as the website's own account, like every other runtime here, so the walls between websites are the same walls.
- Only
/datasurvives a restart. Uploads, generated files, a SQLite database, a cache worth keeping: all of it belongs under/data.
That last one catches people who have run the same image elsewhere without thinking about it, because a long-lived container hides the problem until something restarts it. Treat the container as disposable and /data as the only floor you can stand on. Saving a change replaces the running container, so the rule applies on an ordinary afternoon and not only after a crash.
Everything else is the same website
A container site is a website, not an exception.
It has a domain and a free certificate. It can have mailboxes, DNS records, scheduled tasks and backups. Environment variables are edited as the lines they become, one name and value per line, so what you see is what the container is given, and a database made for the website is reached the same way as from any other runtime.
And it is a runtime like the others: a website can be moved to it and away from it without being rebuilt, keeping its files, its names and its certificate.
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.