> ## Documentation Index
> Fetch the complete documentation index at: https://docs.shipways.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Organizations, roles and members

> Who is in, and what each of them may do.

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.

| Role          | What it adds                                                                                                    |
| ------------- | --------------------------------------------------------------------------------------------------------------- |
| **Viewer**    | Read-only access to everything in the organization.                                                             |
| **Developer** | Change existing servers and sites, open a shell on a server, deploy, run a saved recipe.                        |
| **Manager**   | Create and delete servers and sites, transfer servers, manage members and invitations, change the organization. |
| **Admin**     | Billing, source control credentials, Composer credentials, writing recipes.                                     |
| **Owner**     | Deleting the organization.                                                                                      |

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](/api).