• Default projects limit
  • Projects limit for a user
• Max attachment size
• Max push size
• Max export size
• Max import size
• Personal access token prefix
  • Set a prefix
• Repository size limit
  • How it works
• Customize session duration for Git Operations when 2FA is enabled
• Limit the lifetime of SSH keys
  • Set a lifetime
• Allow expired SSH keys to be used (removed)
• Limit the lifetime of access tokens
  • Set a lifetime
• Allow expired access tokens to be used (removed)
• Disable user profile name changes
• Troubleshooting
  • 413 Request Entity Too Large
  • This repository has exceeded its size limit

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:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General, then expand Account and limit.
3. 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:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Overview > Users.
3. From the list of users, select a user.
4. Select Edit.
5. Increase or decrease the Projects limit value.

Max attachment size

The maximum file size for attachments in GitLab comments and replies is 10 MB. To change the maximum attachment size:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General, then expand Account and limit.
3. Increase or decrease by changing the value in Maximum attachment size (MB).

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:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General, then expand Account and limit.
3. Increase or decrease by changing the value in Maximum push size (MB).

For GitLab.com application limits, read GitLab application limits.

Max export size

To modify the maximum file size for exports in GitLab:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General, then expand Account and limit.
3. Increase or decrease by changing the value in Maximum export size (MB).

Max import size

To modify the maximum file size for imports in GitLab:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General, then expand Account and limit.
3. Increase or decrease by changing the value in Maximum import size (MB).

If you choose a size larger than the configured value for the web server, you may receive errors. See the troubleshooting section for more details.

For GitLab.com repository 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 also inherit this prefix.

Set a prefix

To change the default global prefix:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General.
3. Expand the Account and limit section.
4. Fill in the Personal Access Token prefix field.
5. Click 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.

There are numerous use cases where you might set up a limit for repository size. For instance, consider the following workflow:

1. Your team develops apps which require large files to be stored in the application repository.
2. Although you have enabled Git LFS to your project, your storage has grown significantly.
3. 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:
  1. From the Project’s homepage, navigate to Settings > General.
  2. Fill in the Repository size limit (MB) field in the Naming, topics, avatar section.
  3. Click Save changes.
• Each group’s settings:
  1. From the Group’s homepage, navigate to Settings > General.
  2. Fill in the Repository size limit (MB) field in the Naming, visibility section.
  3. Click Save changes.
• GitLab global settings:
  1. On the top bar, select Menu > Admin.
  2. On the left sidebar, select Settings > General.
  3. Expand the Account and limit section.
  4. Fill in the Size limit per repository (MB) field.
  5. Click 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.

Customize session duration for Git Operations when 2FA is enabled

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:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General.
3. Expand the Account and limit section.
4. Fill in the Session duration for Git operations when 2FA is enabled (minutes) field.
5. Click 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.

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:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General.
3. Expand the Account and limit section.
4. Fill in the Maximum allowable lifetime for SSH keys (days) field.
5. Click 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.
• Applies the lifetime restriction to existing SSH keys. Keys with no expiry or a lifetime greater than the maximum immediately become invalid.

Allow expired SSH keys to be used (removed)

This feature was deprecated in GitLab 14.8. This feature was removed in GitLab 15.0.

Limit the lifetime of access tokens

Users can optionally specify a lifetime for access tokens, this includes personal, group, and project access tokens. This lifetime is not a requirement, and can be set to any arbitrary number of days.

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:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General.
3. Expand the Account and limit section.
4. Fill in the Maximum allowable lifetime for access tokens (days) field.
5. Click 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.

Allow expired access tokens to be used (removed)

This feature was deprecated in GitLab 14.8. This feature was removed in GitLab 15.0.

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:

1. On the top bar, select Menu > Admin.
2. On the left sidebar, select Settings > General, then expand Account and limit.
3. Select the Prevent users from changing their profile name 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 Omnibus GitLab 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 repo size.