Skip to main content
Stout’s tenancy model has four nested layers: organization → team → member → per-resource access. Most small teams only touch the first three; larger teams use per-resource access to carve up a fleet.

​
Organizations

An organization is the top-level boundary. Every box, job, workflow, member, and webhook belongs to exactly one org. Data never crosses org lines. You manage the org from Settings → Organization: change the display name, adjust the slug (with care — it appears in URLs), or delete the org (owners only, and only after removing every member).

​
Members and invitations

From Settings → Team:
  • Invite — enter an email and pick a role. Stout sends a link that expires in 7 days. If the recipient doesn’t yet have a Stout account, the acceptance flow doubles as signup.
  • Remove — revokes all access immediately. Any jobs they queued continue, but they can no longer log in to this org.
  • Change role — promote or demote. The only constraint: there must always be at least one Owner.
Pending invitations are visible at the bottom of the Team page. You can revoke or resend them.

​
Roles

RoleOrg settingsMembersBoxesJobs
OwnerAll, incl. deletionAllAllAll
AdminMostAllAllAll
MemberView onlyView onlyOnly assignedOnly on assigned boxes
Admins cannot delete the org or demote Owners; everything else is open to them. Members are restricted to boxes that have been explicitly assigned to them or to a team they belong to.

​
Teams

Teams are subgroups within an org. From the Teams page, create a team with a name and slug, then add members. Teams exist for one purpose: assigning box access to many people at once. Example: a firmware team gets access to boxes A, B, and C; a QA team gets access to boxes D and E. Adding someone to the firmware team gives them access to A/B/C automatically; removing them revokes it.

​
Per-box access

Open a box’s detail page and go to the Settings tab. The access panel there lists:
  • Every member currently granted access, individually.
  • Every team granted access.
  • The effective access computed from both.
Admins can grant or revoke access here. For members, the default is no access — you must explicitly grant it.

​
Audit logs

Settings → Audit Log shows an append-only stream of every meaningful user action: logins, box registrations, job submissions, role changes, SSO config edits, webhook deliveries. Each entry has:
  • actor — the user, or system for control-plane-initiated events.
  • action — a dotted name like box.register, member.remove, workflow.run.start.
  • resource type + ID — what the action targeted.
  • metadata — JSON details specific to the action.
  • timestamp (with time zone).
Filter by any of these. Export to CSV for compliance reviews.

​
Account security recap

Each member manages their own:
  • Password (Argon2id hashed at rest).
  • MFA — optional TOTP with backup codes. Recommended for admins and owners.
  • SSH public keys — synced to every box the member has access to. Enables passwordless SSH.

​
Coming soon

  • SCIM provisioning.
  • Custom roles.
  • Session-level audit (seeing which device or IP generated each action).