• Default projects limit
• Max attachment size
• Max push size
• Max import size
• Personal Access Token prefix
  • Setting a prefix
• Repository size limit
  • How it works
• Troubleshooting
  • 413 Request Entity Too Large
• Customize session duration for Git Operations when 2FA is enabled
• Limiting lifetime of personal access tokens
  • Setting a lifetime
• Optional enforcement of SSH key expiration
• Optional non-enforcement of Personal Access Token expiration
• Disabling user profile name changes

Account and limit settings

Default projects limit

You can change the default maximum number of projects that users can create in their personal namespace. Navigate to Admin Area > Settings > General, then expand Account and Limit. You can 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.

Max attachment size

You can change the maximum file size for attachments in comments and replies in GitLab. Navigate to Admin Area > Settings > General, then expand Account and Limit. From here, you can increase or decrease by changing the value in Maximum attachment size (MB).

Max push size

You can change the maximum push size for your repository. Navigate to Admin Area > Settings > General, then expand Account and Limit. From here, you can increase or decrease by changing the value in Maximum push size (MB).

Max import size

You can change the maximum file size for imports in GitLab. Navigate to Admin Area > Settings > General, then expand Account and Limit. From here, you can increase or decrease by changing the value in Maximum import size (MB).

Personal Access Token prefix

You can set a global prefix for all generated Personal Access Tokens.

A prefix can help you identify PATs visually, as well as with automation tools.

Setting a prefix

Only a GitLab administrator can set the prefix, which is a global setting applied to any PAT generated in the system by any user:

1. Navigate to Admin Area > Settings > General.
2. Expand the Account and limit section.
3. Fill in the Personal Access Token prefix field.
4. Click Save changes.

It is also possible to configure the prefix via the settings API using the personal_access_token_prefix field.

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. From the Dashboard, navigate to Admin Area > Settings > General.
  2. Expand the Account and limit section.
  3. Fill in the Size limit per repository (MB) field.
  4. 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.

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"

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. Navigate to Admin Area > Settings > General.
2. Expand the Account and limit section.
3. Fill in the Session duration for Git operations when 2FA is enabled (minutes) field.
4. Click Save changes.

Limiting lifetime of personal access tokens

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

Personal 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.

Setting 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 personal access tokens are valid:

1. Navigate to Admin Area > Settings > General.
2. Expand the Account and limit section.
3. Fill in the Maximum allowable lifetime for personal access tokens (days) field.
4. Click Save changes.

Once a lifetime for personal 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.

Optional enforcement of SSH key expiration

By default, expired SSH keys can still be used. You can prevent the use of expired SSH keys with the following steps:

1. Navigate to Admin Area > Settings > General.
2. Expand the Account and limit section.
3. Select the Enforce SSH key expiration checkbox.

Enforcing SSH key expiration immediately disables all expired SSH keys.

For more information, see the following issue on SSH key expiration.

Optional non-enforcement of Personal Access Token expiration

By default, expired personal access tokens (PATs) cannot be used. You can allow the use of expired PATs with the following steps:

To do this:

1. Navigate to Admin Area > Settings > General.
2. Expand the Account and limit section.
3. Uncheck the Enforce personal access token expiration checkbox.

Disabling 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. Navigate to Admin Area > Settings > General, then expand Account and Limit.
2. Check the Prevent users from changing their profile name checkbox.