Summary and recommendation
Spacelift 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.
Spacelift manages users through a two-layer model: an account-level admin toggle and Space-level role assignments (Read, Write, or Admin) scoped to resource groupings called Spaces.
Access is enforced via OPA-based login policies written in Rego, which evaluate identity provider claims at each login to determine what a user can do.
There is no standalone email-invite flow - every app user must authenticate through a configured IdP (GitHub, GitLab, Google OAuth, or SAML/SSO) before they appear in Settings → Members.
Quick facts
| Admin console path | Settings → Members (within the Spacelift account dashboard) |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | N/A |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Full access to all account settings, all Spaces, all stacks, billing, and user management. Can create and manage login policies, spaces, and integrations. | Admin status is granted via login policy (OPA-based) or by toggling admin on an existing user in Settings → Members. The first user who creates the account is automatically an admin. | |||
| User (non-admin) | Access is determined by Space-level role assignments (Read, Write, Admin) set via login policies or Space access rules. No account-level admin capabilities. | Cannot access account-level settings, billing, or manage other users unless granted admin. | Users must authenticate via a configured identity provider (GitHub, GitLab, Google, SAML/SSO). There is no standalone username/password invite flow; access is controlled through login policies. |
Permission model
- Model type: hybrid
- Description: Spacelift uses a two-layer permission model. At the account level, users are either admins or non-admins. Within Spaces (resource groupings), non-admin users are assigned Read, Write, or Admin roles per Space. Access rules are enforced via OPA-based login policies that evaluate identity provider claims (e.g., GitHub teams, SAML attributes) to assign roles dynamically at login.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Space-level role assignment (Read / Write / Admin per Space); account-level admin toggle; stack-level access inherited from Space membership.
How to add users
- Ensure the user can authenticate via a supported identity provider (GitHub, GitLab, Google OAuth, or SAML SSO).
- Navigate to Settings → Members in the Spacelift account dashboard.
- If using login policies: create or update an OPA login policy that maps the user's IdP identity (e.g., GitHub username, team membership, SAML attribute) to the desired role and Space access.
- If granting admin access manually: locate the user in the Members list after their first login and toggle the Admin flag.
- Assign Space-level access by editing the relevant Space and adding the user or their IdP group with the appropriate role (Read, Write, or Admin).
Required fields: Identity provider identity (e.g., GitHub username, GitLab username, Google email, or SAML subject), Target Space(s) and role assignment, Login policy rule (if access is policy-driven)
Watch out for:
- Users cannot be pre-invited by email; they must log in at least once via the configured IdP before they appear in the Members list.
- Login policies are evaluated at each login; changes to policies take effect on the user's next login session.
- If no login policy exists, Spacelift falls back to allowing any authenticated user from the connected IdP, which may be overly permissive.
- SAML/SSO configuration is required for enterprise IdP-based access; this may require a higher-tier plan.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Not documented |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Official documentation does not explicitly describe a delete or permanent removal action for individual users. Access can be revoked by updating the login policy to deny the user's identity, and/or by removing their Space-level role assignments. The user will then be unable to log in or access resources on their next session.
- Update the account's login policy (OPA) to deny login for the specific user identity (e.g., by GitHub username or SAML attribute).
- Remove the user's explicit Space-level role assignments in Settings → Spaces for each relevant Space.
- Optionally, revoke admin status via Settings → Members if the user currently holds admin access.
| Data impact | Behavior |
|---|---|
| Owned records | Not documented |
| Shared content | Not documented |
| Integrations | Not documented |
| License freed | Not documented |
Watch out for:
- Revoking access via login policy only takes effect on the user's next login attempt; existing active sessions may persist until they expire.
- Official docs do not document a hard-delete user action from the UI; access removal is policy- and role-driven.
- If the user is the sole admin, removing their admin access may lock the account from administrative actions.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Free tier user | Up to 2 users included at no cost | $0 |
| Starter plan user | Up to 10 users included in the Starter plan | $399/month for the plan (not per-seat within the included count) |
| Starter+ / Business / Enterprise user | Custom user limits; pricing negotiated per contract | Custom |
- Where to check usage: Settings → Members in the Spacelift account dashboard shows current account members.
- How to identify unused seats: Not documented
- Billing notes: Pricing is plan-based with user count limits per tier rather than strict per-seat billing within a plan. Exceeding the user limit for a plan tier requires upgrading to the next tier. Exact overage or per-seat pricing beyond plan limits is not publicly documented.
The cost of manual management
Spacelift's pricing is plan-based with user count limits per tier rather than strict per-seat billing within a plan. The Free tier covers up to 2 users at no cost; the Starter plan ($399/month) covers up to 10 users.
Starter+, Business, and Enterprise tiers carry custom pricing negotiated per contract. Exceeding the user limit for a given tier requires upgrading - exact overage or per-seat pricing beyond plan limits is not publicly documented.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Spacelift is a strong fit for engineering teams already operating with an IdP and comfortable managing access-as-code via OPA policies. Every app user's access is governed by login policies, so teams that invest in getting those policies right gain consistent, auditable access control across all Spaces.
Teams expecting a lightweight admin UI for user management - or requiring SCIM-based lifecycle automation - will find the current model operationally demanding without additional tooling or scripting.
Bottom line
Spacelift's user management is powerful but policy-first: access is defined in Rego, enforced at login, and scoped per Space rather than managed through a traditional admin console. Teams that treat access control as code will find this model auditable and scalable.
Teams that need point-and-click provisioning, email invites, or SCIM integration should plan for meaningful setup investment before the model operates smoothly at scale.
Automate Spacelift 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.
