Teams and Access
Watasu is organized around teams. A team owns apps and add-ons, and team membership controls who can do what with them.
Why teams
Section titled “Why teams”- one place to manage who has access to what
- apps and add-ons stay tied to the team that owns them, not to whichever individual created them
- collaborator changes (someone joins, someone leaves) are a single operation
Levels of access
Section titled “Levels of access”Different people on the same team usually need different things:
| Role | Typical needs |
|---|---|
| Read-only | View apps, dashboards, and runtime state |
| Deploy | Push code, set config vars, manage releases |
| Operate | Scale processes, manage add-ons, restart, restore |
| Admin | Add/remove members, change billing, destroy apps |
Use the smallest level of access that lets each person do their actual job. Tightening later is harder than starting tight.
Team-wide vs. per-app access
Section titled “Team-wide vs. per-app access”Access can be granted at the team level (everything the team owns) or per-app (one specific app). Per-app grants are useful when one team owns multiple services and not every engineer needs management rights everywhere.
Add-on access
Section titled “Add-on access”Add-ons attached to an app are visible to the people who can access that app, at the level appropriate to their role. Mutating add-ons (creating, destroying, restoring) is a separate, more restricted permission than reading their connection details.
Hygiene
Section titled “Hygiene”- give deploy rights to the people who actually deploy
- review access whenever someone changes role or leaves
- don’t share personal logins. Add the person; don’t share the credential.