Projects
Projects are an organizational layer within a Temporal Cloud Account that groups related resources into a single operational boundary. With Projects, you can organize Namespaces, Nexus endpoints, and Connectivity Rules around how your organization operates: by team, environment, service, or business unit.
Projects make it easier to delegate ownership, manage access at scale, and organize resources without creating additional Cloud Accounts. As your organization grows, Projects help align your Temporal Cloud resources with your organizational structure while reducing operational overhead.
Projects are for organization and authorization. They don't change how Workflows execute inside a Namespace.
Projects are for organization and authorization. They don't change how Workflows execute inside a Namespace.
Default Project and Project names
Every Temporal Cloud Account includes a Default Project. Existing Accounts receive a Default Project when Projects are enabled, and new Accounts are created with one automatically. The Default Project is not a special type of Project. It behaves like any other Project for managing resources. The only difference between the Default Project and any Projects you create is that the Default Project is created for you.
For existing Accounts, all existing resources are automatically placed in the Default Project. All permission resources remain unchanged. For new Accounts, the Default Project is created automatically. New resources are automatically placed in the Default Project unless you specify otherwise.
If you don't need the organizational boundaries offered by Projects, continue to use the Default Project for all your resources. You can always create a new Project later if you need it.
All Projects are identified by immutable IDs, and by display names, which can be edited.
Limitations
The total number of Projects in an Account is limited by an adjustable quota, similar to Namespace quotas.
By default, you can create up to 10 Projects per Account. You can increase this number up to 100 Projects by request.
Each Project has configurable resource limits. New Projects start with the default limits shown below. These limits can be adjusted, but cannot exceed the corresponding Account-level limits.
| Resource | Default | Maximum |
|---|---|---|
| Namespaces | 10 | 5000 |
| Nexus Endpoints | 10 | 100 |
| Connectivity Rules | 5 | 25 |
| Project-scoped Service Accounts | 10 | 1000 |
Namespaces cannot be moved between Projects currently, meaning all existing Namespaces will exist in the Default Project. You can create a new Project and place a new Namespace in that Project.
Create a new Project
Create a Project when a set of resources has a distinct owner or access model, separate from the Default Project. A good Project represents a stable ownership boundary, not just a folder.
Start with one Project for a team or application with clear ownership. Add more only when needed.
In the Temporal UI, click Projects at the top of the left navigation bar, under Your Account. You'll see a list of existing Projects associated with your Account. The first time you use Projects, you'll only see the Default Project in this list.
Click the Create Project button to create a new Project. On the Create Project page that appears, give the Project a name (limited to 39 characters) and an optional description. Click Create and you'll be taken to the page for your new Project. You cannot currently migrate resources from existing Projects to a new Project. Instead, from this page click Create Namespace to add a new Namespace to this Project. To add a Nexus Endpoint instead, click Nexus Endpoints in the left navigation and then click the Create Nexus Endpoint button.
Add Resources to a Project
To add a new Namespace to this Project, click Namespaces in the left navigation, and then click Create Namespace to add a new Namespace.
To add a new Nexus Endpoint to this Project, click Nexus Endpoints in the left navigation, and then click Create Nexus Endpoint to add a new Nexus Endpoint.
To add users, groups, and Service Accounts to the Project, click the Project Identities tab in the left navigation. The Project Identities page has three tabs, for Users, Service Accounts, and Groups. Click the Manage Identities button to add or remove users.
The drop-down list on the left lists the available Project Roles. To add a user to a Role, select the Role from the drop-down, and then type the user's name or email in the search box. The user will be assigned to the Role and their details will appear in the list below. Click Save to save your changes, or Cancel to discard them.
To modify an existing user's role, select the edit button in the list next to their current permission level. You can then update the user's permissions in this Project. Click the trash-can icon to remove Project permissions from that user.
The Service Account and Groups tabs work the same way.
Project roles
The following six roles are available at the Project level for users, groups, and service accounts:
- Project Admin: Complete access to the Project resource itself and all resources in it.
- Project Write: Write access to all the Namespaces and other resources in a Project, but cannot add other users.
- Project Read: Read-only access to all the resources in a Project, including viewing the actual contents of a Workflow.
- Project Contribute: Can create new Namespaces, and list all Project resources, but without access to Workflow contents.
- Project List: List-only access to metadata for all the resources in a Project, but without access to Workflow contents. Project Member: Minimal Project-level access; used when a user already has explicit Namespace-level access and only needs to be represented at the Project level
Project Developer is a compatibility role that is automatically inherited by users with the Account Developer role. It allows them to create Namespaces (and manage them) without automatically granting access to all existing Namespaces in the Project. This role cannot be assigned directly. For new role assignments, assign Project Write or Project Contribute as appropriate.
A principal automatically inherits a Project-level access from their Account-level role. For example, a Global Admin automatically inherits the Project Admin access for every Project in the Account.
Project-level permissions are additive. Granting a Project-level role does not reduce permissions inherited from Account-level or Namespace-level roles. A principal's effective permissions are the union of all applicable Account-, Project-, and Namespace-level role assignments.
Modify an existing Project
To modify an existing Project, click Project Settings in the left navigation. The Project Settings page appears, with the General tab selected by default. Here, you can change the name or description of your Project. You can also access your Project's unique ID. You can copy the ID, but you can't change it.
Delete a Project
To delete a Project, click Project Settings in the left navigation and then click the Delete Project tab. Click the Delete button to permanently delete the Project.
Use the Deletion Prevention slider to set the Deletion Protection flag for this Project. Once set, the Project can't be deleted unless the flag is deliberately disabled.
A Project must be empty, meaning it contains zero Namespaces, to be deleted.
An Account must always contain at least one Project. If the Account contains two or more Projects, you can delete the Default Project. If the Default Project is deleted, Temporal does not automatically designate a new Default Project. If the Default Project is deleted, API calls that do not specify a Project (by providing a Project ID) will fail.
Projects support a delete protection flag, similar to Namespaces. When this flag is enabled, the Project cannot be deleted until the flag is disabled. This flag is enabled for the Default Project. The flag is disabled for any new Project created by a user. This flag is not inherited by the Namespaces within the Project. Namespace delete protection can be managed per-Namespace. If a Project is the only one remaining in an Account, that project cannot be deleted, regardless of the status of the Deletion Protection Flag.