## Problem to solve We've limited the number of secrets for a group or a project. However, by default these limits are relatively high (100 secrets for a project, and 500 secrets for a group), and we haven't checked how GitLab and OpenBao respond when we have that many secrets. ## Proposal Check that the Secrets Manager page is responsive and doesn't fail (no timeout error) when a group or project reaches the application limit (500 and 100 secrets, respectively). Suggest new defaults for the application limits, if necessary. To be tested on GitLab CN or CNH with a selected reference architecture. We might leverage the benchmark-openbao CLI to create a large number of secrets in a namespace. ## Further details Limitations were implemented in https://gitlab.com/gitlab-org/gitlab/-/work_items/585572 and https://gitlab.com/gitlab-org/gitlab/-/work_items/585573. See https://docs.gitlab.com/api/settings/ <details> <summary>Click to expand</summary> > | Attribute | Type | Required | Description | > |-----------|------|----------|-------------| > | project_secrets_limit | integer | no | Maximum number of secrets allowed per project in Secrets Manager. Default: 100. To disable the limit, set to 0. Ultimate only. Introduced in GitLab 18.9. | > | group_secrets_limit | integer | no | Maximum number of secrets allowed per group in Secrets Manager. Default: 500. To disable the limit, set to 0. Ultimate only. Introduced in GitLab 18.9. | </details> We've decided not to implementation pagination until we implement secrets search (https://gitlab.com/gitlab-org/gitlab/-/work_items/509187).