Roles and Permissions
Understand permissions for each role in your account
Overview
Bluebricks uses role-based access control (RBAC) to govern who can do what across your organization. Every user is assigned one account-level role that determines their permissions for all resources: clouds, collections, packages, environments, secrets, webhooks, and more.
Account-level roles control what a user can do. Collection membership controls where they can do it. See Owners and Members for collection-level access.
Roles
Bluebricks defines four roles, ordered from most to least privileged: Admin, Builder, Deployer, and Viewer.
Read more about each role:
Admins have full access to every resource and action in the organization. Admins manage users, configure organization settings, create API keys, and govern all collections, packages, and environments.
Assign this role to platform team leads and organization owners.
Builders can create and manage infrastructure packages (artifacts and blueprints), collections, clouds, secrets, and webhooks. Builders can also initiate and manage deployments. They cannot invite or manage users, change organization settings, or create API keys.
Assign this role to infrastructure engineers who author and maintain IaC.
Deployers can initiate runs and approve or apply plans. Deployers have read access to the resources they need for deployment (collections, packages, clouds) but cannot create or modify infrastructure definitions. Deployers see only the Deploy and Plan pages.
Assign this role to operations engineers or CI/CD service accounts that run deployments without authoring IaC.
Viewers have read-only access to all resources. Viewers can browse collections, packages, environments, clouds, and organization data but cannot create, modify, or delete anything.
Assign this role to stakeholders, auditors, or team members who need visibility without write access.
When you invite a user, the role selector defaults to Viewer. If a user logs in without having been invited or assigned a role (for example, via SSO), they are automatically assigned the Deployer role.
How to invite users
You can invite users from three places:
Sidebar menu > Invite users (quickest path)
Account Settings > Teammates > Invite (top-right)
Collection page > Assigned users > Invite teammates (pre-selects the collection)
All three open the same invite modal. The steps are:
Select an organization role
Choose a role from the dropdown. This sets what the invited user can do across the organization. See Roles above for what each role allows.
Assign collections (optional)
Select one or more collections to grant the user access on acceptance. Each user is added as a Member by default. There is no option to assign the Owner role at invite time; you can change their collection role to Owner after they accept.
When you invite from a collection page, that collection is pre-selected and the collections picker is locked. To assign additional collections, use the invite flow from Account Settings instead.
Only admins can invite users, change roles, and manage user status.
Managing users
Users are managed in Account Settings > Teammates. The page has two tabs:
Teammates: active members of your organization, showing their assigned collections, status, and role
Invited: pending and canceled invitations
User statuses
Active
User has accepted the invite and is using the platform
Change role, Deactivate
Invited
Invitation sent but not yet accepted
Cancel invite
Invite canceled
Invitation was canceled before acceptance
Remove
Inactive
User was deactivated by an admin
Remove
Change a user's role
Find the user in the Teammates tab and use the Role dropdown to select a new role. The change takes effect immediately.
Deactivate a user
Find the user in the Teammates tab, click the three-dot menu, and select Deactivate. Deactivated users lose access but their data is preserved. They appear with an Inactive status.
Remove a user
Deactivated users and canceled invitations can be permanently removed. Find the user in the appropriate tab, click the three-dot menu, and select Remove.
What each role can do
The tables below show every permission and which roles include it.
Cloud accounts
Create cloud accounts
Yes
Yes
View cloud accounts
Yes
Yes
Yes
Yes
Update cloud accounts
Yes
Yes
Delete cloud accounts
Yes
Yes
Collections
Create collections
Yes
Yes
View collections
Yes
Yes
Yes
Yes
Update collections
Yes
Yes
Delete collections
Yes
Yes
Packages (artifacts and blueprints)
Create packages
Yes
Yes
View packages
Yes
Yes
Yes
Yes
Update packages
Yes
Yes
Delete packages
Yes
Yes
Environments and runs
Create environments
Yes
Yes
Yes
View environments
Yes
Yes
Yes
Yes
View run plans
Yes
Yes
Yes
Yes
Approve runs
Yes
Yes
Yes
Approving runs from Slack is limited to admins and builders. Deployers can approve runs through the web UI if they are an owner of the collection.
Secrets
Create secrets
Yes
Yes
View secrets
Yes
Yes
Yes
Yes
Update secrets
Yes
Yes
Delete secrets
Yes
Yes
Webhooks
Create webhooks
Yes
Yes
View webhooks
Yes
Yes
Yes
Yes
Update webhooks
Yes
Yes
Delete webhooks
Yes
Yes
Users
Invite users
Yes
View users
Yes
Yes
Yes
Yes
Update user roles
Yes
Remove users
Yes
Organization and API keys
View organization
Yes
Yes
Yes
Yes
Update organization settings
Yes
Create API keys
Yes
View API keys
Yes
Update API keys
Yes
Long-lived API tokens have a fixed set of permissions that do not correspond to any user role. They cannot perform Admin-only actions such as inviting users or changing organization settings. See API Authentication for details.
Other resources
View tasks
Yes
Yes
Yes
Yes
View rescue operations
Yes
Yes
Yes
Yes
View vendors
Yes
Yes
Yes
Yes
Recommended role mapping for common teams
Platform / DevOps lead
Admin
Infrastructure engineer
Builder
Application developer (deploys only)
Deployer
CI/CD service account
Deployer
Engineering manager / stakeholder
Viewer
Account roles vs. collection membership
Bluebricks separates what a user can do (account-level role) from where they can do it (collection membership).
Account-level role: Assigned in Account Settings > Users. Defines the user's permissions across the entire organization. A user has exactly one account role.
Collection membership: Assigned in Collection Settings > Members. Determines which collections a user can access and whether they are an owner or member of that collection.
Both layers must align for a user to act on a resource. Non-admin users must be assigned to a collection before they can act on its resources; without collection membership, requests will be rejected regardless of the user's account role. For example, a user with the Builder role can create packages, but they can only deploy to collections where they are an assigned member.
Admins can manage any collection, even if they are not listed as a member or owner of that collection.
How the layers work together
Platform lead needs full control
Admin
Owner
Full access to the organization
Engineer authors IaC for a team
Builder
Member
Can create and publish packages; can deploy to member collections
CI/CD pipeline deploys to production
Deployer
Member
Can run deployments in member collections; cannot modify packages or settings
Manager reviews infrastructure state
Viewer
Member
Can view all resources in member collections; cannot make changes
What's next?
Last updated
Was this helpful?