- Default projects limit
- Max attachment size
- Max push size
- Personal access token prefix
- Repository size limit
- Session duration
- Require expiration dates for new access tokens
- Allow top-level group Owners to create service accounts
- Limit the lifetime of SSH keys
- Limit the lifetime of access tokens
- User OAuth applications setting
- Disable user profile name changes
- Prevent users from creating organizations
- Prevent new users from creating top-level groups
- Prevent non-members from creating projects and groups
- Allow users to make their profiles private
- Set profiles of new users to private by default
- Prevent users from deleting their accounts
- Troubleshooting
Account and limit settings
Default projects limit
You can configure the default maximum number of projects new users can create in their personal namespace. This limit affects only new user accounts created after you change the setting. This setting is not retroactive for existing users, but you can separately edit the project limits for existing users.
To configure the maximum number of projects in personal namespaces for new users:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Increase or decrease that Default projects limit value.
If you set Default projects limit to 0, users are not allowed to create projects in their users personal namespace. However, projects can still be created in a group.
Projects limit for a user
You can edit a specific user, and change the maximum number of projects this user can create in their personal namespace:
- On the left sidebar, at the bottom, select Admin.
- Select Overview > Users.
- From the list of users, select a user.
- Select Edit.
- Increase or decrease the Projects limit value.
Max attachment size
- Changed from 10 MB to 100 MB in GitLab 15.7.
The maximum file size for attachments in GitLab comments and replies is 100 MB. To change the maximum attachment size:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Increase or decrease by changing the value in Maximum attachment size (MiB).
If you choose a size larger than the configured value for the web server, you may receive errors. Read the troubleshooting section for more details.
For GitLab.com repository size limits, read accounts and limit settings.
Max push size
You can change the maximum push size for your instance:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Increase or decrease by changing the value in Maximum push size (MiB).
For GitLab.com push size limits, read accounts and limit settings.
Personal access token prefix
You can specify a prefix for personal access tokens. You might use a prefix to find tokens more quickly, or for use with automation tools.
The default prefix is glpat-
but administrators can change it.
Project access tokens and group access tokens also inherit this prefix.
Set a prefix
To change the default global prefix:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand the Account and limit section.
- Fill in the Personal access token prefix field.
- Select Save changes.
You can also configure the prefix by using the settings API.
Repository size limit
Repositories in your GitLab instance can grow quickly, especially if you are using LFS. Their size can grow exponentially, rapidly consuming available storage. To prevent this from happening, you can set a hard limit for your repositories’ size. This limit can be set globally, per group, or per project, with per project limits taking the highest priority.
Numerous use cases exist where you might set up a limit for repository size. For instance, consider the following workflow:
- Your team develops apps which require large files to be stored in the application repository.
- Although you have enabled Git LFS to your project, your storage has grown significantly.
- Before you exceed available storage, you set up a limit of 10 GB per repository.
How it works
Only a GitLab administrator can set those limits. Setting the limit to 0
means
there are no restrictions.
These settings can be found in:
- Each project’s settings:
- From the Project’s homepage, go to Settings > General.
- Fill in the Repository size limit (MiB) field in the Naming, topics, avatar section.
- Select Save changes.
- Each group’s settings:
- From the Group’s homepage, go to Settings > General.
- Fill in the Repository size limit (MiB) field in the Naming, visibility section.
- Select Save changes.
- GitLab global settings:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand the Account and limit section.
- Fill in the Size limit per repository (MiB) field.
- Select Save changes.
The first push of a new project, including LFS objects, is checked for size. If the sum of their sizes exceeds the maximum allowed repository size, the push is rejected.
For details on manually purging files, see reducing the repository size using Git.
Session duration
Customize the default session duration
You can change how long users can remain signed in without activity.
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Fill in the Session duration (minutes) field.
- Select Save changes.
-
Restart GitLab to apply the changes.
Setting Session duration (minutes) to0
breaks your GitLab instance. For more information, see issue 19469.
If Remember me is enabled, users’ sessions can remain active for an indefinite period of time.
For details, see cookies used for sign-in.
Turn Remember me on or off
- Ability to turn the Remember me setting on and off introduced in GitLab 16.0.
Users can select the Remember me checkbox on sign-in, and their session remains active for an indefinite period of time when accessed from that specific browser. You can turn off this setting if you need sessions to expire for security or compliance purposes. Turning off this setting ensures users’ sessions expire after the number of minutes of inactivity set when you customize your session duration.
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Select or clear the Remember me checkbox to turn this setting on or off.
Customize session duration for Git Operations when 2FA is enabled
two_factor_for_cli
. On GitLab.com and GitLab Dedicated, this feature is not available. This feature is not ready for production use. This feature flag also affects 2FA for Git over SSH operations.GitLab administrators can choose to customize the session duration (in minutes) for Git operations when 2FA is enabled. The default is 15 and this can be set to a value between 1 and 10080.
To set a limit on how long these sessions are valid:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand the Account and limit section.
- Fill in the Session duration for Git operations when 2FA is enabled (minutes) field.
- Select Save changes.
Require expiration dates for new access tokens
- Introduced in GitLab 17.3.
Prerequisites:
- You must be an administrator.
You can require all new access tokens to have an expiration date. This setting is turned on by default and applies to:
- Project access tokens.
- Group access tokens.
- Personal access tokens for non-service account users.
For personal access tokens for service accounts, use the service_access_tokens_expiration_enforced
setting in the Application Settings API.
To require expiration dates for new access tokens:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Select the Personal / Project / Group access token expiration checkbox.
- Select Save changes.
When you require expiration dates for new access tokens:
- Users must set an expiration date that does not exceed the allowed lifetime for new access tokens.
- To control the maximum access token lifetime, use the Limit the lifetime of access tokens setting.
Allow top-level group Owners to create service accounts
-
Introduced in GitLab 17.5 with a feature flag named
allow_top_level_group_owners_to_create_service_accounts
for GitLab self-managed. Disabled by default.
allow_top_level_group_owners_to_create_service_accounts
. On GitLab.com, this feature is available.By default, in GitLab self-managed, top-level group Owners can not create service accounts. GitLab administrators can allow top-level group Owners to create service accounts.
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Under Service account creation, select the Allow top-level group owners to create Service accounts checkbox.
- Select Save changes.
Limit the lifetime of SSH keys
Users can optionally specify a lifetime for SSH keys. This lifetime is not a requirement, and can be set to any arbitrary number of days.
- Maximum allowable lifetime limit extended to 400 days in GitLab 17.6 with a flag named
buffered_token_expiration_limit
. Disabled by default.
SSH keys are user credentials to access GitLab. However, organizations with security requirements may want to enforce more protection by requiring the regular rotation of these keys.
Set a lifetime
Only a GitLab administrator can set a lifetime. Leaving it empty means there are no restrictions.
To set a lifetime on how long SSH keys are valid:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand the Account and limit section.
- Fill in the Maximum allowable lifetime for SSH keys (days) field.
- Select Save changes.
Once a lifetime for SSH keys is set, GitLab:
- Requires users to set an expiration date that is no later than the allowed lifetime on new SSH keys. The maximum allowed lifetime is:
- 365 days by default.
- 400 days, if you enable the
buffered_token_expiration_limit
feature flag.
- Applies the lifetime restriction to existing SSH keys. Keys with no expiry or a lifetime greater than the maximum immediately become invalid.
Limit the lifetime of access tokens
- Maximum allowable lifetime limit extended to 400 days in GitLab 17.6 with a flag named
buffered_token_expiration_limit
. Disabled by default.
Users can optionally specify a maximum lifetime in days for access tokens, this includes personal, group, and project access tokens. This lifetime is not a requirement, and can be set to any value greater than 0 and less than or equal to:
- 365 days by default.
- 400 days, if you enable the
buffered_token_expiration_limit
feature flag.
If this setting is left blank, the default allowable lifetime of access tokens is:
- 365 days by default.
- 400 days, if you enable the
buffered_token_expiration_limit
feature flag.
Access tokens are the only tokens needed for programmatic access to GitLab. However, organizations with security requirements may want to enforce more protection by requiring the regular rotation of these tokens.
Set a lifetime
Only a GitLab administrator can set a lifetime. Leaving it empty means there are no restrictions.
To set a lifetime on how long access tokens are valid:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand the Account and limit section.
- Fill in the Maximum allowable lifetime for access tokens (days) field.
- Select Save changes.
Once a lifetime for access tokens is set, GitLab:
- Applies the lifetime for new personal access tokens, and require users to set an expiration date and a date no later than the allowed lifetime.
- After three hours, revoke old tokens with no expiration date or with a lifetime longer than the allowed lifetime. Three hours is given to allow administrators to change the allowed lifetime, or remove it, before revocation takes place.
User OAuth applications setting
Prerequisites:
You must be an administrator.
The User OAuth applications setting controls whether users can register applications to use GitLab as an OAuth provider. This setting affects user-owned OAuth application, but does not affect group-level OAuth applications.
To toggle on or off the User OAuth applications setting:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand the Account and limit section.
- Select or clear the User OAuth applications checkbox.
- Select Save changes.
Disable user profile name changes
To maintain integrity of user details in audit events, GitLab administrators can choose to disable a user’s ability to change their profile name.
To do this:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Select the Prevent users from changing their profile name checkbox.
Prevent users from creating organizations
-
Introduced in GitLab 16.7 with a flag named
ui_for_organizations
. Disabled by default.
ui_for_organizations
. On GitLab.com and GitLab Dedicated, this feature is not available. This feature is not ready for production use.By default, users can create organizations. GitLab administrators can prevent users from creating organizations.
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Clear the Allow users to create organizations checkbox.
Prevent new users from creating top-level groups
- Introduced in GitLab 15.5.
By default, new users can create top-level groups. GitLab administrators can prevent new users from creating top-level groups:
- In GitLab 15.5 and later, using either:
- The GitLab UI using the steps in this section.
- The application setting API.
- In GitLab 15.4 and earlier, a configuration file.
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Clear the Allow new users to create top-level groups checkbox.
Prevent non-members from creating projects and groups
- Introduced in GitLab 16.8
By default, users with the Guest role can create projects and groups. GitLab administrators can prevent this behavior:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Clear the Allow users with up to Guest role to create groups and personal projects checkbox.
- Select Save changes.
Allow users to make their profiles private
-
Introduced in GitLab 17.1 with a flag named
disallow_private_profiles
. Disabled by default.
By default, users can make their profiles private. GitLab administrators can disable this setting to prevent users from making their profiles private:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Clear the Allow users to make their profiles private checkbox.
- Select Save changes.
Set profiles of new users to private by default
- Introduced in GitLab 15.8.
By default, newly created users have a public profile. GitLab administrators can set new users to have a private profile by default:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Select the Make new users’ profiles private by default checkbox.
- Select Save changes.
Prevent users from deleting their accounts
-
Introduced in GitLab 16.1 with a flag named
deleting_account_disabled_for_users
. Enabled by default.
By default, users can delete their own accounts. GitLab administrators can prevent users from deleting their own accounts:
- On the left sidebar, at the bottom, select Admin.
- Select Settings > General.
- Expand Account and limit.
- Clear the Allows users to delete their own accounts checkbox.
Troubleshooting
413 Request Entity Too Large
When attaching a file to a comment or reply in GitLab displays a 413 Request Entity Too Large
error, the max attachment size
is probably larger than the web server’s allowed value.
To increase the max attachment size to 200 MB in a
Linux package install, you may need to
add the line below to /etc/gitlab/gitlab.rb
before increasing the max attachment size:
nginx['client_max_body_size'] = "200m"
This repository has exceeded its size limit
If you receive intermittent push errors in your Rails exceptions log, like this:
Your push has been rejected, because this repository has exceeded its size limit.
Housekeeping tasks may be causing your repository size to grow. To resolve this problem, either of these options helps in the short- to middle-term:
- Increase the repository size limit.
- Reduce the repository size.