Core concepts
Eight words carry the whole model. Everything else in these docs is built out of them.
Tenant
Section titled “Tenant”A tenant is a tenant: one organisation’s users, jobs, queues, storage and nodes, sealed off from every other tenant. Your account belongs to exactly one.
You sign in as you@yourdomain and land in your tenant without choosing it.
Tenants do not see each other. A superadmin is the only
role that spans them, and even then they have to deliberately enter a tenant to
work inside it.
A node is a machine that can run containers. It joined the tenant by accepting a node invite, and it keeps an outbound tunnel open to the central server - so a node behind a firewall works fine, as long as it can reach out.
A node is either online or not. Offline nodes cannot take jobs, which is the single most common reason a queue looks empty.
A queue is the thing you submit to. It holds a set of nodes and decides:
- which nodes your job may land on,
- how much GPU, CPU and memory you may ask for,
- whether jobs on it are interactive, non-interactive, or both,
- which storage is reachable from it,
- what it costs.
Access is granted per user group, not per user. If you cannot see a queue, your group has not been given it.
Job and service
Section titled “Job and service”A job is what you submit. A service is one container inside it.
Most jobs have exactly one service, and the distinction never comes up. It starts to matter when you run several containers that need to talk to each other - a model server and a web front end, say. Then one job holds two services, they are scheduled together, they share a runtime, and each reaches the other by its hostname.
In the jobs table you see one row per job. Expand it to see its services. Selecting a service opens the detail panel; clicking the job row only expands it. That trips people up once.
A token is the unit of billing. A running job spends tokens per minute, scaled by how much GPU, CPU and memory it holds and by the queue’s own cost settings. There is also a small fixed charge for starting a job, and storage is billed per terabyte-hour.
Tokens are not a currency you can lose track of quietly: the submission form shows the estimated cost before you commit, and the Tokens page lists every charge against every job.
Project
Section titled “Project”A project is a shared token budget. Charge a job to a project and the project’s balance pays for it instead of yours.
Tenants can require that every job names a project, which is how an administrator makes cost attribution mandatory rather than polite.
Storage bucket
Section titled “Storage bucket”A bucket is a folder you can mount into a container. It lives on a storage, which lives on a node or on shared infrastructure.
Two rules follow from that, and they explain most storage confusion:
- A bucket is only mountable from a queue that can reach its storage. The Files page lists every bucket you can read. The job form lists only the ones the selected queue can mount. Those are different lists, on purpose.
- Anything not on a mount is temporary. The container’s own filesystem is destroyed with the container.
Putting it together
Section titled “Putting it together”You belong to a tenant. Your group grants you a queue. You submit a job of one or more services to it, mounting a bucket so your results survive, and the minutes are charged in tokens to you or to a project. The scheduler places it on an online node in that queue.
That is the whole thing. The glossary has the smaller words - booked, interactive, relay, tenant admin - in one list.