These settings are used on GitLab.com, and are available to GitLab SaaS customers.
See some of these settings on the instance configuration page for GitLab.com.
Account and limit settingsGitLab.com uses these account limits. If a setting is not listed, the default value is the same as for GitLab Self-Managed instances:
If you are near or over the repository size limit, you can:
git push and GitLab project imports are limited to 5 GiB for each request through Cloudflare. Imports other than a file upload are not affected by this limit. Repository limits apply to both public and private projects.
To back up an entire project on GitLab.com, you can export it:
With exports, be aware of what is and is not included in a project export.
To back up the Git repository of a project or wiki, clone it to another computer. All files uploaded to a wiki after August 22, 2020 are included when you clone a repository.
CI/CDGitLab.com uses these GitLab CI/CD settings. Any settings or feature limits not listed here use the defaults listed in the related documentation:
Setting GitLab.com Default (GitLab Self-Managed) Artifacts maximum size (compressed) 1 GB See Maximum artifacts size. Artifacts expiry time 30 days unless otherwise specified See Default artifacts expiration. Artifacts created before June 22, 2020 have no expiry. Scheduled Pipeline Cron*/5 * * * * See Pipeline schedules advanced configuration. Maximum jobs in a single pipeline 500 for Free tier, 1000 for all trial tiers, 1500 for Premium, and 2000 for Ultimate. See Maximum number of jobs in a pipeline. Maximum jobs in active pipelines 500 for Free tier, 1000 for all trial tiers, 20000 for Premium, and 100000 for Ultimate. See Number of jobs in active pipelines. Maximum CI/CD subscriptions to a project 2 See Number of CI/CD subscriptions to a project. Maximum number of pipeline triggers in a project 25000 See Limit the number of pipeline triggers. Maximum pipeline schedules in projects 10 for Free tier, 50 for all paid tiers See Number of pipeline schedules. Maximum pipelines for each schedule 24 for Free tier, 288 for all paid tiers See Limit the number of pipelines created by a pipeline schedule each day. Maximum number of schedule rules defined for each security policy project Unlimited for all paid tiers See Number of schedule rules defined for each security policy project. Scheduled job archiving 3 months Never. Jobs created before June 22, 2020 were archived after September 22, 2020. Maximum test cases for each unit test report 500000 Unlimited. Maximum registered runners Free tier: 50 for each group and 50for each project
1000 for each group and 1000 for each project See Number of registered runners for each scope. Limit of dotenv variables Free tier: 50
100
150 See Limit dotenv variables. Maximum downstream pipeline trigger rate (for a given project, user, and commit) 350 each minute See Maximum downstream pipeline trigger rate. Maximum number of downstream pipelines in a pipeline’s hierarchy tree 1000 See Limit pipeline hierarchy size. Container registry Setting GitLab.com GitLab Self-Managed Domain name registry.gitlab.com IP address 35.227.35.254 CDN domain name cdn.registry.gitlab-static.net CDN IP address 34.149.22.116 Authorization token duration (minutes) 15 See increase container registry token duration.
To use the GitLab container registry, Docker clients must have access to:
GitLab.com is fronted by Cloudflare. For incoming connections to GitLab.com, you must allow CIDR blocks of Cloudflare (IPv4 and IPv6).
Diff display limitsThe settings for the display of diff files cannot be changed on GitLab.com.
Setting Definition GitLab.com Maximum diff patch size The total size of the entire diff. 200 KB Maximum diff files The total number of files changed in a diff. 3,000 Maximum diff lines The total number of lines changed in a diff. 100,000Diff limits can be changed in GitLab Self-Managed.
EmailEmail configuration settings, IP addresses, and aliases.
Confirmation settingsGitLab.com uses these email confirmation settings:
email_confirmation_setting is set to Hard.unconfirmed_users_delete_after_days is set to three days.GitLab.com uses Mailgun to send emails from the mg.gitlab.com domain, and has its own dedicated IP addresses:
23.253.183.23669.72.35.19069.72.44.107159.135.226.146161.38.202.219192.237.158.143192.237.159.239198.61.254.136198.61.254.160209.61.151.122The IP addresses for mg.gitlab.com are subject to change at any time.
GitLab.com has a mailbox configured for Service Desk with the email address: contact-project+%{key}@incoming.gitlab.com. To use this mailbox, configure the custom suffix in project settings.
Per-repository Gitaly RPC concurrency and queuing limits are configured for different types of Git operations, like git clone. When these limits are exceeded, a fatal: remote error: GitLab is currently unable to handle this request due to load message is returned to the client.
A fetch or clone operation is concurrent when the operation starts before a previous operation finishes.
Operation GitLab.com limit HTTP fetches and clones 60 concurrent operations SSH fetches and clones 30 concurrent operationsFor administrator documentation, see limit RPC concurrency.
GitLab PagesSome settings for GitLab Pages differ from the defaults for GitLab Self-Managed:
Setting GitLab.com Domain namegitlab.io IP address 35.185.44.232 Support for custom domains check-circle Yes Support for TLS certificates check-circle Yes Maximum site size 1 GB Number of custom domains for each GitLab Pages website 150
The maximum size of your Pages site depends on the maximum artifact size, which is part of the GitLab CI/CD settings.
Rate limits also exist for GitLab Pages.
In addition to the GitLab Enterprise Edition Linux package install, GitLab.com uses the following applications and settings to achieve scale. All settings are publicly available, as Kubernetes configuration or Chef cookbooks.
ConsulService discovery:
Elastic clusterWe use Elasticsearch and Kibana for part of our monitoring solution:
FluentdWe use Fluentd to unify our GitLab logs:
GrafanaFor the visualization of monitoring data:
HAProxyHigh Performance TCP/HTTP Load Balancer:
PrometheusPrometheus complete our monitoring stack:
SentryOpen source error tracking:
GitLab-hosted runnersUse GitLab-hosted runners to run your CI/CD jobs on GitLab.com and GitLab Dedicated to seamlessly build, test, and deploy your application on different environments.
For more information, see GitLab-hosted runners.
Hostname listAdd these hostnames when you configure allow-lists in local HTTP(S) proxies, or other web-blocking software that governs end-user computers. Pages on GitLab.com load content from these hostnames:
gitlab.com*.gitlab.com*.gitlab-static.net*.gitlab.io*.gitlab.netDocumentation and GitLab company pages served over docs.gitlab.com and about.gitlab.com also load certain page content directly from common public CDN hostnames.
GitLab.com uses settings to limit importing data into GitLab.
Default import sourcesThe import sources that are available to you by default depend on which GitLab you use:
Imports into GitLab.com limit the number of placeholder users for each top-level namespace. The limits differ depending on your plan and seat count. For more information, see the table of placeholder user limits for GitLab.com.
IP rangeGitLab.com uses the IP ranges 34.74.90.64/28 and 34.74.226.0/24 for traffic from its Web/API fleet. This whole range is solely allocated to GitLab. Connections from webhooks or repository mirroring come from these IP addresses. You should allow these connections.
Incoming connections - GitLab.com is fronted by Cloudflare. For incoming connections to GitLab.com, allow CIDR blocks of Cloudflare (IPv4 and IPv6).
Outgoing connections from CI/CD runners - We don’t provide static IP addresses for outgoing connections from CI/CD runners. However, these guidelines can help:
us-central1.us-east1.us-east-1 region, with runner managers hosted on Google Cloud.To configure an IP-based firewall, you must allow both AWS IP address ranges and Google Cloud IP address ranges.
See how to look up IP address ranges or CIDR blocks for GCP.
Maximum number of reviewers and assigneesHistory
Merge requests enforce these maximums:
History
merge_requests_diffs_limit. Disabled by default.The availability of this feature is controlled by a feature flag. For more information, see the 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.
Diff commits limitHistory
merge_requests_diff_commits_limit. Disabled by default.The availability of this feature is controlled by a feature flag. For more information, see the history.
GitLab limits each merge request to 1,000,000 (one million) diff commits. Merge requests that reach this limit cannot be updated further. Instead, close the affected merge request and create a new merge request.
Password requirementsGitLab.com sets these requirements for passwords on new accounts and password changes:
~, !, @, #, $, %, ^, &, *, (), [], _, +, =, and -.On GitLab.com, top-level group creation is not available through the API. It must be performed through the UI.
Project and group deletionSettings related to the deletion of projects and groups.
Delayed group deletionHistory
Groups are permanently deleted after a 30-day delay.
See how to view and restore groups marked for deletion.
Delayed project deletionHistory
Projects are permanently deleted after a 30-day delay.
See how to view and restore projects marked for deletion.
Dormant project deletionDormant project deletion is disabled on GitLab.com.
Package registry limitsThe maximum file size for a package uploaded to the GitLab package registry varies by format:
Package type GitLab.com Conan 5 GB Generic 5 GB Helm 5 MB Machine learning model 10 GB (uploads are capped at 5 GB) Maven 5 GB npm 5 GB NuGet 5 GB PyPI 5 GB Terraform 1 GB PumaGitLab.com uses the default of 60 seconds for Puma request timeouts.
Rate limits on GitLab.comSee Rate limits for administrator documentation.
When a request is rate limited, GitLab responds with a 429 status code. The client should wait before attempting the request again. There may also be informational headers with this response detailed in rate limiting responses. Rate limiting responses for the Projects, Groups, and Users APIs do not include informational headers.
The following table describes the rate limits for GitLab.com:
Rate limit Setting Protected paths for an IP address 10 requests each minute Raw endpoint traffic for a project, commit, or file path 300 requests each minute Unauthenticated traffic from an IP address 500 requests each minute Authenticated API traffic for a user 2,000 requests each minute Authenticated non-API HTTP traffic for a user 1,000 requests each minute All traffic from an IP address 2,000 requests each minute Issue creation 200 requests each minute Note creation on issues and merge requests 60 requests each minute Advanced, project, or group search API for an IP address 10 requests each minute GitLab Pages requests for an IP address 1,000 requests every 50 seconds GitLab Pages requests for a GitLab Pages domain 5,000 requests every 10 seconds GitLab Pages TLS connections for an IP address 1,000 requests every 50 seconds GitLab Pages TLS connections for a GitLab Pages domain 400 requests every 10 seconds Pipeline creation requests for a project, user, or commit 25 requests each minute Alert integration endpoint requests for a project 3,600 requests every hour GitLab DuoaiAction requests 160 requests every 8 hours Pull mirroring intervals 5 minutes API requests from a user to /api/v4/users/:id 300 requests every 10 minutes GitLab package cloud requests for an IP address (introduced in GitLab 16.11) 3,000 requests each minute GitLab repository files 500 requests each minute User followers requests (/api/v4/users/:id/followers) 100 requests each minute User following requests (/api/v4/users/:id/following) 100 requests each minute User status requests (/api/v4/users/:user_id/status) 240 requests each minute User SSH keys requests (/api/v4/users/:user_id/keys) 120 requests each minute Single SSH key requests (/api/v4/users/:id/keys/:key_id) 120 requests each minute User GPG keys requests (/api/v4/users/:id/gpg_keys) 120 requests each minute Single GPG key requests (/api/v4/users/:id/gpg_keys/:key_id) 120 requests each minute User projects requests (/api/v4/users/:user_id/projects) 300 requests each minute User contributed projects requests (/api/v4/users/:user_id/contributed_projects) 100 requests each minute User starred projects requests (/api/v4/users/:user_id/starred_projects) 100 requests each minute Projects list requests (/api/v4/projects) 2,000 requests every 10 minutes Group projects requests (/api/v4/groups/:id/projects) 600 requests each minute Single project requests (/api/v4/projects/:id) 400 requests each minute Groups list requests (/api/v4/groups) 200 requests each minute Single group requests (/api/v4/groups/:id) 400 requests each minute
More details are available on the rate limits for protected paths and raw endpoints.
GitLab can rate-limit requests at several layers. The rate limits listed here are configured in the application. These limits are the most restrictive for each IP address.
Group and project import by uploading export filesTo help avoid abuse, GitLab.com uses rate limits:
For more information, see:
IP blocksIP blocks can occur when GitLab.com receives unusual traffic from a single IP address that the system views as potentially malicious. This can be based on rate limit settings. After the unusual traffic ceases, the IP address is automatically released depending on the type of block, as described in a following section.
If you receive a 403 Forbidden error for all requests to GitLab.com, check for any automated processes that may be triggering a block. For assistance, contact GitLab Support with details, such as the affected IP address.
GitLab.com responds with HTTP status code 403 for 15 minutes when a single IP address sends 300 failed authentication requests in a 1-minute period.
This applies only to Git requests and container registry (/jwt/auth) requests (combined).
This limit:
gitlab-ci-token.No response headers are provided.
git requests over https always send an unauthenticated request first, which for private repositories results in a 401 error. git then attempts an authenticated request with a username, password, or access token (if available). These requests might lead to a temporary IP block if too many requests are sent simultaneously. To resolve this issue, use SSH keys to communicate with GitLab.
For more information about non-configurable rate limits used on GitLab.com, see non-configurable limits
For performance reasons, if a query returns more than 10,000 records, GitLab excludes some headers.
Protected paths throttleIf the same IP address sends more than 10 POST requests in a minute to protected paths, GitLab.com returns a 429 HTTP status code.
See the source below for which paths are protected. They include user creation, user confirmation, user sign in, and password reset.
User and IP rate limits includes a list of the headers responded to blocked requests.
See Protected Paths for more details.
Rate limiting responsesFor information on rate limiting responses, see:
SSH maximum number of connectionsGitLab.com defines the maximum number of concurrent, unauthenticated SSH connections by using the MaxStartups setting. If more than the maximum number of allowed connections occur concurrently, they are dropped and users get an ssh_exchange_identification error.
Projects, groups, and snippets have the Internal visibility setting disabled on GitLab.com.
SidekiqGitLab.com runs Sidekiq as an external process for Ruby job scheduling.
The current settings are in the GitLab.com Kubernetes pod configuration.
SSH keys and authenticationSettings related to authentication with SSH. For information about maximum connections, see SSH maximum number of connections.
Alternative SSH portGitLab.com can be reached by using a different SSH port for git+ssh.
Hostname altssh.gitlab.com Port 443
An example ~/.ssh/config is the following:
Host gitlab.com
Hostname altssh.gitlab.com
User git
Port 443
PreferredAuthentications publickey
IdentityFile ~/.ssh/gitlabGo to the current instance configuration to see the SSH host key fingerprints on GitLab.com.
In the instance configuration, you see the SSH host key fingerprints:
Algorithm MD5 (deprecated) SHA256 ECDSAf1:d0:fb:46:73:7a:70:92:5a:ab:5d:ef:43:e2:1c:35 SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw ED25519 2e:65:6a:c8:cf:bf:b2:8b:9a:bd:6d:9f:11:5c:12:16 SHA256:eUXGGm1YGsMAS7vkcx6JOJdOGHPem5gQp4taiCfCLB8 RSA b6:03:0e:39:97:9e:d0:e7:24:ce:a3:77:3e:01:42:09 SHA256:ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ
The first time you connect to a GitLab.com repository, one of these keys is displayed in the output.
SSH key restrictionsGitLab.com uses the default SSH key restrictions.
SSHknown_hosts entries
To skip manual fingerprint confirmation in SSH, add the following to .ssh/known_hosts:
gitlab.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf
gitlab.com ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCsj2bNKTBSpIYDEGk9KxsGh3mySTRgMtXL583qmBpzeQ+jqCMRgBqB98u3z++J1sKlXHWfM9dyhSevkMwSbhoR8XIq/U0tCNyokEi/ueaBMCvbcTHhO7FcwzY92WK4Yt0aGROY5qX2UKSeOvuP4D6TPqKF1onrSzH9bx9XUf2lEdWT/ia1NEKjunUqu1xOB/StKDHMoX4/OKyIzuS0q/T1zOATthvasJFoPrAjkohTyaDUz2LN5JoH839hViyEG82yB+MjcFV5MU3N1l1QL3cVUCh93xSaua1N85qivl+siMkPGbO5xR/En4iEY6K2XPASUEMaieWVNTRCtJ4S8H+9
gitlab.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBFSMqzJeV9rUzU4kWitGjeR4PWSa29SPqJ1fVkhtj3Hw9xjLVXVYrU9QlYWrOLXBpQ6KWjbjTDTdDkoohFzgbEY=The following limits apply for webhooks.
Rate limitsFor each top-level namespace, the number of times each minute that a webhook can be called. The limit varies depending on your plan and the number of seats in your subscription.
Plan Default for GitLab.com GitLab Free500 GitLab Premium, 99 seats or fewer 1,600 GitLab Premium, 100-399 seats 2,800 GitLab Premium, 400 seats or more 4,000 GitLab Ultimate and open source, 999 seats or fewer 6,000 GitLab Ultimate and open source, 1,000-4,999 seats 9,000 GitLab Ultimate and open source, 5,000 seats or more 13,000 Security policy limits
The maximum number of policies that you can add to a security policy project. These limits apply to each policy type individually. For example, you can have five merge request approval policies and five scan execution policies in the same security policy project.
Policy type Default limit Merge request approval policies Five policies per security policy project Scan execution policies Five policies per security policy project Pipeline execution policies Five policies per security policy project Vulnerability management policies Five policies per security policy project Other limits Setting Default for GitLab.com Number of webhooks 100 for each project, 50 for each group (subgroup webhooks are not counted towards parent group limits ) Maximum payload size 25 MB Timeout 10 seconds Parallel Pages deployments 100 extra deployments (Premium tier), 500 extra deployments (Ultimate tier)For GitLab Self-Managed instance limits, see:
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4