This topic explains how to use custom roles to create private projects or restrict access to projects. It gives examples of how to restrict access to one project, effectively creating a private project for members you choose, how to restrict access to all projects, and how to grant access only to one or some projects.
This topic uses the viewProject action to restrict and grant access to projects. To learn more about this action, read Using actions.
Viewing access is required to modify a resource, so if a member cannot view a resource, they also cannot modify it in any way. You can use the policies below to control who can access and modify the feature flags or other child resources in a project.
This example policy forbids access to all projects. It is equivalent to the LaunchDarkly Member project role, and to the No access base role. It is also equivalent to an empty policy. By default, new roles cannot take any actions on any resources.
The following code sample restricts view and edit access to all projects:
By default, new roles cannot take any actions on any resources. However, roles created prior to October 2024 had the option to use the Reader base role as their starting point, rather than starting with no access.
To check whether this applies to any of your existing roles, edit the role and look for the warning statement “This role currently has base permissions set to Reader. Members can view all LaunchDarkly content.” Uncheck the box to update the role so that it starts with no access and only allows actions based on the statements in its policy.
You can restrict teams or members to their own project-based workspace by allowing them access to only one project.
The example below allows access to the specific projects listed in the resources parameter: