Teams & Collaboration
Temps includes unlimited seats — invite your entire team at no extra cost. Access is controlled by roles at the organization and project level.
Inviting Team Members
- Go to Settings → Team → Invite Member
- Enter the email address and choose a role
- The invitee receives an email link valid for 48 hours
- Once accepted, they appear in the member list
# Team member invitations are managed via the web UI
# Settings → Team → Invite Member
Pending invitations can be revoked from Settings → Team → Pending Invites.
Roles
| Role | Description |
|---|---|
| Owner | Full access — billing, team management, all projects |
| Admin | All project access, can manage team members (not billing) |
| Developer | Deploy, view logs, manage environment variables |
| Viewer | Read-only access to projects and logs |
Roles apply organization-wide by default. You can override them per project.
Project-level overrides
Grant a user a different role on a specific project without changing their org-wide role:
- Go to Project → Settings → Access
- Click Add Member
- Select the user and the role for this project
A user with the org-wide Viewer role can be a Developer on one specific project. The narrower scope always wins.
Removing Members
Go to Settings → Team, find the member, and click Remove. Their sessions are invalidated immediately. Projects they deployed remain untouched.
temps team remove user@example.com
Audit Log
Every action that changes state — deploys, environment variable edits, domain changes, team changes — is recorded in the audit log.
Settings → Audit Log shows:
- Who performed the action
- What changed (before/after for variable edits)
- When it happened (UTC timestamp)
- Which project or resource was affected
The audit log is append-only and cannot be edited or deleted.
# Export audit log
bunx @temps-sdk/cli audit list --from 2026-01-01 --to 2026-12-31 --json > audit-export.json
SSO
SSO via SAML 2.0 is available. Configure your identity provider under Settings → Security → SSO. Once enabled, all team members must authenticate through the IdP — password and OAuth login are disabled for SSO-enrolled users.
SSO enforcement does not affect the owner account until the owner explicitly enables it. This prevents accidental lockout during setup.