GitLab application limits

{{< details >}}

• Tier: Free, Premium, Ultimate
• Offering: GitLab Self-Managed

{{< /details >}}

GitLab, like most large applications, enforces limits in certain features to maintain a minimum quality of performance. Allowing some features to be limitless could affect security, performance, data, or could even exhaust the allocated resources for the application.

Instance configuration

In the instance configuration page, you can find information about some of the settings that are used in your current GitLab instance.

Depending on which limits you have configured, you can see:

• SSH host keys information
• CI/CD limits
• GitLab Pages limits
• Package registry limits
• Rate limits
• Size limits

Because this page is visible to everybody, unauthenticated users only see the information that is relevant to them.

To visit the instance configuration page:

1. In the left sidebar, select Help ({{< icon name="question-o" >}}) > Help.
2. On the Help page, select Check the current instance configuration.

The direct URL is <gitlab_url>/help/instance_configuration. For GitLab.com, you can visit https://gitlab.com/help/instance_configuration.

Rate limits

Rate limits can be used to improve the security and durability of GitLab.

Read more about configuring rate limits.

Issue creation

This setting limits the request rate to the issue creation endpoint.

Read more about issue creation rate limits.

• Default rate limit: Disabled by default.

By User or IP

This setting limits the request rate per user or IP.

Read more about User and IP rate limits.

• Default rate limit: Disabled by default.

By raw endpoint

These settings limit the request rate on raw endpoints.

Read more about raw endpoint rate limits.

• Default rate limit (authenticated and unauthenticated): 300 requests per minute, per project and file path.
• Default rate limit (unauthenticated): 800 requests per minute, per project across all file paths.

By protected path

This setting limits the request rate on specific paths.

GitLab rate limits the following paths for POST requests by default:

'/users/password',
'/users/sign_in',
'/api/#{API::API.version}/session.json',
'/api/#{API::API.version}/session',
'/users',
'/users/confirmation',
'/unsubscribes/',
'/import/github/personal_access_token',
'/admin/session'

GitLab rate limits the following paths for GET requests by default:

'/users/sign_in_path'

Read more about protected path rate limits.

• Default rate limit: After 10 requests, the client must wait 60 seconds before trying again.

Package registry

This setting limits the request rate on the Packages API per user or IP. For more information, see package registry rate limits.

• Default rate limit: Disabled by default.

Git LFS

This setting limits the request rate on the Git LFS requests per user. For more information, read GitLab Git Large File Storage (LFS) Administration.

• Default rate limit: Disabled by default.

Files API

This setting limits the request rate on the Files API per user or IP address. For more information, read Files API rate limits.

• Default rate limit: Disabled by default.

Deprecated API endpoints

This setting limits the request rate on deprecated API endpoints per user or IP address. For more information, read Deprecated API rate limits.

• Default rate limit: Disabled by default.

Import and export

These settings limit file imports and exports for groups and projects.

These settings can be configured.

Direct transfer migration

{{< history >}}

• Maximum number of migrations permitted limit introduced in GitLab 15.9.
• Configurable settings introduced in GitLab 16.3.
• Eight hour time limit on migrations removed in GitLab 16.7.

{{< /history >}}

The following limits apply on migration by direct transfer.

For more information on changing configurable limits, see import and export settings.

Member Invitations

Limit the maximum daily member invitations allowed per group hierarchy.

• GitLab.com: Free members may invite 20 members per day, Premium trial and Ultimate trial members may invite 50 members per day.
• GitLab Self-Managed: Invites are not limited.

Webhook rate limit

Limit the number of times each minute that webhooks in a top-level namespace can be called. All project and group webhooks in the namespace share this limit.

Calls that exceed the rate limit are logged in auth.log.

To set this limit for a GitLab Self-Managed instance, use the Plan Limits API or run the following in the GitLab Rails console:

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(web_hook_calls: 10)

Set the limit to 0 to disable it.

• Default rate limit: Disabled (unlimited).

Search rate limit

{{< history >}}

• Changed in GitLab 15.9 to include issue, merge request, and epic searches in the rate limit.
• Changed in GitLab 16.0 to apply rate limits to search scopes for authenticated requests.

{{< /history >}}

This setting limits search requests as follows:

Search requests that exceed the search rate limit per minute return the following error:

This endpoint has been requested too many times. Try again later.

Autocomplete users rate limit

{{< history >}}

• Introduced in GitLab 17.10 with a flag named autocomplete_users_rate_limit. Disabled by default.
• Generally available in GitLab 18.1. Feature flag autocomplete_users_rate_limit removed.

{{< /history >}}

This setting limits autocomplete users requests as follows:

Autocomplete requests that exceed the autocomplete rate limit per minute return the following error:

This endpoint has been requested too many times. Try again later.

Pipeline creation rate limit

{{< history >}}

• Introduced in GitLab 15.0.

{{< /history >}}

This setting limits the request rate to the pipeline creation endpoints.

Read more about pipeline creation rate limits.

Gitaly concurrency limit

Clone traffic can put a large strain on your Gitaly service. To prevent such workloads from overwhelming your Gitaly server, you can set concurrency limits in the Gitaly configuration file.

Read more about Gitaly concurrency limits.

• Default rate limit: Disabled.

Number of comments per issue, merge request, or commit

There's a limit to the number of comments that can be submitted on an issue, merge request, or commit. When the limit is reached, system notes can still be added so that the history of events is not lost, but the user-submitted comment fails.

• Max limit: 5,000 comments.

Size of comments and descriptions of issues, merge requests, and epics

There is a limit to the size of comments and descriptions of issues, merge requests, and epics. Attempting to add a body of text larger than the limit, results in an error, and the item is also not created.

It's possible that this limit changes to a lower number in the future.

• Max size: ~1 million characters / ~1 MB.

Size of commit titles and descriptions

Commits with arbitrarily large messages may be pushed to GitLab, but the following display limits apply:

• Title - The first line of the commit message. Limited to 1 KiB.
• Description - The rest of the commit message. Limited to 1 MiB.

When a commit is pushed, GitLab processes the title and description to replace references to issues (#123) and merge requests (!123) with links to the issues and merge requests.

When a branch with a large number of commits is pushed, only the last 100 commits are processed.

Size during rebase operations

When you rebase commits, commit messages that exceed the size limit are truncated. This limit is separate from the size limits for commit titles and descriptions.

• Limit: 10,240 bytes (10 KB).

Number of issues in the milestone overview

The maximum number of issues loaded on the milestone overview page is 500. When the number exceeds the limit the page displays an alert and links to a paginated issue list of all issues in the milestone.

• Limit: 500 issues.

Retention of activity history

Activity history for projects and individuals' profiles is limited to three years.

Number of embedded metrics

There is a limit when embedding metrics in GitLab Flavored Markdown (GLFM) for performance reasons.

• Max limit: 100 embeds.

HTTP response limits

Maximum Gzip-compressed size

{{< history >}}

• Introduced in GitLab 17.10.

{{< /history >}}

This setting restricts the maximum allowed size in MiB for Gzip-compressed HTTP responses after decompression.

The default maximum size is 100 MiB. To disable this limit, set the value to 0.

You can change this limit by using the GitLab Rails console or use application setting API

ApplicationSetting.update(max_http_decompressed_size: 50)

Maximum HTTP responses size from outbound requests

{{< history >}}

• Introduced in GitLab 17.10.

{{< /history >}}

This setting restricts the maximum allowed size in MiB for decompressed HTTP responses. It applies to integrations, importers, and webhooks.

The default maximum size is 100 MiB. To disable this limit, set the value to 0.

You can change this limit by using the GitLab Rails console or use application setting API

ApplicationSetting.update(max_http_response_size_limit: 60)

Maximum allowed object count in JSON HTTP responses from outbound requests

{{< history >}}

• Introduced in GitLab 18.4.

{{< /history >}}

This setting restricts the maximum allowed object count in JSON HTTP responses from outbound requests. The number of objects is estimated based on the number of occurrences of :, ,, {, and [ in the response.

The default maximum count is 1,000,000 objects. To disable this limit, set the value to 0.

You can change this limit by using the GitLab Rails console or use the application setting API:

ApplicationSetting.update(max_http_response_json_structural_chars: 500000)

Maximum allowed nesting depth in JSON HTTP responses from outbound requests

{{< history >}}

• Introduced in GitLab 18.4.

{{< /history >}}

This setting restricts the maximum allowed nesting depth in JSON HTTP responses from outbound requests.

The default maximum nesting depth is 32.

You can change this limit by using the GitLab Rails console or use the application setting API:

ApplicationSetting.update(max_http_response_json_depth: 100)

Maximum allowed object count in XML HTTP responses from outbound requests

{{< history >}}

• Introduced in GitLab 18.4.

{{< /history >}}

This setting restricts the maximum allowed object count in XML HTTP responses from outbound requests. The number of objects is estimated based on the number of occurrences of <, = in the response.

The default maximum count is 250,000 objects. To disable this limit, set the value to 0.

You can change this limit by using the GitLab Rails console or use the application setting API:

ApplicationSetting.update(max_http_response_xml_structural_chars: 500000)

Maximum allowed object count in CSV HTTP responses from outbound requests

{{< history >}}

• Introduced in GitLab 18.4.

{{< /history >}}

This setting restricts the maximum allowed object count in CSV HTTP responses from outbound requests. The number of objects is estimated based on the number of occurrences of ,, ;, \t, \r, and \n in the response.

The default maximum count is 250,000 objects. To disable this limit, set the value to 0.

You can change this limit by using the GitLab Rails console or use the application setting API:

ApplicationSetting.update(max_http_response_csv_structural_chars: 500000)

HTTP request limits

By default, JSON parameters in requests are limited. For more information, see JSON validation limits by endpoint.

{{< tabs >}}

{{< tab title="Linux package (Omnibus)" >}}

To disable this check:

1. Set the GITLAB_JSON_GLOBAL_VALIDATION_MODE environment variable on all nodes that run Puma:

   shellCopy

   sudo -e /etc/gitlab/gitlab.rb
   

   rubyCopy

   gitlab_rails['env'] = { 'GITLAB_JSON_GLOBAL_VALIDATION_MODE' => 'disabled' }
   

2. Reconfigure the updated nodes for the change to take effect:

   shellCopy

   sudo gitlab-ctl reconfigure
   

{{< /tab >}}

{{< tab title="Helm chart (Kubernetes)" >}}

To disable this check, you can use --set gitlab.webservice.extraEnv.GITLAB_JSON_GLOBAL_VALIDATION_MODE="disabled", or specify the following in your values file:

gitlab:
  webservice:
    extraEnv:
      GITLAB_JSON_GLOBAL_VALIDATION_MODE: "disabled"

{{< /tab >}}

{{< /tabs >}}

JSON validation limits by endpoint

Some API endpoints have specific JSON validation limits.

Footnotes:

1. The Terraform state max size limit can be set by using the application settings API to set max_terraform_state_size_bytes.

Environment variable configuration

The following environment variables modify the default limits and the validation modes:

The GITLAB_JSON_GLOBAL_VALIDATION_MODE environment variable can be set to one of these modes.

When using GITLAB_JSON_GLOBAL_VALIDATION_MODE:

• Route-specific configurations override default limits but not the global validation mode.
• When limits are exceeded in enforced mode, the response is HTTP 400 with a JSON error message.
• Total elements count includes all elements in arrays and hashes throughout the entire JSON structure.

Webhook limits

Also see Webhook rate limits.

Number of webhooks

To set the maximum number of group or project webhooks for a GitLab Self-Managed instance, run the following in the GitLab Rails console:

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

# For project webhooks
Plan.default.actual_limits.update!(project_hooks: 200)

# For group webhooks
Plan.default.actual_limits.update!(group_hooks: 100)

Set the limit to 0 to disable it.

The default maximum number of webhooks is 100 per project and 50 per group. Webhooks in a subgroup do not count towards the webhook limit of their parent group.

For GitLab.com, see the webhook limits for GitLab.com.

Webhook payload size

The maximum webhook payload size is 25 MB.

Webhook timeout

The number of seconds GitLab waits for an HTTP response after sending a webhook.

To change the webhook timeout value:

1. Edit /etc/gitlab/gitlab.rb on all GitLab nodes that are running Sidekiq:

   rubyCopy

   gitlab_rails['webhook_timeout'] = 60
   

2. Save the file.

3. Reconfigure and restart GitLab for the changes to take effect:

   shellCopy

   gitlab-ctl reconfigure
   gitlab-ctl restart
   

See also webhook limits for GitLab.com.

Recursive webhooks

GitLab detects and blocks webhooks that are recursive or that exceed the limit of webhooks that can be triggered from other webhooks. This enables GitLab to continue to support workflows that use webhooks to call the API non-recursively, or that do not trigger an unreasonable number of other webhooks.

Recursion can happen when a webhook is configured to make a call to its own GitLab instance (for example, the API). The call then triggers the same webhook and creates an infinite loop.

The maximum number of requests to an instance made by a series of webhooks that trigger other webhooks is 100. When the limit is reached, GitLab blocks any further webhooks that would be triggered by the series.

Blocked recursive webhook calls are logged in auth.log with the message "Recursive webhook blocked from executing".

Import placeholder user limits

{{< history >}}

• Introduced in GitLab 17.4.

{{< /history >}}

The number of placeholder users created during an import can be limited per top-level namespace.

The default limit for GitLab Self-Managed is 0 (unlimited).

To change this limit for a GitLab Self-Managed instance, run the following in the GitLab Rails console:

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(import_placeholder_user_limit_tier_1: 200)

Set the limit to 0 to disable it.

Pull mirroring interval

The minimum wait time between pull refreshes defaults to 300 seconds (5 minutes). For example, a pull refresh only runs once in a given 300 second period, regardless of how many times you trigger it.

This setting applies in the context of pull refreshes invoked by using the projects API, or when forcing an update by selecting Update now ({{< icon name="retry" >}}) in Settings > Repository > Mirroring repositories. This setting has no effect on the automatic 30 minute interval schedule used by Sidekiq for pull mirroring.

To change this limit for a GitLab Self-Managed instance, run the following in the GitLab Rails console:

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(pull_mirror_interval_seconds: 200)

Incoming emails from auto-responders

GitLab ignores all incoming emails sent from auto-responders by looking for the X-Autoreply header. Such emails don't create comments on issues or merge requests.

Amount of data sent from Sentry through Error Tracking

{{< history >}}

• Limiting all Sentry responses introduced in GitLab 15.6.

{{< /history >}}

Sentry payloads sent to GitLab have a 1 MB maximum limit, both for security reasons and to limit memory consumption.

Max offset allowed by the REST API for offset-based pagination

When using offset-based pagination in the REST API, there is a limit to the maximum requested offset into the set of results. This limit is only applied to endpoints that also support keyset-based pagination. More information about pagination options can be found in the API documentation section on pagination.

To set this limit for a GitLab Self-Managed instance, run the following in the GitLab Rails console:

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(offset_pagination_limit: 10000)

• Default offset pagination limit: 50000.

Set the limit to 0 to disable it.

GitLab Pages limits

Number of files per GitLab Pages website

The total number of file entries (including directories and symlinks) is limited to 200,000 per GitLab Pages website.

This is the default limit for GitLab Self-Managed and GitLab.com.

To update the limit in your GitLab Self-Managed instance, use the GitLab Rails console. For example, to change the limit to 100:

Plan.default.actual_limits.update!(pages_file_entries: 100)

Number of custom domains per GitLab Pages website

The total number of custom domains per GitLab Pages website is limited to 150 for GitLab.com.

The default limit for GitLab Self-Managed is 0 (unlimited). To set a limit on your instance, use the Admin area.

Number of parallel Pages deployments

When using parallel Pages deployments, the total number of parallel Pages deployments permitted for a top-level namespace is 1000.

When a project has a unique domain enabled, the project's unique domain is treated as its own top-level namespace with a separate limit of 1000 deployments.

Instance monitoring and metrics

Limit inbound incident management alerts

This setting limits the number of inbound alert payloads over a period of time.

Read more about incident management rate limits.

Prometheus Alert JSON payloads

Prometheus alert payloads sent to the notify.json endpoint are limited to 1 MB in size.

Generic Alert JSON payloads

Alert payloads sent to the notify.json endpoint are limited to 1 MB in size.

Environment Dashboard limits

{{< details >}}

• Tier: Premium, Ultimate
• Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

{{< /details >}}

See Environment Dashboard for the maximum number of displayed projects.

Environment data on deploy boards

Deploy boards load information from Kubernetes about Pods and Deployments. However, data over 10 MB for a certain environment read from Kubernetes aren't shown.

Merge requests

Diff limits

GitLab has limits around:

• The patch size for a single file. This is configurable on GitLab Self-Managed.
• The total size of all the diffs for a merge request.

An upper and lower limit applies to each of these:

• The number of changed files.
• The number of changed lines.
• The cumulative size of the changes displayed.

The lower limits result in additional diffs being collapsed. The higher limits prevent any more changes from rendering. For more information about these limits, read the GitLab development documentation about working with diffs.

Diff version limit

{{< history >}}

• Introduced in GitLab 17.10 with a flag named merge_requests_diffs_limit. Disabled by default.
• Enabled on GitLab.com in GitLab 17.10.
• Generally available in GitLab 19.0. Feature flag merge_requests_diffs_limit removed.

{{< /history >}}

GitLab limits each merge request to 1000 diff versions. Merge requests that reach this limit cannot be updated further. Instead, close the affected merge request and create a new merge request.

To configure this limit, see diff limits administration.

Merge request reports size limit

Reports that go over the 20 MB limit aren't loaded. Affected reports:

• Merge request security reports
• CI/CD parameter artifacts:expose_as
• Unit test reports

Advanced search limits

Maximum file size indexed

You can set a limit on the content of repository files that are indexed in Elasticsearch. Any files larger than this limit only index the filename. The file content is neither indexed nor searchable.

Setting a limit helps reduce the memory usage of the indexing processes and the overall index size. This value defaults to 1024 KiB (1 MiB) as any text files larger than this likely aren't meant to be read by humans.

You must set a limit because unlimited file sizes aren't supported. Setting this value to be greater than the amount of memory on GitLab Sidekiq nodes causes the GitLab Sidekiq nodes to run out of memory because this amount of memory is pre-allocated during indexing.

Maximum field length

You can set a limit on the content of text fields indexed for advanced search. Setting a maximum helps to reduce the load of the indexing processes. If any text field exceeds this limit, then the text is truncated to this number of characters. The rest of the text is not indexed, and not searchable. This applies to all indexed data except repository files that get indexed, which have a separate limit. For more information, read Maximum file size indexed.

• On GitLab.com, the field length limit is 20,000 characters.
• For GitLab Self-Managed instances, the field length is unlimited by default.

You can configure this limit for GitLab Self-Managed instances when you enable Elasticsearch. Set the limit to 0 to disable it.

Math rendering limits

{{< history >}}

• Introduced in GitLab 16.5.
• Removed the 50-node limit from Wiki and repository files.
• Added a group-level setting to allow disabling math rendering limits, and re-enabled by default the math limits for wiki and repository files in GitLab 16.9.

{{< /history >}}

GitLab imposes default limits when rendering math in Markdown fields. These limits provide better security and performance.

The limits for issues, merge requests, epics, wikis, and repository files:

• Maximum number of macro expansions: 1000.
• Maximum user-specified size in em: 20.
• Maximum number of nodes rendered: 50.
• Maximum number of characters in a math block: 1000.
• Maximum rendering time: 2000 ms.

You can disable these limits when you run GitLab Self-Managed and trust the user input.

Use the GitLab Rails console:

ApplicationSetting.update(math_rendering_limits_enabled: false)

These limits can also be disabled per-group using the GraphQL or REST API.

If the limits are disabled, math is rendered with mostly no limits in issues, merge requests, epics, wikis, and repository files. This means a malicious actor could add math that would cause a DoS when viewing in the browser. You must ensure that only people you trust can add content.

Wiki limits

• Wiki page content size limit.
• Length restrictions for file and directory names.

Snippets limits

See the documentation about Snippets settings.

Design Management limits

See the limits in the Add a design to an issue section.

Push Event Limits

Max push size

The maximum allowed push size.

Not set by default on GitLab Self-Managed. For GitLab.com, see Account and limit settings

Webhooks and Project Services

Total number of changes (branches or tags) in a single push. If changes are more than the specified limit, hooks are not executed.

For more information, see:

• Webhook push events
• Push hook limit for project integrations

Activities

Total number of changes (branches or tags) in a single push to determine whether individual push events or a bulk push event are created.

More information can be found in the Push event activities limit and bulk push events documentation.

Package registry limits

File size limits

The default maximum file size for a package that's uploaded to the GitLab package registry varies by format:

• Conan: 3 GB
• Generic: 5 GB
• Helm: 5 MB
• Maven: 3 GB
• npm: 500 MB
• NuGet: 500 MB
• PyPI: 3 GB
• Terraform: 1 GB

The maximum file sizes on GitLab.com might be different.

To set these limits for a GitLab Self-Managed instance, you can do it through the Admin area or run the following in the GitLab Rails console:

# File size limit is stored in bytes

# For Conan Packages
Plan.default.actual_limits.update!(conan_max_file_size: 100.megabytes)

# For npm Packages
Plan.default.actual_limits.update!(npm_max_file_size: 100.megabytes)

# For NuGet Packages
Plan.default.actual_limits.update!(nuget_max_file_size: 100.megabytes)

# For Maven Packages
Plan.default.actual_limits.update!(maven_max_file_size: 100.megabytes)

# For PyPI Packages
Plan.default.actual_limits.update!(pypi_max_file_size: 100.megabytes)

# For Debian Packages
Plan.default.actual_limits.update!(debian_max_file_size: 100.megabytes)

# For Helm Charts
Plan.default.actual_limits.update!(helm_max_file_size: 100.megabytes)

# For Generic Packages
Plan.default.actual_limits.update!(generic_packages_max_file_size: 100.megabytes)

Set the limit to 0 to allow any file size.

Package versions returned

When asking for versions of a given NuGet package name, the GitLab package registry returns a maximum of 300 versions.

Dependency Proxy Limits

The maximum file size for an image cached in the Dependency Proxy varies by file type:

• Image blob: 5 GB
• Image manifest: 10 MB

Maximum number of assignees and reviewers

{{< history >}}

• Maximum assignees introduced in GitLab 15.6.
• Maximum reviewers introduced in GitLab 15.9.

{{< /history >}}

Issues and merge requests enforce these maximums:

• Maximum assignees: 200
• Maximum reviewers: 200

Maximum number of project push mirrors

{{< history >}}

• Introduced in GitLab 18.9.

{{< /history >}}

Each project can have a maximum of 10 enabled push mirrors. This limit prevents performance issues from excessive concurrent sync jobs.

If you require more mirrors, you can:

• Disable unused mirrors.
• Consolidate mirrors by combining multiple destinations into a single mirror.

CDN-based limits on GitLab.com

In addition to application-based limits, GitLab.com is configured to use Cloudflare's standard DDoS protection and Spectrum to protect Git over SSH. Cloudflare terminates client TLS connections but is not application aware and cannot be used for limits tied to users or groups. Cloudflare page rules and rate limits are configured with Terraform. These configurations are not public because they include security and abuse implementations that detect malicious activities and making them public would undermine those operations.

Container Repository tag deletion limit

Container repository tags are in the container registry, so each tag deletion triggers network requests to the container registry. Because of this, we limit the number of tags that a single API call can delete to 20.

Project-level Secure Files API limits

The secure files API enforces the following limits:

• Files must be smaller than 5 MB.
• Projects cannot have more than 100 secure files.

Changelog API limits

{{< history >}}

• Introduced in GitLab 15.1 with a flag named changelog_commits_limitation. Disabled by default.
• Enabled on GitLab.com and by default on GitLab Self-Managed in GitLab 15.3.
• Generally available in GitLab 17.3. Feature flag changelog_commits_limitation removed.

{{< /history >}}

The changelog API enforces the following limits:

• The commit range between from and to cannot exceed 15000 commits.

Value Stream Analytics limits

• Each namespace (such as a group or a project) can have a maximum of 50 value streams.
• Each value stream can have a maximum of 15 stages.

Audit events streaming destination limits

Custom HTTP Endpoint

• Each top-level group can have a maximum of 5 custom HTTP streaming destinations.

Google Cloud Logging

• Each top-level group can have a maximum of 5 Google Cloud Logging streaming destinations.

Amazon S3

• Each top-level group can have a maximum of 5 Amazon S3 streaming destinations.

Dependency scanning using SBOM limits

The dependency scanning using SBOM feature uses an internal API with the following limits:

• Maximum number of upload requests per project per hour: 400
• Maximum number of download requests per project per hour: 6000

You can configure these limits for GitLab Self-Managed instances using the dependency scanning settings.

Commits and Files API limits

{{< history >}}

• Introduced in GitLab 18.7.

{{< /history >}}

The Commits and Files APIs enforce maximum size and rate limits on the following endpoints:

• POST /projects/:id/repository/commits - Create a commit
• POST /projects/:id/repository/files/:file_path - Create a file in a repository
• PUT /projects/:id/repository/files/:file_path - Update a file in a repository
• Maximum request size: Requests that exceed this limit receive a 413 Request Entity Too Large error with the following message: RequestBody: upload failed: the upload size <size> is over maximum of 314572800 bytes: entity is too large. The default is 300 MB (314,572,800 bytes).
• Rate limit: 3 requests per 30 seconds for requests above 20 MB.

The maximum request size is configurable on GitLab Self-Managed by setting the GITLAB_COMMITS_MAX_REQUEST_SIZE_BYTES environment variable. This variable sets the maximum request size in bytes. Instructions on how to set an environment variable can be found in HTTP Request Limits.

List all instance limits

To list all instance limit values, run the following from the GitLab Rails console:

Plan.default.actual_limits

Sample output:

id: 1,
plan_id: 1,
ci_pipeline_size: 0,
ci_active_jobs: 0,
project_hooks: 100,
group_hooks: 50,
ci_project_subscriptions: 3,
ci_pipeline_schedules: 10,
offset_pagination_limit: 50000,
ci_instance_level_variables: "[FILTERED]",
storage_size_limit: 0,
ci_max_artifact_size_lsif: 200,
ci_max_artifact_size_archive: 0,
ci_max_artifact_size_metadata: 0,
ci_max_artifact_size_trace: "[FILTERED]",
ci_max_artifact_size_junit: 0,
ci_max_artifact_size_sast: 0,
ci_max_artifact_size_dependency_scanning: 350,
ci_max_artifact_size_container_scanning: 150,
ci_max_artifact_size_dast: 0,
ci_max_artifact_size_codequality: 0,
ci_max_artifact_size_license_management: 0,
ci_max_artifact_size_license_scanning: 100,
ci_max_artifact_size_performance: 0,
ci_max_artifact_size_metrics: 0,
ci_max_artifact_size_metrics_referee: 0,
ci_max_artifact_size_network_referee: 0,
ci_max_artifact_size_dotenv: 0,
ci_max_artifact_size_cobertura: 0,
ci_max_artifact_size_terraform: 5,
ci_max_artifact_size_accessibility: 0,
ci_max_artifact_size_cluster_applications: 0,
ci_max_artifact_size_secret_detection: "[FILTERED]",
ci_max_artifact_size_requirements: 0,
ci_max_artifact_size_coverage_fuzzing: 0,
ci_max_artifact_size_browser_performance: 0,
ci_max_artifact_size_load_performance: 0,
ci_needs_size_limit: 2,
conan_max_file_size: 3221225472,
maven_max_file_size: 3221225472,
npm_max_file_size: 524288000,
nuget_max_file_size: 524288000,
pypi_max_file_size: 3221225472,
generic_packages_max_file_size: 5368709120,
golang_max_file_size: 104857600,
debian_max_file_size: 3221225472,
project_feature_flags: 200,
ci_max_artifact_size_api_fuzzing: 0,
ci_pipeline_deployments: 500,
pull_mirror_interval_seconds: 300,
daily_invites: 0,
rubygems_max_file_size: 3221225472,
terraform_module_max_file_size: 1073741824,
helm_max_file_size: 5242880,
ci_registered_group_runners: 1000,
ci_registered_project_runners: 1000,
ci_daily_pipeline_schedule_triggers: 0,
ci_max_artifact_size_cluster_image_scanning: 0,
ci_jobs_trace_size_limit: "[FILTERED]",
pages_file_entries: 200000,
dast_profile_schedules: 1,
external_audit_event_destinations: 5,
dotenv_variables: "[FILTERED]",
dotenv_size: 5120,
pipeline_triggers: 25000,
project_ci_secure_files: 100,
repository_size: 0,
security_policy_scan_execution_schedules: 0,
web_hook_calls_mid: 0,
web_hook_calls_low: 0,
project_ci_variables: "[FILTERED]",
group_ci_variables: "[FILTERED]",
ci_max_artifact_size_cyclonedx: 1,
rpm_max_file_size: 5368709120,
pipeline_hierarchy_size: 1000,
ci_max_artifact_size_requirements_v2: 0,
enforcement_limit: 0,
notification_limit: 0,
dashboard_limit_enabled_at: nil,
web_hook_calls: 0,
project_access_token_limit: 0,
google_cloud_logging_configurations: 5,
ml_model_max_file_size: 10737418240,
limits_history: {},
audit_events_amazon_s3_configurations: 5

Some limit values display as [FILTERED] in the list due to filtering in the Rails console.