Managing RDE access
Access to Remote Dev Environments is granted per workspace member. Being a member of a workspace that has RDE isn't enough on its own: until someone grants you access, the Remote Dev Environments section doesn't open for you.
Remote Dev Environments is a beta product. The features, APIs, and clients described here can change, and breaking changes can happen without prior notice. Don't rely on RDE for production-critical workflows yet.
RDE access overviewClick to copy link
RDE is a standalone product. Unlike Bitrise CI and Release Management, its access isn't tied to projects: it's a single on-or-off setting that applies to the whole workspace. There's nothing to configure per project, and no role to choose.
- Granting access assigns the RDE User role on the workspace. That's the only RDE role.
- Admin access to projects doesn't include RDE. It has to be granted separately.
- Workspace owners always have access.
Everyone with the RDE User role can create and manage their own sessions, templates, and saved inputs.
Only workspace owners and workspace managers can grant or revoke RDE access. For the full picture of workspace roles, see Roles and permissions in workspaces.
You can grant access in three places, all on the Collaboration page of the workspace settings:
- To an existing member: Granting access to a member.
- To a whole workspace group: Granting access to a group.
- To someone you're inviting: Adding members to workspaces.
If your workspace provisions users through an identity provider, you can assign the role automatically: Managing RDE access with SCIM.
Granting access to a memberClick to copy link
-
Log in to Bitrise and hover over the left navigation bar.
-
Make sure you have the right workspace selected in the Workspace menu.
-
Select Settings.
-
On the left, select Collaboration.
-
On the Members tab, find the member and click the options menu (⋮) next to their name, then select View details.
-
On the Overview tab, click Manage access.
-
Under Standalone products, turn on Remote Dev Environments.
-
Click Save changes.
The member gets the RDE User role and can open the Remote Dev Environments section right away.
The Standalone products section shows up when you manage access across all projects. It isn't part of the per-project Change access flow, because RDE access isn't project-specific.
Granting access to a groupClick to copy link
Every member of the group inherits the access, including people you add to the group later.
- Existing group
- New group
-
Log in to Bitrise and hover over the left navigation bar.
-
Make sure you have the right workspace selected in the Workspace menu.
-
Select Settings.
-
On the left, select Collaboration.
-
Select the Groups tab and find the group you need.
-
Open the group's details and click Manage access.
-
Under Standalone products, turn on Remote Dev Environments.
-
Click Save changes.
-
Log in to Bitrise and hover over the left navigation bar.
-
Make sure you have the right workspace selected in the Workspace menu.
-
Select Settings.
-
On the left, select Collaboration.
-
Select the Groups tab and click Create group.
-
Enter a group name in the Group name field.
-
Under Standalone products, turn on Remote Dev Environments.
-
Click Create group.
Checking who has accessClick to copy link
The workspace settings show RDE access in a few places:
| Location | What you'll see |
|---|---|
| Workspace settings > Collaboration > Members tab | Remote Dev Environments listed in each member's Product access column. Members without any product access show (no access). |
| Workspace settings > Collaboration > Members tab > options menu (⋮) > View details > Overview tab | A Product access table with a Remote Dev Environments row and the RDE User tag. |
| Workspace settings > Collaboration > Groups tab | The RDE User role on each group. Filter the list by that role to see every group with access. |
Revoking accessClick to copy link
Revoking access doesn't delete the person's sessions. Terminated sessions keep their persistent disk until the usual cleanup, and running sessions keep running until they auto-terminate.
If a member still has RDE access after you revoke it directly, check their Groups tab: a group they belong to may grant it. Remove them from that group, or turn off RDE for the group.
- Member
- Group
-
Log in to Bitrise and hover over the left navigation bar.
-
Make sure you have the right workspace selected in the Workspace menu.
-
Select Settings.
-
On the left, select Collaboration.
-
On the Members tab, find the member and click the options menu (⋮) next to their name, then select View details.
-
On the Overview tab, click Manage access.
-
Under Standalone products, turn off Remote Dev Environments.
-
Click Save changes.
-
Log in to Bitrise and hover over the left navigation bar.
-
Make sure you have the right workspace selected in the Workspace menu.
-
Select Settings.
-
On the left, select Collaboration.
-
Select the Groups tab and find the group you need.
-
Open the group's details and click Manage access.
-
Under Standalone products, turn off Remote Dev Environments.
-
Click Save changes.
Managing RDE access with SCIMClick to copy link
If your workspace uses SCIM provisioning, your identity provider can assign the RDE User role with the standard roles attribute. The value is rde:rde_admin:
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"roles": [
{ "value": "workspace:workspace_contributor" },
{ "value": "rde:rde_admin" }
]
}
Sending a roles array without an rde: entry removes the user's RDE access. For the request formats each identity provider uses, see Configuring SCIM.