Summary and recommendation
Buildkite user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Buildkite uses a two-level permission model: organization roles (Administrator or Member) and team roles (Maintainer or Member). Pipeline access is granted to teams at read, build, or manage levels - individual users inherit permissions from their team memberships. There are no custom roles; the model is fixed at both levels.
The Teams feature is unavailable on the free and Startup plans. On those plans, every app member shares access to all pipelines with no team-level scoping.
Quick facts
| Admin console path | Organization Settings > Members (and Teams) |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Pro/Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Organization Administrator | Full access to all organization settings, billing, SSO configuration, member management, all pipelines, and all teams. | All plans | Counts as a full user seat | Admins can see and modify all pipelines regardless of team membership. | |
| Organization Member | Access to pipelines and teams they are explicitly added to. Can trigger builds, view logs, and manage resources within their team scope. | Cannot access organization settings, billing, SSO, or pipelines outside their assigned teams. | All plans | Counts as a full user seat | Pipeline visibility and access is controlled at the team level; members not in any team with pipeline access cannot see those pipelines. |
| Team Maintainer | Can manage team membership (add/remove members) and team pipeline access within their specific team. | Cannot manage organization-level settings or other teams. | Team plan and above (Teams feature required) | Counts as a full user seat | Teams feature is not available on the free/Startup plan. |
| Team Member | Access to pipelines assigned to the team with the permission level set on that team (read, build, or manage). | Cannot manage team membership or organization settings. | Team plan and above | Counts as a full user seat | Pipeline access level (read/build/manage) is set per team-pipeline assignment, not per individual user. |
Permission model
- Model type: role-based
- Description: Buildkite uses a two-level role model: organization-level roles (Administrator or Member) and team-level roles (Maintainer or Member). Pipeline access is granted to teams at one of three levels: read, build, or manage. Individual users inherit pipeline permissions from their team memberships. There are no custom roles; permissions are fixed at the organization and team levels.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Organization-level (admin vs. member) and team-level (maintainer vs. member) with per-pipeline access levels (read, build, manage) assigned to teams.
How to add users
- Navigate to Organization Settings > Members (https://buildkite.com/organizations/~/members).
- Click 'Invite Members'.
- Enter the email address(es) of the user(s) to invite.
- Select the organization role: Member or Administrator.
- Optionally assign the invitee to one or more teams during the invite flow.
- Click 'Send Invitations'. The invitee receives an email to accept and create or link their Buildkite account.
Required fields: Email address, Organization role (Member or Administrator)
Watch out for:
- Invitations expire; if the user does not accept in time, a new invitation must be sent.
- If SSO is enforced, users must authenticate via the configured SSO provider; email/password login is disabled for those users.
- Users are not automatically added to any team unless explicitly assigned during invite or afterward.
- On the free/Startup plan, the Teams feature is unavailable, so all members share access to all pipelines.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Buildkite allows removing (revoking) a member from the organization. This removes their access immediately. There is no separate 'deactivate' state; removal is the primary offboarding action. If SCIM is configured (Enterprise), deprovisioning via the IdP removes the user from the organization automatically.
- Navigate to Organization Settings > Members (https://buildkite.com/organizations/~/members).
- Locate the user in the member list.
- Click the user's name or the options menu next to their name.
- Select 'Remove from Organization' (or equivalent removal action).
- Confirm the removal. The user loses access immediately.
| Data impact | Behavior |
|---|---|
| Owned records | Build history, pipeline configurations, and audit log entries created by the user are retained in the organization after removal. |
| Shared content | Pipelines, teams, and builds the user contributed to remain intact and accessible to other members. |
| Integrations | API tokens and agent tokens created by the removed user may remain active unless explicitly revoked; administrators should audit and revoke these separately. |
| License freed | Removing a member frees their user seat, reducing the billable seat count at the next billing cycle. |
Watch out for:
- API tokens belonging to the removed user are not automatically revoked; they must be manually invalidated to prevent continued API access.
- If SSO is enforced but SCIM is not configured, removing a user from the IdP does not automatically remove them from Buildkite; manual removal in Buildkite is required.
- SCIM-based automatic deprovisioning is only available on the Enterprise plan.
- A removed user can be re-invited using the same email address.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| User seat | Full access per role assignment; all organization members (admins and regular members) consume one seat each. | $15/user/month (Team plan), $25/user/month (Business plan), custom (Enterprise) |
- Where to check usage: Organization Settings > Billing (https://buildkite.com/organizations/~/billing) shows current seat count and usage.
- How to identify unused seats: Review the Members list (Organization Settings > Members) and cross-reference last login activity or build activity. Buildkite does not natively surface a 'last active' timestamp in the UI as of available documentation; audit logs may be used to identify inactive users on plans that include audit logging.
- Billing notes: Buildkite combines per-seat pricing with usage-based pricing for build minutes and compute. The free plan includes up to 1,000 build minutes. The Startup plan is free for up to 3 users. Team plan is $15/user/month. Business plan is $25/user/month. Enterprise is custom pricing. SCIM provisioning is only available on Enterprise. SSO is available on Team plan and above.
The cost of manual management
Every app in your stack that lacks automated provisioning creates the same offboarding gap - and Buildkite is a meaningful one for engineering orgs. Removing a user from your IdP does not remove them from Buildkite unless SCIM is configured, which requires the Enterprise plan.
On Team or Business plans, manual removal in Buildkite is a required step every time someone leaves.
Compounding this: removing a member via the UI does not revoke their personal API tokens. Those remain valid until manually invalidated, leaving a live credential behind after offboarding. There is also no native last-active timestamp in the Members UI, so identifying unused seats requires parsing audit logs - a feature itself gated to higher-tier plans.
What IT admins are saying
The most consistent friction reported by Buildkite admins centers on the SCIM paywall. Automated user lifecycle management - provisioning and deprovisioning - is locked to Enterprise, forcing teams on Team or Business plans to manage membership manually at scale.
A secondary complaint is the absence of self-serve SCIM setup for custom SAML configurations; that path requires contacting Buildkite support.
Admins also flag the lack of last-login visibility in the Members UI as a practical obstacle to seat hygiene, since there is no built-in way to surface inactive users without log analysis.
Common complaints:
- SCIM provisioning is restricted to the Enterprise plan, requiring an upgrade from Team or Business plans solely for automated user lifecycle management.
- Custom SAML SCIM configuration requires contacting Buildkite support rather than self-serve setup.
- No built-in 'last active' or 'last login' visibility in the Members UI makes it difficult to identify unused seats without parsing audit logs.
- Removing a user from an SSO/IdP provider does not automatically remove them from Buildkite unless SCIM is configured (Enterprise only), creating a deprovisioning gap on lower plans.
- No custom roles; permission granularity is limited to the fixed organization and team role model.
The decision
Every app in a CI/CD stack eventually surfaces the same question: how much access governance can you automate without upgrading every tool to its highest tier? For small engineering teams with low turnover, Buildkite's manual workflow is manageable and the fixed role model covers most access patterns without configuration overhead.
The model breaks down at scale or with compliance requirements. The deprovisioning gap on sub-Enterprise plans - where IdP removal does not cascade to Buildkite - is a real risk for any org with regular offboarding.
Teams that need automated lifecycle management, audit-ready deprovisioning, or seat hygiene visibility should factor the Enterprise plan requirement into their evaluation.
Bottom line
Buildkite's permission model is straightforward but deliberately tiered: the features most relevant to access governance - SCIM provisioning, automated deprovisioning, and audit logging - are concentrated at the Enterprise tier.
On lower plans, every offboarding event requires a manual step in Buildkite, and a missed step leaves API tokens active.
For small, stable teams the manual workflow is manageable; for orgs with regular headcount changes or compliance obligations, the gap between what the UI offers and what automated governance requires is significant.
Automate Buildkite workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
