GitLab은 대부분의 대규모 애플리케이션과 마찬가지로, 최소한의 성능 품질을 유지하기 위해 특정 기능에 제한을 적용합니다. 일부 기능을 무제한으로 허용하면 보안, 성능, 데이터에 영향을 미치거나 애플리케이션에 할당된 리소스가 소진될 수 있습니다.

인스턴스 구성#

인스턴스 구성 페이지에서 현재 GitLab 인스턴스에 사용되는 일부 설정 정보를 확인할 수 있습니다.

구성한 제한에 따라 다음 정보를 볼 수 있습니다.

• SSH 호스트 키 정보
• CI/CD 제한
• GitLab Pages 제한
• 패키지 레지스트리 제한
• 속도 제한
• 크기 제한

이 페이지는 모든 사람이 볼 수 있으므로, 인증되지 않은 사용자는 자신에게 관련된 정보만 볼 수 있습니다.

인스턴스 구성 페이지를 방문하려면:

1. 왼쪽 사이드바에서 도움말 ([question-o]) > 도움말을 선택합니다.
2. 도움말 페이지에서 현재 인스턴스 구성 확인을 선택합니다.

직접 URL은 <gitlab_url>/help/instance_configuration입니다. GitLab.com에서는 https://gitlab.com/help/instance_configuration을 방문할 수 있습니다.

속도 제한#

속도 제한은 GitLab의 보안과 내구성을 향상시키는 데 사용될 수 있습니다.

속도 제한 구성에 대해 자세히 알아보세요.

이슈 생성#

이 설정은 이슈 생성 엔드포인트에 대한 요청 속도를 제한합니다.

이슈 생성 속도 제한에 대해 자세히 알아보세요.

• 기본 속도 제한: 기본적으로 비활성화됩니다.

사용자 또는 IP별#

이 설정은 사용자 또는 IP별 요청 속도를 제한합니다.

사용자 및 IP 속도 제한에 대해 자세히 알아보세요.

• 기본 속도 제한: 기본적으로 비활성화됩니다.

raw 엔드포인트별#

이 설정들은 raw 엔드포인트의 요청 속도를 제한합니다.

raw 엔드포인트 속도 제한에 대해 자세히 알아보세요.

• 기본 속도 제한 (인증됨 및 인증되지 않음): 프로젝트 및 파일 경로당 분당 300개 요청.
• 기본 속도 제한 (인증되지 않음): 모든 파일 경로에 걸쳐 프로젝트당 분당 800개 요청.

보호된 경로별#

이 설정은 특정 경로의 요청 속도를 제한합니다.

GitLab은 기본적으로 POST 요청에 대해 다음 경로를 속도 제한합니다:

'/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은 기본적으로 GET 요청에 대해 다음 경로를 속도 제한합니다:

'/users/sign_in_path'

보호된 경로 속도 제한에 대해 자세히 알아보세요.

• 기본 속도 제한: 10번의 요청 이후, 클라이언트는 다시 시도하기 전에 60초를 기다려야 합니다.

패키지 레지스트리#

이 설정은 사용자 또는 IP별 Packages API 요청 속도를 제한합니다. 자세한 내용은 패키지 레지스트리 속도 제한을 참조하세요.

• 기본 속도 제한: 기본적으로 비활성화됩니다.

Git LFS#

이 설정은 사용자별 Git LFS 요청 속도를 제한합니다. 자세한 내용은 GitLab Git Large File Storage (LFS) 관리를 읽어보세요.

• 기본 속도 제한: 기본적으로 비활성화됩니다.

Files API#

이 설정은 사용자 또는 IP 주소별 Files API 요청 속도를 제한합니다. 자세한 내용은 Files API 속도 제한을 읽어보세요.

• 기본 속도 제한: 기본적으로 비활성화됩니다.

더 이상 사용되지 않는 API 엔드포인트#

이 설정은 사용자 또는 IP 주소별 더 이상 사용되지 않는 API 엔드포인트의 요청 속도를 제한합니다. 자세한 내용은 더 이상 사용되지 않는 API 속도 제한을 읽어보세요.

• 기본 속도 제한: 기본적으로 비활성화됩니다.

가져오기 및 내보내기#

이 설정들은 그룹 및 프로젝트의 파일 가져오기 및 내보내기를 제한합니다.

이 설정들은 구성할 수 있습니다.

직접 전송 마이그레이션#

직접 전송으로 마이그레이션할 때 다음 제한이 적용됩니다.

구성 가능한 제한 변경에 대한 자세한 내용은 가져오기 및 내보내기 설정을 참조하세요.

멤버 초대#

그룹 계층당 허용되는 최대 일일 멤버 초대 수를 제한합니다.

• GitLab.com: Free 멤버는 하루에 20명을 초대할 수 있고, Premium 트라이얼 및 Ultimate 트라이얼 멤버는 하루에 50명을 초대할 수 있습니다.
• GitLab Self-Managed: 초대는 제한되지 않습니다.

웹훅 속도 제한#

최상위 네임스페이스의 웹훅이 분당 호출될 수 있는 횟수를 제한합니다. 네임스페이스의 모든 프로젝트 및 그룹 웹훅이 이 제한을 공유합니다.

속도 제한을 초과하는 호출은 auth.log에 기록됩니다.

GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 Plan Limits API를 사용하거나 GitLab Rails 콘솔에서 다음을 실행합니다:

# 기본 플랜에 제한이 존재하지 않으면 다음으로 생성할 수 있습니다:
# Plan.default.create_limits!

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

제한을 0으로 설정하면 비활성화됩니다.

• 기본 속도 제한: 비활성화됨 (무제한).

검색 속도 제한#

이 설정은 다음과 같이 검색 요청을 제한합니다:

분당 검색 속도 제한을 초과하는 검색 요청은 다음 오류를 반환합니다:

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

자동 완성 사용자 속도 제한#

이 설정은 자동 완성 사용자 요청을 다음과 같이 제한합니다:

분당 자동 완성 속도 제한을 초과하는 자동 완성 요청은 다음 오류를 반환합니다:

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

파이프라인 생성 속도 제한#

이 설정은 파이프라인 생성 엔드포인트에 대한 요청 속도를 제한합니다.

파이프라인 생성 속도 제한에 대해 자세히 알아보세요.

Gitaly 동시성 제한#

클론 트래픽은 Gitaly 서비스에 큰 부하를 줄 수 있습니다. 이러한 워크로드가 Gitaly 서버를 압도하는 것을 방지하기 위해 Gitaly 구성 파일에서 동시성 제한을 설정할 수 있습니다.

Gitaly 동시성 제한에 대해 자세히 알아보세요.

• 기본 속도 제한: 비활성화됩니다.

이슈, 머지 리퀘스트, 또는 커밋당 댓글 수#

이슈, 머지 리퀘스트, 또는 커밋에 제출할 수 있는 댓글 수에는 제한이 있습니다. 제한에 도달하면 이벤트 기록이 손실되지 않도록 시스템 노트는 여전히 추가될 수 있지만, 사용자가 제출한 댓글은 실패합니다.

• 최대 제한: 댓글 5,000개.

이슈, 머지 리퀘스트, 에픽의 댓글 및 설명 크기#

이슈, 머지 리퀘스트, 에픽의 댓글 및 설명 크기에는 제한이 있습니다. 제한보다 큰 텍스트 본문을 추가하려고 하면 오류가 발생하고, 항목도 생성되지 않습니다.

이 제한이 미래에 더 낮은 숫자로 변경될 수 있습니다.

• 최대 크기: 약 100만 자 / 약 1 MB.

커밋 제목 및 설명 크기#

임의로 큰 메시지가 있는 커밋이 GitLab에 push될 수 있지만, 다음 표시 제한이 적용됩니다:

• 제목 - 커밋 메시지의 첫 번째 줄. 1 KiB로 제한됩니다.
• 설명 - 나머지 커밋 메시지. 1 MiB로 제한됩니다.

커밋이 push되면 GitLab은 제목과 설명을 처리하여 이슈(#123) 및 머지 리퀘스트(!123) 참조를 해당 이슈와 머지 리퀘스트의 링크로 교체합니다.

많은 수의 커밋이 있는 브랜치가 push되면, 마지막 100개 커밋만 처리됩니다.

리베이스 작업 중 크기#

커밋을 리베이스할 때, 크기 제한을 초과하는 커밋 메시지는 잘립니다. 이 제한은 커밋 제목 및 설명의 크기 제한과는 별개입니다.

• 제한: 10,240바이트 (10 KB).

마일스톤 개요의 이슈 수#

마일스톤 개요 페이지에 로드되는 최대 이슈 수는 500개입니다. 수가 제한을 초과하면 페이지에 알림이 표시되고 마일스톤의 모든 이슈의 페이지화된 이슈 목록으로 링크됩니다.

• 제한: 이슈 500개.

Git push당 파이프라인 수#

여러 태그나 브랜치 같은 여러 변경 사항을 단일 Git push로 push하는 경우, 기본적으로 4개의 태그 또는 브랜치 파이프라인만 트리거될 수 있습니다. 이 제한은 git push --all 또는 git push --mirror를 사용할 때 많은 수의 파이프라인이 실수로 생성되는 것을 방지합니다.

머지 리퀘스트 파이프라인은 제한됩니다. Git push가 여러 머지 리퀘스트를 동시에 업데이트하면, 제한에 도달하기 전에 모든 업데이트된 머지 리퀘스트에 대해 머지 리퀘스트 파이프라인이 트리거될 수 있습니다.

기본값은 GitLab Self-Managed와 GitLab.com 모두에서 4입니다.

GitLab Self-Managed 인스턴스에서 이 제한을 변경하려면 Admin Area를 사용합니다.

활동 기록 보존#

프로젝트 및 개인 프로필의 활동 기록은 3년으로 제한됩니다.

임베드된 메트릭 수#

성능상의 이유로 GitLab Flavored Markdown (GLFM)에 메트릭을 임베드할 때 제한이 있습니다.

• 최대 제한: 100개 임베드.

HTTP 응답 제한#

최대 Gzip 압축 크기#

이 설정은 압축 해제 후 Gzip 압축된 HTTP 응답에 허용되는 최대 크기(MiB)를 제한합니다.

기본 최대 크기는 100 MiB입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.

GitLab Rails 콘솔을 사용하거나 애플리케이션 설정 API를 사용하여 이 제한을 변경할 수 있습니다.

ApplicationSetting.update(max_http_decompressed_size: 50)

아웃바운드 요청에서 최대 HTTP 응답 크기#

이 설정은 압축 해제된 HTTP 응답에 허용되는 최대 크기(MiB)를 제한합니다. 통합, 임포터, 웹훅에 적용됩니다.

기본 최대 크기는 100 MiB입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.

GitLab Rails 콘솔을 사용하거나 애플리케이션 설정 API를 사용하여 이 제한을 변경할 수 있습니다.

ApplicationSetting.update(max_http_response_size_limit: 60)

아웃바운드 요청에서 JSON HTTP 응답의 최대 허용 오브젝트 수#

이 설정은 아웃바운드 요청에서 JSON HTTP 응답의 최대 허용 오브젝트 수를 제한합니다. 오브젝트 수는 응답에서 :, ,, {, [의 발생 횟수를 기반으로 추정됩니다.

기본 최대 수는 1,000,000개 오브젝트입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.

GitLab Rails 콘솔을 사용하거나 애플리케이션 설정 API를 사용하여 이 제한을 변경할 수 있습니다:

ApplicationSetting.update(max_http_response_json_structural_chars: 500000)

아웃바운드 요청에서 JSON HTTP 응답의 최대 허용 중첩 깊이#

이 설정은 아웃바운드 요청에서 JSON HTTP 응답의 최대 허용 중첩 깊이를 제한합니다.

기본 최대 중첩 깊이는 32입니다.

GitLab Rails 콘솔을 사용하거나 애플리케이션 설정 API를 사용하여 이 제한을 변경할 수 있습니다:

ApplicationSetting.update(max_http_response_json_depth: 100)

아웃바운드 요청에서 XML HTTP 응답의 최대 허용 오브젝트 수#

이 설정은 아웃바운드 요청에서 XML HTTP 응답의 최대 허용 오브젝트 수를 제한합니다. 오브젝트 수는 응답에서 <, =의 발생 횟수를 기반으로 추정됩니다.

기본 최대 수는 250,000개 오브젝트입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.

GitLab Rails 콘솔을 사용하거나 애플리케이션 설정 API를 사용하여 이 제한을 변경할 수 있습니다:

ApplicationSetting.update(max_http_response_xml_structural_chars: 500000)

아웃바운드 요청에서 CSV HTTP 응답의 최대 허용 오브젝트 수#

이 설정은 아웃바운드 요청에서 CSV HTTP 응답의 최대 허용 오브젝트 수를 제한합니다. 오브젝트 수는 응답에서 ,, ;, \t, \n의 발생 횟수를 기반으로 추정됩니다.

기본 최대 수는 250,000개 오브젝트입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.

GitLab Rails 콘솔을 사용하거나 애플리케이션 설정 API를 사용하여 이 제한을 변경할 수 있습니다:

ApplicationSetting.update(max_http_response_csv_structural_chars: 500000)

HTTP 요청 제한#

기본적으로 요청의 JSON 파라미터는 제한됩니다. 자세한 내용은 엔드포인트별 JSON 유효성 검사 제한을 참조하세요.

gitlab:
  webservice:
    extraEnv:
      GITLAB_JSON_GLOBAL_VALIDATION_MODE: "disabled"

엔드포인트별 JSON 유효성 검사 제한#

일부 API 엔드포인트에는 특정 JSON 유효성 검사 제한이 있습니다.

각주:

1. Terraform 상태 최대 크기 제한은 애플리케이션 설정 API를 사용하여 max_terraform_state_size_bytes를 설정함으로써 지정할 수 있습니다.

환경 변수 구성#

다음 환경 변수들은 기본 제한과 유효성 검사 모드를 수정합니다:

GITLAB_JSON_GLOBAL_VALIDATION_MODE 환경 변수는 다음 모드 중 하나로 설정할 수 있습니다.

GITLAB_JSON_GLOBAL_VALIDATION_MODE 사용 시:

• 경로별 구성이 기본 제한을 재정의하지만 전역 유효성 검사 모드는 재정의하지 않습니다.
• enforced 모드에서 제한을 초과하면 응답은 JSON 오류 메시지가 포함된 HTTP 400입니다.
• 전체 요소 수에는 전체 JSON 구조의 배열과 해시의 모든 요소가 포함됩니다.

웹훅 제한#

웹훅 속도 제한도 참조하세요.

웹훅 수#

GitLab Self-Managed 인스턴스의 그룹 또는 프로젝트 웹훅 최대 수를 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

# 기본 플랜에 제한이 존재하지 않으면 다음으로 생성할 수 있습니다:
# Plan.default.create_limits!

# 프로젝트 웹훅
Plan.default.actual_limits.update!(project_hooks: 200)

# 그룹 웹훅
Plan.default.actual_limits.update!(group_hooks: 100)

제한을 0으로 설정하면 비활성화됩니다.

기본 최대 웹훅 수는 프로젝트당 100개, 그룹당 50개입니다. 하위 그룹의 웹훅은 상위 그룹의 웹훅 제한에 포함되지 않습니다.

GitLab.com의 경우, GitLab.com의 웹훅 제한을 참조하세요.

웹훅 페이로드 크기#

최대 웹훅 페이로드 크기는 25 MB입니다.

웹훅 타임아웃#

웹훅을 전송한 후 GitLab이 HTTP 응답을 기다리는 초 수입니다.

웹훅 타임아웃 값을 변경하려면:

1. Sidekiq를 실행하는 모든 GitLab 노드에서 /etc/gitlab/gitlab.rb를 편집합니다:

   gitlab_rails['webhook_timeout'] = 60
   

2. 파일을 저장합니다.

3. 변경 사항이 적용되도록 GitLab을 재구성하고 재시작합니다:

   gitlab-ctl reconfigure
   gitlab-ctl restart
   

GitLab.com의 웹훅 제한도 참조하세요.

재귀 웹훅#

GitLab은 재귀적이거나 다른 웹훅에서 트리거될 수 있는 웹훅 수의 제한을 초과하는 웹훅을 감지하고 차단합니다. 이를 통해 GitLab은 API를 비재귀적으로 호출하거나 불합리한 수의 다른 웹훅을 트리거하지 않는 웹훅을 사용하는 워크플로를 계속 지원할 수 있습니다.

재귀는 웹훅이 자신의 GitLab 인스턴스(예: API)를 호출하도록 구성될 때 발생할 수 있습니다. 그 호출이 같은 웹훅을 트리거하여 무한 루프를 만듭니다.

다른 웹훅을 트리거하는 일련의 웹훅에 의해 인스턴스에 요청되는 최대 횟수는 100입니다. 제한에 도달하면 GitLab은 해당 시리즈에서 트리거될 추가 웹훅을 차단합니다.

차단된 재귀 웹훅 호출은 "Recursive webhook blocked from executing" 메시지와 함께 auth.log에 기록됩니다.

가져오기 플레이스홀더 사용자 제한#

가져오기 중에 생성되는 플레이스홀더 사용자 수는 최상위 네임스페이스당 제한될 수 있습니다.

GitLab Self-Managed의 기본 제한은 0 (무제한)입니다.

GitLab Self-Managed 인스턴스에서 이 제한을 변경하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

# 기본 플랜에 제한이 존재하지 않으면 다음으로 생성할 수 있습니다:
# Plan.default.create_limits!

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

제한을 0으로 설정하면 비활성화됩니다.

풀 미러링 간격#

풀 새로 고침 간의 최소 대기 시간은 기본값이 300초(5분)입니다. 예를 들어, 풀 새로 고침은 몇 번을 트리거하더라도 지정된 300초 기간에 한 번만 실행됩니다.

이 설정은 프로젝트 API를 사용하거나 설정 > 저장소 > 저장소 미러링에서 지금 업데이트 ([retry])를 선택하여 강제로 업데이트할 때 호출되는 풀 새로 고침 컨텍스트에서 적용됩니다. 이 설정은 풀 미러링을 위해 Sidekiq가 사용하는 자동 30분 간격 스케줄에는 영향을 미치지 않습니다.

GitLab Self-Managed 인스턴스에서 이 제한을 변경하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

# 기본 플랜에 제한이 존재하지 않으면 다음으로 생성할 수 있습니다:
# Plan.default.create_limits!

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

자동 응답에서 수신 이메일#

GitLab은 X-Autoreply 헤더를 확인하여 자동 응답에서 보낸 모든 수신 이메일을 무시합니다. 이러한 이메일은 이슈나 머지 리퀘스트에 댓글을 생성하지 않습니다.

오류 추적을 통해 Sentry에서 전송된 데이터 양#

GitLab으로 전송된 Sentry 페이로드는 보안상의 이유와 메모리 소비를 제한하기 위해 최대 1 MB 제한이 있습니다.

REST API의 오프셋 기반 페이지네이션에서 허용되는 최대 오프셋#

REST API에서 오프셋 기반 페이지네이션을 사용할 때, 결과 집합에 요청할 수 있는 최대 오프셋에 제한이 있습니다. 이 제한은 키셋 기반 페이지네이션도 지원하는 엔드포인트에만 적용됩니다. 페이지네이션 옵션에 대한 자세한 내용은 페이지네이션에 관한 API 문서 섹션에서 찾을 수 있습니다.

GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

# 기본 플랜에 제한이 존재하지 않으면 다음으로 생성할 수 있습니다:
# Plan.default.create_limits!

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

• 기본 오프셋 페이지네이션 제한: 50000.

제한을 0으로 설정하면 비활성화됩니다.

CI/CD 제한#

활성 파이프라인의 작업 수#

활성 파이프라인의 총 작업 수는 프로젝트당 제한될 수 있습니다. 이 제한은 새 파이프라인이 생성될 때마다 확인됩니다. 활성 파이프라인은 다음 상태 중 하나에 있는 파이프라인입니다:

• created
• pending
• running

새 파이프라인으로 인해 총 작업 수가 제한을 초과하면, 파이프라인은 job_activity_limit_exceeded 오류와 함께 실패합니다.

• GitLab.com에서는 각 구독 티어별 제한이 정의되어 있으며, 이 제한은 해당 티어의 모든 프로젝트에 영향을 미칩니다.
• GitLab Self-Managed의 Premium 또는 Ultimate 구독에서, 이 제한은 모든 프로젝트에 영향을 미치는 default 플랜 아래에 정의됩니다. 이 제한은 기본적으로 비활성화됩니다 (0).

GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

# 기본 플랜에 제한이 존재하지 않으면 다음으로 생성할 수 있습니다:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(ci_active_jobs: 500)

제한을 0으로 설정하면 비활성화됩니다.

작업이 실행될 수 있는 최대 시간#

작업이 실행될 수 있는 기본 최대 시간은 60분입니다. 60분 이상 실행되는 작업은 타임아웃됩니다.

작업이 타임아웃되기 전에 실행될 수 있는 최대 시간을 변경할 수 있습니다:

• 주어진 프로젝트의 프로젝트 CI/CD 설정에서 프로젝트 수준으로. 이 제한은 10분에서 1개월 사이여야 합니다.
• 런너 수준에서. 이 제한은 10분 이상이어야 합니다.

구성된 타임아웃 제한에 관계없이, GitLab은 60분 동안 비활성 상태인 작업을 종료합니다. 비활성 작업은 새 로그나 추적 업데이트가 없는 작업입니다.

파이프라인의 최대 작업 수#

파이프라인의 최대 작업 수를 제한할 수 있습니다. 파이프라인의 작업 수는 파이프라인 생성 시 및 새 커밋 상태가 생성될 때 확인됩니다. 작업이 너무 많은 파이프라인은 size_limit_exceeded 오류와 함께 실패합니다.

• GitLab.com에서는 각 구독 티어별 제한이 정의되어 있으며, 이 제한은 해당 티어의 모든 프로젝트에 영향을 미칩니다.
• GitLab Self-Managed의 Premium 또는 Ultimate 구독에서, 이 제한은 모든 프로젝트에 영향을 미치는 default 플랜 아래에 정의됩니다. 이 제한은 기본적으로 비활성화됩니다 (0).

GitLab Self-Managed 인스턴스의 제한을 변경하려면 다음 GitLab Rails 콘솔 명령으로 default 플랜의 제한을 변경합니다:

# 기본 플랜에 제한이 존재하지 않으면 다음으로 생성할 수 있습니다:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(ci_pipeline_size: 500)

제한을 0으로 설정하면 비활성화됩니다.

파이프라인의 최대 배포 작업 수#

파이프라인의 최대 배포 작업 수를 제한할 수 있습니다. 배포는 environment가 지정된 모든 작업입니다. 파이프라인의 배포 수는 파이프라인 생성 시 확인됩니다. 배포가 너무 많은 파이프라인은 deployments_limit_exceeded 오류와 함께 실패합니다.

기본 제한은 모든 GitLab Self-Managed 및 GitLab.com 구독에 대해 500입니다.

GitLab Self-Managed 인스턴스의 제한을 변경하려면 다음 GitLab Rails 콘솔 명령으로 default 플랜의 제한을 변경합니다:

# 기본 플랜에 제한이 존재하지 않으면 다음으로 생성할 수 있습니다:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(ci_pipeline_deployments: 500)

제한을 0으로 설정하면 비활성화됩니다.

파이프라인 계층 크기 제한#

기본적으로 파이프라인 계층은 최대 1000개의 다운스트림 파이프라인을 포함할 수 있습니다. 이 제한이 초과되면 downstream pipeline tree is too large 오류와 함께 파이프라인 생성이 실패합니다.

인스턴스에서 이 제한을 수정하려면 Admin area의 GitLab UI 또는 Plan Limits API를 사용합니다.

GitLab Rails 콘솔에서 다음 명령을 실행할 수도 있습니다:

Plan.default.actual_limits.update!(pipeline_hierarchy_size: 500)

이 제한은 GitLab.com에서 활성화되어 있으며 변경할 수 없습니다.

프로젝트에 대한 CI/CD 구독 수#

총 구독 수는 프로젝트당 제한될 수 있습니다. 이 제한은 새 구독이 생성될 때마다 확인됩니다.

새 구독으로 인해 총 구독 수가 제한을 초과하면, 해당 구독은 유효하지 않은 것으로 간주됩니다.

• GitLab.com에서는 각 구독 티어별 제한이 정의되어 있으며, 이 제한은 해당 티어의 모든 프로젝트에 영향을 미칩니다.
• GitLab Self-Managed의 Premium 또는 Ultimate에서, 이 제한은 모든 프로젝트에 영향을 미치는 default 플랜 아래에 정의됩니다. 기본적으로 2개의 구독 제한이 있습니다.

GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits.update!(ci_project_subscriptions: 500)

제한을 0으로 설정하면 비활성화됩니다.

파이프라인 트리거 수 제한#

프로젝트당 최대 파이프라인 트리거 수에 제한을 설정할 수 있습니다. 이 제한은 새 트리거가 생성될 때마다 확인됩니다.

새 트리거로 인해 파이프라인 트리거 총 수가 제한을 초과하면, 해당 트리거는 유효하지 않은 것으로 간주됩니다.

제한을 0으로 설정하면 비활성화됩니다. GitLab Self-Managed에서 기본값은 25000입니다.

GitLab Self-Managed 인스턴스에서 이 제한을 100으로 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

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

이 제한은 GitLab.com에서 활성화되어 있습니다.

파이프라인 스케줄 수#

총 파이프라인 스케줄 수는 프로젝트당 제한될 수 있습니다. 이 제한은 새 파이프라인 스케줄이 생성될 때마다 확인됩니다. 새 파이프라인 스케줄로 인해 총 파이프라인 스케줄 수가 제한을 초과하면, 파이프라인 스케줄은 생성되지 않습니다.

GitLab.com에서 제한은 각 구독 티어별로 정의되어 있으며, 이 제한은 해당 티어의 모든 프로젝트에 영향을 미칩니다.

GitLab Self-Managed 및 GitLab Dedicated에서 이 제한은 모든 프로젝트에 영향을 미치는 default 플랜 아래에 정의됩니다. 기본적으로 10개의 파이프라인 스케줄 제한이 있습니다.

이 제한을 설정하려면 Plan Limits API를 사용합니다.

GitLab Self-Managed의 경우 GitLab Rails 콘솔을 사용할 수도 있습니다. 예를 들어, 제한을 100으로 설정하려면:

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

파이프라인 스케줄이 하루에 생성하는 파이프라인 수 제한#

각 개별 파이프라인 스케줄이 하루에 트리거할 수 있는 파이프라인 수를 제한할 수 있습니다.

제한보다 더 자주 파이프라인을 실행하려는 스케줄은 최대 빈도로 느려집니다. 빈도는 1440(하루 분 수)을 제한값으로 나누어 계산됩니다. 예를 들어, 최대 빈도가 다음인 경우:

• 분당 1번, 제한은 1440이어야 합니다.
• 10분당 1번, 제한은 144이어야 합니다.
• 60분당 1번, 제한은 24이어야 합니다.

최소값은 24, 즉 60분당 파이프라인 1개입니다. 최대값은 없습니다.

GitLab Self-Managed 인스턴스에서 이 제한을 1440으로 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits.update!(ci_daily_pipeline_schedule_triggers: 1440)

이 제한은 GitLab.com에서 활성화되어 있습니다.

보안 정책 프로젝트에 대해 정의된 스케줄 규칙 수 제한#

보안 정책 프로젝트당 총 스케줄 규칙 수에 제한을 설정할 수 있습니다. 이 제한은 스케줄 규칙이 있는 정책이 업데이트될 때마다 확인됩니다. 새 스케줄 규칙으로 인해 총 스케줄 규칙 수가 제한을 초과하면, 새 스케줄 규칙은 처리되지 않습니다.

기본적으로 GitLab Self-Managed는 처리 가능한 스케줄 규칙 수를 제한하지 않습니다.

GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

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

이 제한은 GitLab.com에서 활성화되어 있습니다.

CI/CD 변수 제한#

프로젝트, 그룹, 인스턴스 설정에서 정의할 수 있는 CI/CD 변수 수는 모두 인스턴스 전체에 걸쳐 제한됩니다. 이 제한은 새 변수가 생성될 때마다 확인됩니다. 새 변수로 인해 총 변수 수가 해당 제한을 초과하면, 새 변수는 생성되지 않습니다.

GitLab Self-Managed 인스턴스에서 이러한 제한 중 하나의 default 플랜을 업데이트하려면 GitLab Rails 콘솔에서 다음 명령을 실행합니다:

• 인스턴스 수준 CI/CD 변수 제한 (기본값: 25):

  Plan.default.actual_limits.update!(ci_instance_level_variables: 30)
  

• 그룹당 그룹 수준 CI/CD 변수 제한 (기본값: 30000):

  Plan.default.actual_limits.update!(group_ci_variables: 40000)
  

• 프로젝트당 프로젝트 수준 CI/CD 변수 제한 (기본값: 8000):

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

아티팩트 유형별 최대 파일 크기#

artifacts:reports로 정의되어 런너에 의해 업로드된 작업 아티팩트는 파일 크기가 최대 파일 크기 제한을 초과하면 거부됩니다. 제한은 프로젝트의 최대 아티팩트 크기 설정과 해당 아티팩트 유형의 인스턴스 제한을 비교하여 더 작은 값을 선택함으로써 결정됩니다.

제한은 메가바이트 단위로 설정되므로 정의할 수 있는 최소값은 1 MB입니다.

각 유형의 아티팩트에는 설정할 수 있는 크기 제한이 있습니다. 기본값 0은 해당 특정 아티팩트 유형에 제한이 없으며, 프로젝트의 최대 아티팩트 크기 설정이 사용됨을 의미합니다:

예를 들어, GitLab Self-Managed에서 ci_max_artifact_size_junit 제한을 10 MB로 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

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

GitLab Pages 웹사이트당 파일 수#

총 파일 항목 수 (디렉토리 및 심볼릭 링크 포함)는 GitLab Pages 웹사이트당 200,000으로 제한됩니다.

이것은 GitLab Self-Managed 및 GitLab.com의 기본 제한입니다.

GitLab Self-Managed 인스턴스에서 제한을 업데이트하려면 GitLab Rails 콘솔을 사용합니다. 예를 들어, 제한을 100으로 변경하려면:

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

GitLab Pages 웹사이트당 커스텀 도메인 수#

GitLab Pages 웹사이트당 총 커스텀 도메인 수는 GitLab.com에서 150으로 제한됩니다.

GitLab Self-Managed의 기본 제한은 0 (무제한)입니다. 인스턴스에 제한을 설정하려면 Admin area를 사용합니다.

병렬 Pages 배포 수#

병렬 Pages 배포를 사용할 때, 최상위 네임스페이스에 허용되는 총 병렬 Pages 배포 수는 1000개입니다.

프로젝트에 고유 도메인이 활성화된 경우, 프로젝트의 고유 도메인은 별도의 1000개 배포 제한이 있는 자체 최상위 네임스페이스로 취급됩니다.

각 범위에 등록된 런너 수#

등록된 런너 총 수는 그룹 및 프로젝트에 대해 제한됩니다. 새 런너가 등록될 때마다 GitLab은 지난 7일 동안 생성되거나 활성화된 런너에 대해 이 제한을 확인합니다. 런너의 등록 토큰이 결정한 범위의 제한을 초과하면 런너 등록이 실패합니다. 제한값이 0으로 설정되면 제한이 비활성화됩니다.

GitLab.com 구독자는 구독별로 정의된 다른 제한이 있으며, 해당 구독을 사용하는 모든 프로젝트에 영향을 미칩니다.

GitLab Self-Managed의 Premium 및 Ultimate 제한은 모든 프로젝트에 영향을 미치는 기본 플랜으로 정의됩니다:

이 제한을 업데이트하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

# 원하는 범위에 따라 ci_registered_group_runners 또는 ci_registered_project_runners 사용
Plan.default.actual_limits.update!(ci_registered_project_runners: 100)

작업 로그의 최대 파일 크기#

GitLab의 작업 로그 파일 크기 제한은 기본적으로 100메가바이트입니다. 제한을 초과하는 작업은 실패로 표시되고 런너에 의해 삭제됩니다.

GitLab Rails 콘솔에서 제한을 변경할 수 있습니다. 새 값(메가바이트)으로 ci_jobs_trace_size_limit를 업데이트합니다:

Plan.default.actual_limits.update!(ci_jobs_trace_size_limit: 125)

GitLab Runner에도 런너에서 최대 로그 크기를 구성하는 output_limit 설정이 있습니다. 런너 제한을 초과하는 작업은 계속 실행되지만, 제한에 도달하면 로그가 잘립니다.

프로젝트당 최대 활성 DAST 프로필 스케줄 수#

프로젝트당 활성 DAST 프로필 스케줄 수를 제한합니다. DAST 프로필 스케줄은 활성 또는 비활성 상태일 수 있습니다.

GitLab Rails 콘솔에서 제한을 변경할 수 있습니다. 새 값으로 dast_profile_schedules를 업데이트합니다:

Plan.default.actual_limits.update!(dast_profile_schedules: 50)

CI 아티팩트 아카이브의 최대 크기#

이 설정은 동적 하위 파이프라인의 YAML 크기를 제한하는 데 사용됩니다.

CI 아티팩트 아카이브의 기본 최대 크기는 5메가바이트입니다.

GitLab Rails 콘솔을 사용하여 이 제한을 변경할 수 있습니다. CI 아티팩트 아카이브의 최대 크기를 업데이트하려면, 새 값으로 max_artifacts_content_include_size를 업데이트합니다. 예를 들어, 20 MB로 설정하려면:

ApplicationSetting.update(max_artifacts_content_include_size: 20.megabytes)

CI/CD 구성 YAML 파일의 최대 크기 및 깊이#

단일 CI/CD 구성 YAML 파일의 기본 최대 크기는 2메가바이트이고 기본 깊이는 100입니다.

GitLab Rails 콘솔에서 이 제한을 변경할 수 있습니다:

• 최대 YAML 크기를 업데이트하려면, 새 값(메가바이트)으로 max_yaml_size_bytes를 업데이트합니다:

  ApplicationSetting.update(max_yaml_size_bytes: 4.megabytes)
  

  max_yaml_size_bytes 값은 YAML 파일의 크기에 직접 연결되지 않고, 관련 오브젝트에 할당된 메모리에 연결됩니다.

• 최대 YAML 깊이를 업데이트하려면, 새 값(줄 수)으로 max_yaml_depth를 업데이트합니다:

  ApplicationSetting.update(max_yaml_depth: 125)
  

전체 CI/CD 구성의 최대 크기#

포함된 모든 YAML 구성 파일과 함께 전체 파이프라인 구성에 할당할 수 있는 메모리의 최대 양(바이트)입니다.

기본값은 max_yaml_size_bytes (기본값 2 MB)와 ci_max_includes (기본값 150)를 곱하여 계산됩니다:

• GitLab 17.2 이하: 1 MB × 150 = 157286400바이트 (150 MB).
• GitLab 17.3 이상: 2 MB × 150 = 314572800바이트 (314.6 MB).

GitLab Rails 콘솔을 사용하여 이 제한을 변경할 수 있습니다. CI/CD 구성에 할당할 수 있는 최대 메모리를 업데이트하려면, 새 값으로 ci_max_total_yaml_size_bytes를 업데이트합니다. 예를 들어, 20 MB로 설정하려면:

ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)

dotenv 변수 제한#

dotenv 아티팩트 내의 최대 변수 수에 제한을 설정할 수 있습니다. 이 제한은 dotenv 파일이 아티팩트로 내보낼 때마다 확인됩니다.

비활성화하려면 제한을 0으로 설정합니다. GitLab Self-Managed에서 기본값은 20입니다.

인스턴스에서 이 제한을 100으로 설정하려면 GitLab Rails 콘솔에서 다음 명령을 실행합니다:

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

GitLab UI 또는 Plan limits API를 사용하여 이 제한을 설정할 수도 있습니다.

이 제한은 GitLab.com에서 활성화되어 있습니다.

dotenv 파일 크기 제한#

dotenv 아티팩트의 최대 크기에 제한을 설정할 수 있습니다. 이 제한은 dotenv 파일이 아티팩트로 내보낼 때마다 확인됩니다.

비활성화하려면 제한을 0으로 설정합니다. 기본값은 5 KB입니다.

GitLab Self-Managed 인스턴스에서 이 제한을 5 KB로 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits.update!(dotenv_size: 5.kilobytes)

CI/CD 작업 주석 제한#

CI/CD 작업당 최대 주석 수에 제한을 설정할 수 있습니다.

비활성화하려면 제한을 0으로 설정합니다. GitLab Self-Managed에서 기본값은 20입니다.

인스턴스에서 이 제한을 100으로 설정하려면 GitLab Rails 콘솔에서 다음 명령을 실행합니다:

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

CI/CD 작업 주석 파일 크기 제한#

CI/CD 작업 주석의 최대 크기에 제한을 설정할 수 있습니다.

비활성화하려면 제한을 0으로 설정합니다. 기본값은 80 KB입니다.

GitLab Self-Managed 인스턴스에서 이 제한을 100 KB로 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits.update!(ci_job_annotations_size: 100.kilobytes)

CI/CD 테이블의 최대 데이터베이스 파티션 크기#

새 파티션이 자동으로 생성되기 전에 파티션된 테이블의 파티션이 사용할 수 있는 최대 디스크 공간(바이트)입니다. 기본값은 100 GB입니다.

GitLab Rails 콘솔을 사용하여 이 제한을 변경할 수 있습니다. 제한을 변경하려면 새 값으로 ci_partitions_size_limit를 업데이트합니다. 예를 들어, 20 GB로 설정하려면:

ApplicationSetting.update(ci_partitions_size_limit: 20.gigabytes)

CI/CD 파티션의 최대 시간 창#

새 CI 파티션이 생성되고 시스템이 다음 파티션 세트로 전환되기 전의 시간 창(초)입니다. 1개월에서 6개월 사이여야 합니다. 기본값은 1개월(2592000초)입니다.

GitLab Rails 콘솔을 사용하여 이 제한을 변경할 수 있습니다. 제한을 변경하려면 새 값으로 ci_partitions_in_seconds_limit를 업데이트합니다. 예를 들어, 3개월로 설정하려면:

ApplicationSetting.update(ci_partitions_in_seconds_limit: ChronicDuration.parse('3 months'))

자동 파이프라인 정리의 최대 구성 값#

CI/CD 파이프라인 만료 시간의 상한선을 구성합니다. 기본값은 1년입니다.

GitLab Rails 콘솔을 사용하여 이 제한을 변경할 수 있습니다. 제한을 변경하려면 새 값으로 ci_delete_pipelines_in_seconds_limit_human_readable를 업데이트합니다. 예를 들어, 3년으로 설정하려면:

ApplicationSetting.update(ci_delete_pipelines_in_seconds_limit_human_readable: '3 years')

인스턴스 모니터링 및 메트릭#

인바운드 인시던트 관리 알림 제한#

이 설정은 일정 시간 동안 인바운드 알림 페이로드 수를 제한합니다.

인시던트 관리 속도 제한에 대해 자세히 알아보세요.

Prometheus Alert JSON 페이로드#

notify.json 엔드포인트로 전송된 Prometheus 알림 페이로드는 크기가 1 MB로 제한됩니다.

일반 Alert JSON 페이로드#

notify.json 엔드포인트로 전송된 알림 페이로드는 크기가 1 MB로 제한됩니다.

환경 대시보드 제한#

표시되는 최대 프로젝트 수는 환경 대시보드를 참조하세요.

배포 보드의 환경 데이터#

배포 보드는 Kubernetes에서 Pod 및 배포에 대한 정보를 로드합니다. 그러나 Kubernetes에서 읽은 특정 환경에 대해 10 MB를 초과하는 데이터는 표시되지 않습니다.

머지 리퀘스트#

Diff 제한#

GitLab에는 다음에 대한 제한이 있습니다:

• 단일 파일의 패치 크기. 이는 GitLab Self-Managed에서 구성 가능합니다.
• 머지 리퀘스트의 모든 diff 총 크기.

각각에 대해 상한 및 하한이 적용됩니다:

• 변경된 파일 수.
• 변경된 줄 수.
• 표시되는 변경의 누적 크기.

하한은 추가적인 diff가 축소되도록 합니다. 상한은 더 이상 변경이 렌더링되지 않도록 합니다. 이 제한에 대한 자세한 내용은 diff 작업에 대한 GitLab 개발 문서를 읽어보세요.

Diff 버전 제한#

GitLab은 각 머지 리퀘스트를 1000개의 diff 버전으로 제한합니다. 이 제한에 도달한 머지 리퀘스트는 더 이상 업데이트할 수 없습니다. 대신 영향받은 머지 리퀘스트를 닫고 새 머지 리퀘스트를 만듭니다.

머지 리퀘스트 리포트 크기 제한#

20 MB 제한을 초과하는 리포트는 로드되지 않습니다. 영향받은 리포트:

• 머지 리퀘스트 보안 리포트
• CI/CD 파라미터 artifacts:expose_as
• 단위 테스트 리포트

고급 검색 제한#

인덱싱된 최대 파일 크기#

Elasticsearch에서 인덱싱된 저장소 파일 내용에 제한을 설정할 수 있습니다. 이 제한보다 큰 파일은 파일 이름만 인덱싱합니다. 파일 내용은 인덱싱되지 않고 검색할 수 없습니다.

제한을 설정하면 인덱싱 프로세스의 메모리 사용량과 전체 인덱스 크기를 줄이는 데 도움이 됩니다. 이 값은 기본값이 1024 KiB (1 MiB)로, 이보다 큰 텍스트 파일은 사람이 읽을 용도가 아닌 경우가 많습니다.

무제한 파일 크기는 지원되지 않으므로 반드시 제한을 설정해야 합니다. 이 값을 GitLab Sidekiq 노드의 메모리 양보다 크게 설정하면 GitLab Sidekiq 노드의 메모리가 부족해집니다. 인덱싱 중에 이 양의 메모리가 미리 할당되기 때문입니다.

최대 필드 길이#

고급 검색을 위해 인덱싱된 텍스트 필드 내용에 제한을 설정할 수 있습니다. 최대값을 설정하면 인덱싱 프로세스의 부하를 줄이는 데 도움이 됩니다. 텍스트 필드가 이 제한을 초과하면 텍스트가 해당 문자 수로 잘립니다. 나머지 텍스트는 인덱싱되지 않고 검색할 수 없습니다. 이것은 인덱싱되는 저장소 파일을 제외한 모든 인덱싱된 데이터에 적용되며, 저장소 파일에는 별도의 제한이 있습니다. 자세한 내용은 인덱싱된 최대 파일 크기를 읽어보세요.

• GitLab.com에서 필드 길이 제한은 20,000자입니다.
• GitLab Self-Managed 인스턴스의 경우 필드 길이는 기본적으로 무제한입니다.

Elasticsearch를 활성화할 때 GitLab Self-Managed 인스턴스에 이 제한을 구성할 수 있습니다. 비활성화하려면 제한을 0으로 설정합니다.

수학 렌더링 제한#

GitLab은 Markdown 필드에서 수학을 렌더링할 때 기본 제한을 적용합니다. 이 제한은 더 나은 보안과 성능을 제공합니다.

이슈, 머지 리퀘스트, 에픽, wiki 및 저장소 파일에 대한 제한:

• 최대 매크로 확장 수: 1000.
• em 단위의 최대 사용자 지정 크기: 20.
• 렌더링된 최대 노드 수: 50.
• 수학 블록의 최대 문자 수: 1000.
• 최대 렌더링 시간: 2000 ms.

GitLab Self-Managed를 실행하고 사용자 입력을 신뢰하는 경우 이 제한을 비활성화할 수 있습니다.

GitLab Rails 콘솔을 사용합니다:

ApplicationSetting.update(math_rendering_limits_enabled: false)

이 제한은 GraphQL 또는 REST API를 사용하여 그룹별로 비활성화할 수도 있습니다.

제한이 비활성화되면 이슈, 머지 리퀘스트, 에픽, wiki 및 저장소 파일에서 수학이 대부분 제한 없이 렌더링됩니다. 이는 악의적인 행위자가 브라우저에서 볼 때 DoS를 유발할 수 있는 수학을 추가할 수 있음을 의미합니다. 신뢰하는 사람만 콘텐츠를 추가할 수 있도록 해야 합니다.

Wiki 제한#

• Wiki 페이지 콘텐츠 크기 제한.
• 파일 및 디렉토리 이름의 길이 제한.

스니펫 제한#

스니펫 설정에 대한 문서를 참조하세요.

Design Management 제한#

이슈에 디자인 추가 섹션의 제한을 참조하세요.

Push 이벤트 제한#

최대 push 크기#

최대 허용 push 크기.

GitLab Self-Managed에서는 기본적으로 설정되지 않습니다. GitLab.com의 경우 계정 및 제한 설정을 참조하세요.

웹훅 및 프로젝트 서비스#

단일 push에서 변경 사항(브랜치 또는 태그) 총 수. 변경 사항이 지정된 제한보다 많으면 훅이 실행되지 않습니다.

자세한 내용은 다음을 참조하세요:

• 웹훅 push 이벤트
• 프로젝트 통합을 위한 Push 훅 제한

활동#

단일 push에서 개별 push 이벤트 또는 대량 push 이벤트가 생성되는지 결정하기 위한 변경 사항(브랜치 또는 태그) 총 수.

자세한 내용은 Push 이벤트 활동 제한 및 대량 push 이벤트 문서에서 찾을 수 있습니다.

패키지 레지스트리 제한#

파일 크기 제한#

GitLab 패키지 레지스트리에 업로드된 패키지의 기본 최대 파일 크기는 형식에 따라 다릅니다:

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

GitLab.com의 최대 파일 크기는 다를 수 있습니다.

GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 Admin area를 통해 하거나 GitLab Rails 콘솔에서 다음을 실행합니다:

# 파일 크기 제한은 바이트 단위로 저장됩니다

# Conan 패키지
Plan.default.actual_limits.update!(conan_max_file_size: 100.megabytes)

# npm 패키지
Plan.default.actual_limits.update!(npm_max_file_size: 100.megabytes)

# NuGet 패키지
Plan.default.actual_limits.update!(nuget_max_file_size: 100.megabytes)

# Maven 패키지
Plan.default.actual_limits.update!(maven_max_file_size: 100.megabytes)

# PyPI 패키지
Plan.default.actual_limits.update!(pypi_max_file_size: 100.megabytes)

# Debian 패키지
Plan.default.actual_limits.update!(debian_max_file_size: 100.megabytes)

# Helm 차트
Plan.default.actual_limits.update!(helm_max_file_size: 100.megabytes)

# Generic 패키지
Plan.default.actual_limits.update!(generic_packages_max_file_size: 100.megabytes)

모든 파일 크기를 허용하려면 제한을 0으로 설정합니다.

반환되는 패키지 버전#

지정된 NuGet 패키지 이름의 버전을 요청할 때, GitLab 패키지 레지스트리는 최대 300개의 버전을 반환합니다.

Dependency Proxy 제한#

Dependency Proxy에 캐시된 이미지의 최대 파일 크기는 파일 유형에 따라 다릅니다:

• 이미지 blob: 5 GB
• 이미지 manifest: 10 MB

최대 담당자 및 검토자 수#

이슈 및 머지 리퀘스트는 다음 최대값을 적용합니다:

• 최대 담당자: 200
• 최대 검토자: 200

최대 프로젝트 push 미러 수#

각 프로젝트는 최대 10개의 활성화된 push 미러를 가질 수 있습니다. 이 제한은 과도한 동시 동기화 작업으로 인한 성능 문제를 방지합니다.

더 많은 미러가 필요한 경우:

• 사용하지 않는 미러를 비활성화합니다.
• 여러 대상을 단일 미러로 결합하여 미러를 통합합니다.

GitLab.com의 CDN 기반 제한#

애플리케이션 기반 제한 외에도, GitLab.com은 Git over SSH를 보호하기 위해 Cloudflare의 표준 DDoS 보호 및 Spectrum을 사용하도록 구성되어 있습니다. Cloudflare는 클라이언트 TLS 연결을 종료하지만 애플리케이션을 인식하지 못하며 사용자 또는 그룹에 연결된 제한에는 사용할 수 없습니다. Cloudflare 페이지 규칙 및 속도 제한은 Terraform으로 구성됩니다. 이러한 구성에는 악의적인 활동을 감지하고 공개되면 이러한 작업을 약화시킬 수 있는 보안 및 남용 구현이 포함되어 있으므로 공개되지 않습니다.

컨테이너 저장소 태그 삭제 제한#

컨테이너 저장소 태그는 컨테이너 레지스트리에 있으므로 각 태그 삭제는 컨테이너 레지스트리에 대한 네트워크 요청을 트리거합니다. 이 때문에 단일 API 호출이 삭제할 수 있는 태그 수를 20으로 제한합니다.

프로젝트 수준 Secure Files API 제한#

secure files API는 다음 제한을 적용합니다:

• 파일은 5 MB보다 작아야 합니다.
• 프로젝트는 100개 이상의 secure file을 가질 수 없습니다.

Changelog API 제한#

changelog API는 다음 제한을 적용합니다:

• from과 to 사이의 커밋 범위는 15000개 커밋을 초과할 수 없습니다.

Value Stream Analytics 제한#

• 각 네임스페이스(그룹 또는 프로젝트 등)는 최대 50개의 value stream을 가질 수 있습니다.
• 각 value stream은 최대 15개의 단계를 가질 수 있습니다.

감사 이벤트 스트리밍 대상 제한#

커스텀 HTTP 엔드포인트#

• 각 최상위 그룹은 최대 5개의 커스텀 HTTP 스트리밍 대상을 가질 수 있습니다.

Google Cloud Logging#

• 각 최상위 그룹은 최대 5개의 Google Cloud Logging 스트리밍 대상을 가질 수 있습니다.

Amazon S3#

• 각 최상위 그룹은 최대 5개의 Amazon S3 스트리밍 대상을 가질 수 있습니다.

SBOM을 사용한 종속성 스캐닝 제한#

SBOM 기능을 사용한 종속성 스캐닝은 다음 제한이 있는 내부 API를 사용합니다:

• 시간당 프로젝트당 최대 업로드 요청 수: 400
• 시간당 프로젝트당 최대 다운로드 요청 수: 6000

종속성 스캐닝 설정을 사용하여 GitLab Self-Managed 인스턴스에 이 제한을 구성할 수 있습니다.

커밋 및 Files API 제한#

커밋 및 Files API는 다음 엔드포인트에 최대 크기 및 속도 제한을 적용합니다:

• POST /projects/:id/repository/commits - 커밋 생성
• POST /projects/:id/repository/files/:file_path - 저장소에 파일 생성
• PUT /projects/:id/repository/files/:file_path - 저장소의 파일 업데이트
• 최대 요청 크기: 이 제한을 초과하는 요청은 다음 메시지와 함께 413 Request Entity Too Large 오류를 받습니다: RequestBody: upload failed: the upload size <size> is over maximum of 314572800 bytes: entity is too large. 기본값은 300 MB (314,572,800바이트)입니다.
• 속도 제한: 20 MB를 초과하는 요청에 대해 30초당 3개 요청.

최대 요청 크기는 GITLAB_COMMITS_MAX_REQUEST_SIZE_BYTES 환경 변수를 설정하여 GitLab Self-Managed에서 구성할 수 있습니다. 이 변수는 최대 요청 크기를 바이트 단위로 설정합니다. 환경 변수를 설정하는 방법에 대한 지침은 HTTP 요청 제한에서 찾을 수 있습니다.

모든 인스턴스 제한 나열#

모든 인스턴스 제한값을 나열하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits

샘플 출력:

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

일부 제한 값은 Rails 콘솔에서의 필터링으로 인해 목록에 [FILTERED]로 표시됩니다.