Summary and recommendation
Travis CI 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.
Travis CI does not maintain its own user directory.
Access to every app and repository in your Travis CI organization is inherited directly from your connected VCS provider - GitHub, GitLab, or Bitbucket.
There are no standalone user roles to configure inside Travis CI itself.
Organization Admin status in Travis CI is granted automatically to anyone who holds admin rights in the connected VCS organization.
Members see only the repositories their VCS permissions allow.
Custom roles and fine-grained permission configuration are not available.
Quick facts
| Admin console path | Settings (top-right avatar menu) > Organization Settings, or https://app.travis-ci.com/organizations/{org-name}/settings |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Organization Admin | Can manage organization settings, view all repositories synced to the org, manage billing, and control which repositories are active on Travis CI. Inherits admin rights from the connected VCS provider (GitHub/GitLab/Bitbucket) organization owner role. | Cannot independently manage user roles within Travis CI; role assignment is controlled by the VCS provider organization. | No per-seat cost; pricing is based on concurrent jobs, not users. | Admin status in Travis CI is derived from admin status in the connected VCS organization. Changing roles must be done in the VCS provider, then re-synced. | |
| Member | Can view and trigger builds for repositories they have access to in the connected VCS organization. Access level mirrors their VCS repository permissions (read/write). | Cannot access organization billing settings or activate/deactivate repositories unless they have admin rights in the VCS provider. | No per-seat cost; pricing is based on concurrent jobs, not users. | Access is not managed inside Travis CI directly. Adding or removing a user from the VCS organization and re-syncing is required to reflect changes in Travis CI. |
Permission model
- Model type: role-based
- Description: Travis CI does not maintain an independent permission system. User access and roles are inherited from the connected VCS provider (GitHub, GitLab, or Bitbucket). Repository-level permissions in the VCS provider determine what a user can see and do in Travis CI. Organization-level admin rights in the VCS provider grant admin access in Travis CI.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Repository-level access inherited from VCS provider; no fine-grained permission configuration within Travis CI itself.
How to add users
- Add the user to the GitHub/GitLab/Bitbucket organization or repository in the VCS provider.
- In Travis CI, navigate to your organization's settings page at https://app.travis-ci.com/organizations/{org-name}/settings.
- Click 'Sync Account' (or 'Sync Now') to pull the latest membership data from the VCS provider.
- The new user must also sign in to Travis CI at https://app.travis-ci.com using their VCS provider credentials to activate their account.
Required fields: Active account on the connected VCS provider (GitHub, GitLab, or Bitbucket), Membership in the relevant VCS organization or repository
Watch out for:
- Users are not added directly inside Travis CI; all user provisioning originates in the VCS provider.
- A sync must be triggered manually or waited for (periodic auto-sync) before the new member appears in Travis CI.
- The user must log in to Travis CI at least once with their VCS credentials to be fully activated.
- Travis CI does not support SCIM provisioning on cloud plans; Enterprise self-hosted may have additional options.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | No | Not documented |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Travis CI does not document an explicit delete or deactivate user action within its own UI. Removing a user from the connected VCS organization or repository and triggering a sync in Travis CI revokes their access. Whether this constitutes a formal account deletion within Travis CI is not explicitly documented in official sources.
- Remove the user from the GitHub/GitLab/Bitbucket organization or repository in the VCS provider.
- In Travis CI, navigate to https://app.travis-ci.com/organizations/{org-name}/settings.
- Click 'Sync Account' to refresh membership data from the VCS provider.
- The user will lose access to the organization's repositories in Travis CI once the sync completes.
| Data impact | Behavior |
|---|---|
| Owned records | Build history and logs associated with the user's triggered builds remain in Travis CI and are not deleted when access is revoked. |
| Shared content | Environment variables, repository settings, and build configurations are stored at the repository level and are unaffected by removing a user. |
| Integrations | API tokens or SSH keys the user added to repositories may persist and should be manually reviewed and revoked. |
| License freed | Because pricing is based on concurrent jobs rather than seats, removing a user does not directly free a license or reduce billing. |
Watch out for:
- Removing a user from Travis CI requires action in the VCS provider first; there is no standalone 'remove user' button in Travis CI.
- Any personal API tokens the user generated in Travis CI (Settings > API Token) are not automatically invalidated when VCS access is removed; these must be revoked separately if the user had access.
- Build history triggered by the removed user remains visible to remaining org members.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Concurrent Job Slot | One parallel build execution slot. All users in the organization share the pool of concurrent job slots. | Varies by plan: Bootstrap $64/mo (1 slot), Startup $119/mo (2 slots), Small Business $229/mo (5 slots), Premium $449/mo (10 slots), Platinum from $729/mo (15–300 slots). Annual billing rates. |
- Where to check usage: https://app.travis-ci.com/account/subscription - shows current plan, concurrent job usage, and billing details.
- How to identify unused seats: Travis CI does not provide a built-in report of inactive users. Because billing is per concurrent job rather than per seat, unused seats are not a direct cost driver. Admins can review build history per repository to identify inactive contributors.
- Billing notes: Pricing is based entirely on concurrent job slots, not on the number of users. Adding or removing users has no direct impact on the monthly bill. Plan upgrades or downgrades change the number of available concurrent jobs. Open-source public repositories receive free builds with up to 5 concurrent jobs on the cloud platform.
The cost of manual management
Travis CI pricing is based entirely on concurrent job slots, not on the number of users. Adding or removing team members has no direct impact on your monthly bill. Plans range from Bootstrap ($64/mo, 1 concurrent job) through Platinum (from $729/mo, 15–300 concurrent jobs), all billed annually.
The Enterprise plan is self-hosted with custom pricing.
Because there are no per-seat costs, unused-seat audits are not a billing concern. Admins who want to identify inactive contributors should review per-repository build history manually, as Travis CI provides no built-in inactive-user report.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Travis CI is the right fit for teams already standardized on GitHub, GitLab, or Bitbucket who want CI access control to follow their VCS membership without any additional configuration layer. Every app a user can reach in the VCS organization is automatically reflected in Travis CI after a sync.
It is a poor fit for teams that need immediate, auditable access revocation or IdP-driven provisioning. There is no SCIM support on cloud plans, no native deactivation button, and no user-lifecycle webhooks. Teams with strict offboarding SLAs should account for the sync delay and the manual API-token revocation step as permanent operational overhead.
Bottom line
Travis CI offloads all user management to your VCS provider, which keeps the access model simple but introduces real operational gaps: sync delays, no SCIM on cloud plans, and no automatic invalidation of personal API tokens on offboarding.
For teams whose VCS organization already reflects their source of truth for access, the model works with minimal overhead. For teams that need deterministic, real-time deprovisioning tied to an IdP, the current architecture requires compensating controls outside Travis CI itself.
Automate Travis CI 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.
