> ## Documentation Index
> Fetch the complete documentation index at: https://launchdarkly.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Create private projects with custom roles

<View title="Developer" />

<View title="Federal docs" />

<View title="EU docs" />

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](/docs/home/account/roles/role-actions).

> [!NOTE]
>
> **Account members can't modify what they can't view**
>
> 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.

## Restricting access to all projects

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:

```json title="Restrict access to all projects" lines wrap theme={null}
[
  {
    "effect": "deny",
    "actions": ["*"],
    "resources": ["*"]
  }
]
```

## Granting access to specific projects

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:

```json title="Grant access to specific projects" lines wrap theme={null}
[
  {
    "effect": "allow",
    "actions": ["*"],
    "resources": [
      "proj/project-1",
      "proj/project-2",
      "proj/project-3",
      "proj/project-4"
    ]
  }
]
```

> [!NOTE]
>
> **Read access is project-scoped**
>
> Denying edit actions on an environment or its child resources restricts what members can modify. However, it does not prevent them from viewing resources in that environment. Instead, view access is controlled by the `viewProject` action on the `proj/*` resource. This action applies to all resources in all of the project's environments, including flags, configs, segments, and other resources.