Organisations and projects
Organisations
Section titled “Organisations”An organisation (org) is the tenant boundary. It has a unique slug, a plan, and settings such as SSO enforcement, allowed email domains, an IP allowlist, token policies, runner pools and retention.
Isolation is enforced in the database: every org-scoped table carries org_id and a Postgres row-level security policy keyed on the caller’s organisation. See Tenant isolation.
The organisation is always taken from your credentials, never from a request body. A person can belong to several organisations and switch between them (slipway org switch <slug>).
Membership, roles and teams
Section titled “Membership, roles and teams”A membership links a user to an org with a role. A team is a named group of members; roles can be bound to a team.
Built-in roles:
| Role | Intent |
|---|---|
owner |
Everything, including deleting the org and changing the plan |
admin |
Manage members, projects, integrations and settings |
developer |
Create and edit pipelines, trigger runs |
deployer |
Deploy and promote to environments they are granted |
viewer |
Read-only |
billing |
Plans, invoices and usage |
Custom roles are available on Team and above. A role is a set of permissions such as pipelines.read, runs.trigger, deployments.approve or environments.deploy:<env>. A role binding attaches a role to a subject (user, team or service account) at a scope: org, project or environment. That scoping is how you give a team deploy:production on one project only. See Access control.
Projects
Section titled “Projects”A project lives under an org, with a slug unique within the org. It holds:
- linked repositories (through SCM connections),
- pipelines, services and environments,
- a default runner pool,
- project-scoped secrets and variables.
Environments and permissions are the main reason to split projects. A typical split is one project per product or deployable system, not per repository.
Non-human principals
Section titled “Non-human principals”- Service accounts are owned by the org and have their own role bindings. Use them for automation.
- API tokens are personal access tokens or service-account tokens: prefix
sk_live_, hashed at rest, scoped to permissions, with an expiry. - Job tokens are short-lived OIDC JWTs issued to a running job. They are never stored. See OIDC job tokens.