From bd649e99c903be620b75b5327e892067d4d46b82 Mon Sep 17 00:00:00 2001 From: Brian MacDonald Date: Wed, 29 Jul 2026 16:47:53 -0400 Subject: [PATCH 1/8] Add documentation for the Projects feature --- docs/cloud/projects.mdx | 115 ++++++++++++++++++++++++++++++++++++++++ sidebars.js | 1 + 2 files changed, 116 insertions(+) create mode 100644 docs/cloud/projects.mdx diff --git a/docs/cloud/projects.mdx b/docs/cloud/projects.mdx new file mode 100644 index 0000000000..5632359ad3 --- /dev/null +++ b/docs/cloud/projects.mdx @@ -0,0 +1,115 @@ +--- +id: projects +title: Projects +sidebar_label: Projects +description: Organize Temporal Cloud resources including Namespaces and Nexus Endpoints around your organizational structure +toc_max_heading_level: 4 +keywords: + - operations + - temporal cloud + - namespaces +tags: + - Projects + - Namespaces + - Nexus + - Nexus Endpoints +--- + +Projects are an organizational container within a Temporal Cloud account that allows you to group related resources into a single operational unit. With Projects, you can organize Namespaces, Nexus endpoints, and Connectivity Rules around how your organization operates: by team, environment, service, business unit, or for usage attribution purposes. Projects allow you to define ownership boundaries for teams, business units, and services within a single Temporal account. This allows for more detailed usage information in billing, and offers greater control as your usage scales. + +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. + +The total number of each Project-level resource is limited within each Project. Projects inherit the current Account-level limits. A Project cannot be set to have higher limits than the Account that contains it. + +| 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 Developer:** Can creating Namespaces and edit other resources in a Project, but without access to see all existing Namespaces in the Project. +- **Project Member:** Access to some specific resource in the Project, without granting any other Project-level access. + +:::warning Project Developer + +The Project Developer role exists for backward compatibility with the Account Developer role. Assigning this role is not recommended. Assign Project Contribute or Project Write instead. + +::: + +Similar to Account-level roles, only a single effective Project role applies to a principal, determined by the highest-precedence role granted. + +A principal's Project-level roles inherit from their Account-level roles, but explicit Project grants can supersede inherited roles. For example, an Account Developer could be explicitly granted Project Admin to a particular Project, which would supersede their inherited Project Developer role. + +Project-level permissions are additive. Addition of Project level roles do not narrow user permissions gained via Account-level or Namespace-level permissions. + +## 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. + + + diff --git a/sidebars.js b/sidebars.js index 20be4e47c9..c0e5dfe7ba 100644 --- a/sidebars.js +++ b/sidebars.js @@ -1305,6 +1305,7 @@ module.exports = { 'cloud/migrate/estimate-actions', ], }, + 'cloud/projects', 'cloud/capacity-modes', 'cloud/worker-health', 'cloud/service-health', From 7c53b7e4b4a84e693bd3ec8674d7fde0ea95991d Mon Sep 17 00:00:00 2001 From: Brian MacDonald Date: Thu, 30 Jul 2026 16:19:25 -0400 Subject: [PATCH 2/8] Apply suggestion from @LutaoX Co-authored-by: Lutao X --- docs/cloud/projects.mdx | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/cloud/projects.mdx b/docs/cloud/projects.mdx index 5632359ad3..232d008aff 100644 --- a/docs/cloud/projects.mdx +++ b/docs/cloud/projects.mdx @@ -15,7 +15,11 @@ tags: - Nexus Endpoints --- -Projects are an organizational container within a Temporal Cloud account that allows you to group related resources into a single operational unit. With Projects, you can organize Namespaces, Nexus endpoints, and Connectivity Rules around how your organization operates: by team, environment, service, business unit, or for usage attribution purposes. Projects allow you to define ownership boundaries for teams, business units, and services within a single Temporal account. This allows for more detailed usage information in billing, and offers greater control as your usage scales. +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. From 5a8f7f45384dd07b5f43f41485a0ee2731f67375 Mon Sep 17 00:00:00 2001 From: Brian MacDonald Date: Thu, 30 Jul 2026 16:20:28 -0400 Subject: [PATCH 3/8] Apply suggestion from @LutaoX Co-authored-by: Lutao X --- docs/cloud/projects.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cloud/projects.mdx b/docs/cloud/projects.mdx index 232d008aff..ece1bf8d08 100644 --- a/docs/cloud/projects.mdx +++ b/docs/cloud/projects.mdx @@ -39,7 +39,7 @@ The total number of Projects in an Account is limited by an adjustable quota, si By default, you can create up to 10 Projects per Account. You can increase this number up to 100 Projects by request. -The total number of each Project-level resource is limited within each Project. Projects inherit the current Account-level limits. A Project cannot be set to have higher limits than the Account that contains it. +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 | | --- | --- | --- | From 113d0d7ebad46410bfaba0182b2e032507d34384 Mon Sep 17 00:00:00 2001 From: Brian MacDonald Date: Thu, 30 Jul 2026 16:28:43 -0400 Subject: [PATCH 4/8] Apply suggestion from @LutaoX Co-authored-by: Lutao X --- docs/cloud/projects.mdx | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/cloud/projects.mdx b/docs/cloud/projects.mdx index ece1bf8d08..1d15b07acc 100644 --- a/docs/cloud/projects.mdx +++ b/docs/cloud/projects.mdx @@ -84,7 +84,6 @@ The following six roles are available at the Project level for users, groups, an - **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 Developer:** Can creating Namespaces and edit other resources in a Project, but without access to see all existing Namespaces in the Project. - **Project Member:** Access to some specific resource in the Project, without granting any other Project-level access. :::warning Project Developer From ce5a8411cdc11391a43b6bc4173116098b756fa4 Mon Sep 17 00:00:00 2001 From: Brian MacDonald Date: Thu, 30 Jul 2026 16:29:10 -0400 Subject: [PATCH 5/8] Apply suggestion from @LutaoX Co-authored-by: Lutao X --- docs/cloud/projects.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cloud/projects.mdx b/docs/cloud/projects.mdx index 1d15b07acc..2a9d98d55d 100644 --- a/docs/cloud/projects.mdx +++ b/docs/cloud/projects.mdx @@ -84,7 +84,7 @@ The following six roles are available at the Project level for users, groups, an - **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:** Access to some specific resource in the Project, without granting any other Project-level access. +**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 :::warning Project Developer From 767ff692672910bdf9bbb34af852cd62faa135c8 Mon Sep 17 00:00:00 2001 From: Brian MacDonald Date: Thu, 30 Jul 2026 16:29:35 -0400 Subject: [PATCH 6/8] Apply suggestion from @LutaoX Co-authored-by: Lutao X --- docs/cloud/projects.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/cloud/projects.mdx b/docs/cloud/projects.mdx index 2a9d98d55d..f1c6a23034 100644 --- a/docs/cloud/projects.mdx +++ b/docs/cloud/projects.mdx @@ -88,7 +88,7 @@ The following six roles are available at the Project level for users, groups, an :::warning Project Developer -The Project Developer role exists for backward compatibility with the Account Developer role. Assigning this role is not recommended. Assign Project Contribute or Project Write instead. +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. ::: From 8f0278d6330514d1990bd09981abc94a7352e09a Mon Sep 17 00:00:00 2001 From: Brian MacDonald Date: Thu, 30 Jul 2026 16:36:46 -0400 Subject: [PATCH 7/8] Apply suggestion from @LutaoX Co-authored-by: Lutao X --- docs/cloud/projects.mdx | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/cloud/projects.mdx b/docs/cloud/projects.mdx index f1c6a23034..043a12ccb0 100644 --- a/docs/cloud/projects.mdx +++ b/docs/cloud/projects.mdx @@ -92,11 +92,9 @@ Project Developer is a compatibility role that is automatically inherited by use ::: -Similar to Account-level roles, only a single effective Project role applies to a principal, determined by the highest-precedence role granted. +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. -A principal's Project-level roles inherit from their Account-level roles, but explicit Project grants can supersede inherited roles. For example, an Account Developer could be explicitly granted Project Admin to a particular Project, which would supersede their inherited Project Developer role. - -Project-level permissions are additive. Addition of Project level roles do not narrow user permissions gained via Account-level or Namespace-level permissions. +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 From 752f06bc7633c5dcaacda71796526eaaf193d252 Mon Sep 17 00:00:00 2001 From: Brian MacDonald Date: Fri, 31 Jul 2026 16:15:48 -0400 Subject: [PATCH 8/8] Updates to Projects docs --- docs/cloud/manage-access/service-accounts.mdx | 9 ++++ docs/cloud/projects.mdx | 51 +++++++++++-------- docs/evaluate/temporal-cloud/limits.mdx | 39 ++++++++++++-- src/constants/featureReleaseTypes.js | 1 + 4 files changed, 75 insertions(+), 25 deletions(-) diff --git a/docs/cloud/manage-access/service-accounts.mdx b/docs/cloud/manage-access/service-accounts.mdx index e840bc4fa1..d93d4df7ad 100644 --- a/docs/cloud/manage-access/service-accounts.mdx +++ b/docs/cloud/manage-access/service-accounts.mdx @@ -17,6 +17,7 @@ tags: import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; +import { ReleaseNoteHeader } from '@site/src/components'; Temporal Cloud provides Account Owner and Global Admin [roles](/cloud/manage-access/users#account-level-roles) with the option to create machine identities named Service Accounts. @@ -236,3 +237,11 @@ Note that the Account Role is omitted, since Namespace-scoped Service Accounts a When a Namespace is deleted, all associated Namespace-scoped Service Accounts and their associated API keys are automatically deleted as well. Therefore, you do not need to manually remove Namespace-scoped Service Accounts and their API keys after deleting a Namespace. + +## Project-scoped Service Accounts + + + +Project-scoped Service Accounts can be created and managed within a Project. Unlike Account-scoped Service Accounts, they can only access resources within their Project, making them useful for workloads that shouldn't have Account-wide permissions. For more information, see [Add resources to a Project](/cloud/projects/#add-resources-to-a-project). diff --git a/docs/cloud/projects.mdx b/docs/cloud/projects.mdx index 043a12ccb0..341071737a 100644 --- a/docs/cloud/projects.mdx +++ b/docs/cloud/projects.mdx @@ -15,14 +15,18 @@ tags: - Nexus Endpoints --- +import { ReleaseNoteHeader } from '@site/src/components'; + + + 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. @@ -33,23 +37,10 @@ If you don't need the organizational boundaries offered by Projects, continue to 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. +For limitations on the number of Projects per Account and number of resources per Project, see [Project-level limitations](/cloud/limits#project-level). + ## 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. @@ -58,10 +49,10 @@ Start with one Project for a team or application with clear ownership. Add more 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. +Click the **Create Project** button to create a new Project. On the **Create Project** page that appears, give the Project a name (limited to 64 characters) and an optional description (limited to 255 characters). 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 +## Add Resources to a Project {/* #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. @@ -73,18 +64,34 @@ The drop-down list on the left lists the available Project Roles. To add a user 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. +The Groups tab works the same way as the Users tab. + +To create a Project-scoped service account in this Project, click **Project Identities** in the left navigation. Then click the **Service Accounts** tab to create Project-scoped service account. + +Project-scoped Service Accounts are not created automatically with Project creation. Create them only when needed. Unlike an Account-scoped Service Account, a Project-scoped Service Account cannot access resources outside its Project. + +Use a Project-scoped Service Account when automation only needs access to one team's resources. If automation needs to work across multiple Projects, use an Account-scoped Service Account instead. + +A Project can contain multiple Project-scoped Service Accounts. Each Project-scoped Service Account belongs to exactly one Project. + +A Project-scoped Service Account cannot be moved to another Project after it is created. + +Project-scoped Service Accounts count toward the Project's Service Account limit. + +A Project cannot be deleted while it contains Project-scoped Service Accounts. + +API keys created for the Service Account inherit only that Service Account's permissions. Deleting a Project-scoped Service Account also deletes its API keys. ## Project roles -The following six roles are available at the Project level for users, groups, and service accounts: +The following 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 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 :::warning Project Developer diff --git a/docs/evaluate/temporal-cloud/limits.mdx b/docs/evaluate/temporal-cloud/limits.mdx index 0055accdbc..d4697d787a 100644 --- a/docs/evaluate/temporal-cloud/limits.mdx +++ b/docs/evaluate/temporal-cloud/limits.mdx @@ -22,6 +22,7 @@ tags: --- import { CaptionedImage } from '@site/src/components'; +import { ReleaseNoteHeader } from '@site/src/components'; Temporal Cloud enforces a variety of limits to keep the service reliable, including rate limits (how often something may occur in a unit of time), resource limits (how many of a given resource may exist at any one time), and configuration limits (minimum or maximum values for a setting) @@ -39,17 +40,49 @@ The following limits apply at the Temporal Cloud Account level (per account). ### Users - Scope: Account -- Default limit: 300 users +- Default limit: 300 Users - How to increase: [Contact support](/cloud/support#support-ticket) +### Projects + +- Scope: Account +- Default limit: 5 Projects +- How to increase: [Contact support](/cloud/support#support-ticket) + ### Namespaces - Scope: Account -- Default limit: 10 namespaces +- Default limit: 10 Namespaces - How to increase: - - Automatically increased as you start creating namespaces + - Automatically increased as you start creating Namespaces - [Contact support](/cloud/support#support-ticket) for large-scale needs +## Project level {/* #project-level */} + + + +The following limits apply at the Project level for any new Project created. The Default Project uses the Account-level resource limits rather than the per-Project defaults shown above. For example, the Default Project inherits the Account's Namespace quota and Account-level limits for Service Accounts, Nexus Endpoints, and Connectivity Rules. + +### Namespaces and Project-scoped Service accounts + +- Scope: Project +- Default: 10 +- How to increase: [Contact support](/cloud/support#support-ticket) + +### Nexus Endpoints + +- Scope: Project +- Default: 5 +- How to increase: [Contact support](/cloud/support#support-ticket) + +### Connectivity rules + +- Scope: Project. Each non-default Project supports up to one Public Connectivity Rule. +- Default: 6 +- How to increase: [Contact support](/cloud/support#support-ticket) + ## Namespace level The following limits apply at the Namespace level. diff --git a/src/constants/featureReleaseTypes.js b/src/constants/featureReleaseTypes.js index e6460ff47d..49ef304d93 100644 --- a/src/constants/featureReleaseTypes.js +++ b/src/constants/featureReleaseTypes.js @@ -7,4 +7,5 @@ export const FEATURE_RELEASE_TYPES = { nexus: "publicPreview", workflowStreams: "publicPreview", serverlessWorkers: "prerelease", + projects: "prerelease", };