Running a machine of your own
You rent a server, cut it into containers, and hand them out — that is what this page is for, and it takes you from an empty machine to one container in somebody else's hands. Your own hardware works exactly the same way; a rented one is the usual case, so it is the one this page assumes.
The other side of this — what your tenants see and do — is quick start. Reading it once is the fastest way to understand what you are selling.
1. What has to be reachable
The machine calls the panel and keeps that connection open, so the panel needs no way in at all. Your tenants do:
Three numbers, and your own sshd is already sitting on one of them. Do it in this order:
Open the spare port before you move sshd onto it. The other order locks you out of your own server, and a rented one has no console cable to save you.
Your provider's firewall is what you are opening — a security group, network rules, whatever they call it — and a fresh instance commonly allows nothing but 22. Nothing is forwarded and no router of yours is involved; the machine's public address is already its own.
Moving sshd is the machine's Ports card, not your text editor. Editing the most frightening file on a server, over the connection you are about to change, is how people lose a machine. The card writes the port, checks the configuration before it restarts anything, and leaves the session you are typing in alone. It also knows the two shapes of OpenSSH apart — on Debian 13 and recent Ubuntu systemd holds the socket, and Port in sshd_config does nothing whatsoever, which is the trap that has cost people their remote access.
You do not have to give 22 away: the gateway can sit on another port and your tenants add -p, and the same card offers that. But a tenant who has to remember a port number is a tenant who writes to you about it.
Otherwise the list is short:
The supporting software a container needs is installed for you, every time the machine starts, and the machine's page in the panel says how that went.
2. Nothing to switch on
There is no separate host account and no application to make. Any account can attach a machine, and the same login can hold somebody else's container at the same time:
So the whole of this step is: sign in, and open Machines.
3. Attach the machine
Machines → Add machine, and it is two steps.
The page fills in your panel's own address in both lines, so you copy rather than type. If your panel can be reached at more than one address it asks which one the machine should use and times each from your browser first — your route is not necessarily the machine's.
You should see it appear on its own, within a few seconds of the second command:
Two things to know now rather than later:
4. The settings, one at a time
On the machine's page:
The two numbers that are the whole product
Read that before you price anything. A processor share is a guarantee at the bottom, not a ceiling at the top — so the same container benchmarks twice as fast on a quiet night, and the honest answer to "how fast is this" is the busy one. Memory has no such kindness: at the line, the biggest process in that container is killed.
You do not have to guess how many containers fit. The machine refuses one it has no room for and says so in a sentence, and its page tells you which way the wind is blowing:
The rest of the page, in one line each
One thing worth turning on early is in Advanced: without it, a container's free and top show the whole machine's memory rather than its own. Limits are enforced exactly as sold either way — it only changes what the numbers say — but tenants read those numbers and file support requests about them.
5. Create a container
Who it is for is the choice that decides what happens next:
Pick an image the machine already has and the create downloads nothing and takes seconds — one copy on the machine is shared by every container built from it.
The image row has three tabs. From the market is that shared copy. A reference of your own is anything you have pushed to a registry the machine can reach: the machine downloads it while it builds the container, unpacks it into that container's own disk, and counts the download as that container's traffic — so it needs a disk size. From this host is a file you have copied into the machine's image directory yourself, which costs no traffic at all.
You should see:
Shown once means shown once: the panel does not keep it. If it is lost, reset it from the container's page.
6. Hand it over
Give it away produces a link and a code. Send either:
Nothing changes until they claim it, and you can issue a fresh code from the container's page whenever one runs out. The moment they do claim it, the shell login is rewritten — so your copy stops working, which is the point.
Then send them to quick start. It begins exactly where your share code leaves them.
7. Living with it
Because those last two differ: deleting the containers first is the tidy way to retire a machine. Detaching alone leaves them running on hardware the panel no longer knows about.
Keeping the machine's software current is driven from its page, and a bigger account — more containers than your plan allows — is arranged by message rather than by checkout; the Plans page says how.
8. When something is wrong
| What you see | What it usually is |
|---|---|
| The machine says offline | It cannot reach the panel. Check the machine is on and its outbound connection works; nothing on it needs an open port. |
| A create is refused | The machine has no room in memory or processor for that size, and says which. Sell smaller, or wait for load to drop. |
| A create from the market fails, and creating it again says the name is already used | The machine was still downloading the system when the panel stopped waiting — it finished building the container anyway, and the panel never recorded it. Cache the system first from Images, then create from this host, which downloads nothing. Clear the stray one on the machine itself with hqnode rm <name>. |
| A tenant cannot log in | Their container is stopped, out of time, or paused for traffic — or your provider's firewall is not letting port 22 through. |
| A tenant's name resolves but nothing answers | Either nothing is listening inside their container, or your provider's firewall is not letting ports 80 and 443 through to the machine. |
| Certificates fail for every tenant | The machine's secure door has been moved off its usual port. Requests are refused before the certificate issuer is ever contacted. |
| Containers show the machine's memory, not their own | The option in Advanced is not installed. Containers already running keep the old numbers until they restart. |
| Software missing right after attaching | It installs on its own at every start; the machine's page says what failed and what to run by hand if it cannot. |
Where next
- Quick start — what your tenants do, in order.
- How this works — the short version, for explaining it to somebody.
- Building your own image — offering a system that is not on the published list.