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

See the plans

Container websites

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 UHost 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 UHost does not ship, a system library an application needs, a service with its own base image. You supply the image; UHost supplies the domain, the certificate and the isolation.

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 uses Approve an image, and each entry needs an explicit tag — not latest — so the version that runs cannot change underneath you. A rebuild upstream does not silently become a deployment here.

This is an administrator's job rather than a customer's on purpose. An image is code running on the machine, so the list of what may run is a decision for whoever owns the server.

What a container may do

Less than you might expect, deliberately.

A container runs as the website's own account with no privileges, a read-only root filesystem, and its memory, CPU and process limits enforced by Docker. It reaches the network only through the web server — it cannot open arbitrary outbound connections, and nothing publishes it directly.

So an image that expects to write across its filesystem, install packages at boot, or bind a public port will need adjusting. That is the trade for running somebody else's image next to other people's websites.

The thing that surprises people

Only /data survives a restart.

Anything a container writes outside /data is lost when it restarts, and saving a change replaces the running container. Uploads, generated files, a SQLite database, a cache you would rather keep — all of it belongs under /data or it is gone the next time the container starts.

This 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.

Configuration

Environment variables, edited as lines.

Container environment variables are edited as the lines they become, one NAME=value per line, so what you see is what the container is given. A database made for the website is reached the same way as from any other runtime: create one and pass its credentials in as environment variables.

All guides