Skip to main content
Every server, site, database, credential and token belongs to an organization. You get a personal one when you sign up; create more when a set of machines has a different set of people around it. Switching organization changes what the whole panel is about, including the command palette and the notification bell.

​
Roles

Five, and they nest: each one has everything the role below it has, and adds to it. Reading needs no permission at all, which is why a viewer is granted none. Two of these deserve saying out loud. Opening a shell is a separate permission from changing a server. A shell is effective root on the machine, so a role can be allowed to configure a server without being handed a terminal on it. Writing a recipe is held higher than running one. A recipe is root code that other people will run across machines they picked from a list, without reading it, so authoring one sits with the organization’s administrators. Running one reaches no further than a shell already does, so developers may.

​
Members and invitations

Invite by email address. An invitation that is never accepted is deleted once it expires, so a member list is people rather than intentions. Somebody’s role decides what the interface offers them, not only what the server accepts: a developer looking at a server’s settings is told plainly that their role does not allow changing it, rather than being shown a form that refuses to save.

​
API tokens act as a person

A token is issued on behalf of whoever created it and can only ever narrow what they could do. A developer’s read-write token still cannot delete a server. See the API.