Roles
Admin and member, and where the line between them is drawn.
There are two roles and no organizations: Cubeship runs one instance on one VPS, and a tenant boundary inside it was a level everybody had to name and nobody could use. The role is a column on the account.
Member
Deploys published images, writes variables, places and scales apps, reads everything about what the instance runs — charts, logs, the list of databases and what is attached where. A CI job's key is a member's.
Admin
Everything a member does, and:
- builds source on this host — creating, deploying and writing the environment of an app whose source is a repository, because a build executes whatever the repository contains with the builder's privileges;
- configures the instance — projects and environments, databases and stores and what is inside them, registries, DNS, credentials, the firewall, servers, settings, users;
- reads data — a bucket's files, a database's credentials, a backup.
Why those two lines
Executing source is a different kind of act from running a published artifact: a member who could point a building app at a repository would be running arbitrary code on the box.
Reading data is the other. Cubeship lets a member read a great deal about what the instance is wired to and never lets one read a row of a database or a file in a bucket — an app they deploy still uses both, because the app is given the keys.
Access roles
Every account holds a role: a named list of grants, given on Users. Three ship with the instance and cannot be changed or deleted:
| Role | What it is |
|---|---|
| Admin | Everything above, users and roles included. |
| Deploy | What a member always did: apps managed with their variables, projects read, and domains, databases, object storage, servers, templates and this instance's registry read. |
| Read only | Every resource read, nothing changed, no secret. |
Any other role is made on Users → Access roles. Each grant is one kind of resource — projects, apps, domains, databases, object storage, servers, templates, backups, the registries, git and DNS providers, credentials, certificates, the firewall, settings, the audit log — and says:
| Level | none, view or manage. |
| Secrets | Whether it reads what somebody set: variables, credentials, files in a bucket, backup downloads. |
| Shell | On apps only: whether it opens a shell inside their containers. Needs manage, and is never implied by the others. |
| Which | For projects, apps, domains, databases and object storage: every one, or only those named. One outside the list is not there — it answers as not found. |
Users and roles are an admin's whatever a role says — whoever can shape access can give themselves all of it — and so are building source and a root shell on a machine. A role still held by somebody cannot be deleted.
cubeship role listWhat a key inherits
An API key has its owner's access. Given a role, it has that role narrowed by its owner's — never more than the owner reaches, and over MCP it is not offered a tool its access would refuse. Give an agent a key with a role unless it has business doing everything you can. See API keys.