Members

Fleet membership lives entirely in the cabinet. This is the right surface for the job — adding a member is an admin event, not an operational one.

Members list

The members table shows everyone with access to the fleet. Columns:

• Email — primary identity.
• Role — Owner, Admin, Member, or Viewer.
• Status — active, invited, suspended.
• Joined — when the invitation was accepted.
• Last active — most recent authenticated request.

Inviting a member

Send an invite by email. The recipient receives a magic link at /invite/[token] that walks them through sign-up (or sign-in) and joins them to the fleet under the role you picked. Invitations expire after 7 days; resend or revoke from the same row.

Choose the role at invite time — you can change it later, but downgrading an Owner requires a second Owner to exist first.

Resending and revoking invitations

Pending invitations have a Resend and Revoke action in the row. Revoke immediately invalidates the token; resending issues a fresh one and resets the 7-day expiry.

Removing a member

Removing a member detaches them from the fleet immediately. What survives:

• Their entries in the activity log and audit log.
• Sessions they kicked off (transcripts remain attached to the machine).

What gets revoked:

• Fleet API tokens issued by them.
• Pending invitations they created.
• OAuth-issued tokens that depend on their membership.

Per-machine access overrides

Some fleets enable per-machine access overrides on top of role-based access (Full Access / Execute Only / View Only). See Roles & permissions for what each level allows.

Where this data lives

Members and invitations are managed through the fleets API, so the same membership applies across the cabinet, desktop, and CLI.

Related

• Roles & permissions
• Fleet settings — require 2FA, IP allowlist, default policy.
• Subscriptions — seats and billing.
• Activity log