Workspaces & roles
A workspace owns everything: its own private network, its instances, and its API tokens. Signing up creates a personal one for you; create more from the workspace switcher when you want to separate a team or a client from your own work.
Members and invitations
Members lists everyone in the workspace. Invite by email and the invitation is sent with a role attached; the recipient accepts it from the link and lands in the workspace. Pending invitations can be revoked from the same page, and you can change or remove a member's role there too.
Membership is per-workspace, so being an owner of one grants nothing in another.
Roles
| Owner | Admin | Developer | Viewer | |
|---|---|---|---|---|
| Create / delete instances | ✓ | ✓ | ✓ | — |
| Start, stop, restart | ✓ | ✓ | ✓ | — |
| Read connection details | ✓ | ✓ | ✓ | ✓ |
| Mint & revoke API tokens | ✓ | ✓ | ✓ | — |
| Networks and domains | ✓ | ✓ | read only | read only |
| Invite & manage members | ✓ | ✓ | — | — |
| Delete the workspace | ✓ | — | — | — |
Developer is the role for people who build: full lifecycle over instances and volumes they create, including deleting them, but no changes to the workspace's shared topology — networks, domains, membership. Viewer reads everything and writes nothing.
These aren't only UI affordances for instances and tokens: the control plane re-resolves your role on every request and rejects the ones your role doesn't carry, so a hidden button can't be worked around by calling the API directly.
Plan and quota
The plan sits on your account, not on each workspace, and grants the quota that instances are carved out of. Usage shows what's allocated against it.
Next steps
- API tokens — a token inherits the resource permissions of the role that minted it
- Instances — what your team can launch