• Max attachment size
• Max import size
• Maximum namespace storage size
• Repository size limit
  • How it works
• Troubleshooting
  • 413 Request Entity Too Large
• Limiting lifetime of personal access tokens
  • Setting a limit
• Optional enforcement of Personal Access Token expiry
  • Enable or disable optional enforcement of Personal Access Token expiry Feature
• Disabling user profile name changes

Account and limit settings

Max attachment size

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

Max import size

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

Maximum namespace storage size

This sets a maximum size limit on each namespace. The following are included in the namespace size:

• repository
• wiki
• LFS objects
• build artifacts
• packages

Repository size limit

Repositories within your GitLab instance can grow quickly, especially if you are using LFS. Their size can grow exponentially, rapidly consuming available storage.

To avoid 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 within:

• 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’s 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, will be checked for size and will be rejected if the sum of their sizes exceeds the maximum allowed repository size.

Note: The repository size limit includes repository files and LFS, and does not include artifacts.

For details on manually purging files, see reducing the repository size using Git.

Troubleshooting

413 Request Entity Too Large

If you are attaching a file to a comment or reply in GitLab and receive the 413 Request Entity Too Large error, it is likely caused by having a max attachment size larger than what the web server is configured to allow.

If you wanted to increase the max attachment size to 200m in a GitLab Omnibus install, for example, you might need to add the line below to /etc/gitlab/gitlab.rb before increasing the max attachment size:

nginx['client_max_body_size'] = "200m"

Limiting lifetime of personal access tokens

Users can optionally specify an expiration date for personal access tokens. This expiration date is not a requirement, and can be set to any arbitrary date.

Since personal access tokens are the only token needed for programmatic access to GitLab, organizations with security requirements may want to enforce more protection to require regular rotation of these tokens.

Setting a limit

Only a GitLab administrator can set a limit. Leaving it empty means there are no restrictions.

To set a limit 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 will:

• Apply 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 Personal Access Token expiry

GitLab administrators can choose to prevent personal access tokens from expiring automatically. The tokens will be usable after the expiry date, unless they are revoked explicitly.

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.

Enable or disable optional enforcement of Personal Access Token expiry Feature

Optional Enforcement of Personal Access Token Expiry is under development and not ready for production use. It is deployed behind a feature flag that is disabled by default. GitLab administrators with access to the GitLab Rails console can enable it for your instance from the rails console.

To enable it:

Feature.enable(:enforce_personal_access_token_expiration)

To disable it:

Feature.disable(:enforce_personal_access_token_expiration)

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.