Summary and recommendation
Pulumi 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.
Pulumi Cloud manages users through a two-tier model: organization-level roles (Admin or Member) and stack-level permissions (Admin, Write, or Read) granted via Teams. Every app in your stack portfolio is access-controlled through team assignments - new members have zero stack visibility until explicitly added to a team.
There are no fully custom roles; all permissions are predefined at each tier.
Quick facts
| Admin console path | app.pulumi.com → [Organization Name] → Settings → Members |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Organization Admin | Full control over organization settings, members, teams, stacks, billing, SSO/SCIM configuration, and access tokens. Can add/remove members, change roles, and manage all resources. | Cannot act as another member's identity; cannot recover stacks owned by deleted members without prior transfer. | All plans (Individual, Team, Enterprise) | Counts as a billable member on Team and Enterprise plans | There must always be at least one Admin in an organization; the last Admin cannot be removed or demoted. |
| Organization Member | Can create and manage stacks they own, collaborate on stacks shared via teams, and use organization-level resources within granted team permissions. | Cannot access organization settings, billing, SSO configuration, or manage other members. Cannot see stacks they have not been granted access to. | All plans | Counts as a billable member on Team and Enterprise plans | Default stack permissions for new members depend on organization-level stack default settings; members may have no access to existing stacks until added to a team. |
| Team Admin (within a Team) | Can manage membership of a specific team, add/remove team members, and set team-level stack permissions. | Cannot manage organization-wide settings or other teams unless also an Organization Admin. | Team plan and above | No additional seat cost beyond standard member seat | Teams feature is not available on the free Individual plan. |
Permission model
- Model type: role-based
- Description: Pulumi Cloud uses a two-tier role model: organization-level roles (Admin, Member) and team-level stack permissions (Admin, Write, Read). Stacks are shared with members via Teams. Each team is granted a permission level on specific stacks. Individual stack permissions can also be granted directly to teams. There are no fully custom roles; permissions are predefined at each tier.
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Organization-level (Admin/Member) and stack-level (Admin/Write/Read) via team assignments
How to add users
- Navigate to app.pulumi.com and select your organization.
- Go to Settings → Members.
- Click 'Invite member'.
- Enter the invitee's email address or Pulumi username.
- Select the role (Admin or Member).
- Send the invitation. The invitee receives an email and must accept to join.
- Optionally, add the new member to one or more Teams via Settings → Teams to grant stack access.
Required fields: Email address or existing Pulumi username
Watch out for:
- Invitees must have or create a Pulumi account to accept the invitation; the invite is tied to the email used.
- New members have no stack access by default until added to a team with appropriate permissions.
- Invitation links expire; if not accepted, the admin must re-send.
- On the free Individual plan, organizations are single-user; multi-member organizations require Team plan or above.
| 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: No
- Delete/deactivate behavior: Pulumi Cloud does not offer a 'deactivate' state for organization members. Removing a member revokes their access to the organization immediately. The member's Pulumi account itself is not deleted; they retain access to their personal account and any other organizations they belong to. There is no soft-disable or suspension option within an organization.
- Navigate to app.pulumi.com and select your organization.
- Go to Settings → Members.
- Locate the member to remove.
- Click the options menu (⋯) next to their name.
- Select 'Remove member' and confirm the action.
| Data impact | Behavior |
|---|---|
| Owned records | Stacks created by the removed member remain in the organization and are not deleted. Ownership of those stacks stays associated with the original creator's account identity, but the stacks remain accessible to organization admins. |
| Shared content | Team memberships are revoked immediately. The removed member loses access to all stacks shared via organization teams. |
| Integrations | Any personal access tokens the removed member created for organization resources should be manually revoked by an admin via Settings → Access Tokens before or after removal to prevent continued API access. |
| License freed | Removing a member reduces the active member count, which may reduce usage-based billing on the next billing cycle depending on plan. |
Watch out for:
- Personal access tokens belonging to the removed member are NOT automatically invalidated when the member is removed from the organization; admins must manually revoke them.
- If the removed member was the sole Admin, removal is blocked - another member must be promoted to Admin first.
- Stacks owned by the removed member remain in the organization but may lack a clear new owner; reassignment is a manual process.
- SCIM-based deprovisioning (Enterprise only) will remove the user from the organization automatically when deprovisioned in the IdP, but token revocation still requires manual action.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Organization Member (Team plan) | Access to organization stacks via teams, CI/CD integrations, audit logs, and 150k free resource-hour credits/month shared across org | Usage-based: ~$0.00025/resource/hour per resource managed; no per-seat flat fee |
| Organization Member (Enterprise plan) | All Team features plus SAML SSO, SCIM provisioning, advanced policies, self-hosted option, and priority support | Usage-based: ~$0.0005/resource/hour, or negotiated annual contract (e.g., $32,850/year via AWS Marketplace) |
- Where to check usage: app.pulumi.com → [Organization Name] → Settings → Billing & Usage
- How to identify unused seats: Review Settings → Members for members with no recent stack activity. Pulumi does not provide a built-in 'last active' timestamp in the Members UI as of early 2025; admins must cross-reference audit logs (Settings → Audit Logs) to identify inactive members.
- Billing notes: Pulumi Cloud billing is primarily resource-hour based, not per-seat. Adding or removing members affects access but does not directly change a flat per-seat charge. However, on annual Enterprise contracts, member counts may be factored into negotiated pricing. The Team plan includes 150,000 free resource-credit-hours per month before usage charges apply.
The cost of manual management
Pulumi Cloud billing is resource-hour based, not per-seat, so adding or removing members does not directly trigger a flat charge. However, identifying inactive members is operationally expensive: the Members UI does not expose a last-active timestamp, forcing admins to cross-reference audit logs manually at Settings → Audit Logs.
On annual Enterprise contracts, member counts may factor into negotiated pricing, making unreviewed rosters a latent cost risk.
What IT admins are saying
Three friction points surface consistently in community feedback. First, personal access tokens are not automatically revoked when a member is removed - each token must be hunted down and invalidated manually, leaving a real security gap.
Second, stack ownership does not transfer on removal, producing orphaned stacks with no clear owner. Third, the absence of a suspend or deactivate state means admins must choose between full removal and full access, with no middle ground for temporary restrictions.
Common complaints:
- Users report that personal access tokens are not automatically revoked when a member is removed from an organization, creating a potential security gap that requires manual remediation.
- No built-in 'last login' or 'last active' date is visible in the Members UI, making it difficult to identify inactive seats without manually parsing audit logs.
- The lack of a 'deactivate/suspend' state (as opposed to full removal) is noted as a gap for organizations that need to temporarily restrict access without losing membership history.
- Stack ownership does not automatically transfer when a member is removed, leaving orphaned stacks with no clear owner.
- Some users note that the Teams-based permission model requires significant upfront configuration - new members have zero stack access until explicitly added to teams, which can cause confusion during onboarding.
The decision
Manual administration is viable for small, stable engineering orgs where team membership changes infrequently. It becomes a liability at scale: every app a departing engineer touched may have orphaned stack ownership, and token hygiene requires a separate audit pass after every offboarding.
Organizations with frequent onboarding/offboarding cycles, or those operating under compliance requirements for access certification, should treat SCIM provisioning (Enterprise plan, SSO prerequisite) as the baseline rather than an upgrade.
Bottom line
Pulumi Cloud's manual user management is straightforward for day-to-day role changes but carries two structural gaps that compound over time: no automatic token revocation on member removal, and no built-in activity signal to identify dormant accounts.
Every app in a Pulumi organization inherits these gaps unless the org invests in audit-log review cadences or moves to SCIM-backed provisioning. Teams that can absorb that operational overhead on the Team plan will find the UI sufficient; those that cannot should budget for Enterprise.
Automate Pulumi 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.
