GitLab 애플리케이션 제한 사항

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

대부분의 대형 애플리케이션과 마찬가지로 GitLab은 특정 기능에서 제한을 강제하여 최소한의 성능 품질을 유지합니다. 일부 기능을 무제한으로 허용하는 것은 보안, 성능, 데이터에 영향을 줄 수 있거나 애플리케이션에 할당된 리소스를 고갈시킬 수 있습니다.

인스턴스 구성

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

구성한 제한에 따라 다음을 볼 수 있습니다:

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

이 페이지는 모든 사용자에게 표시되므로 인증되지 않은 사용자는 해당 정보만 볼 수 있습니다.

인스턴스 구성 페이지 방문 방법:

  1. 좌측 사이드바에서 도움말 () > 도움말을 선택합니다.
  2. 도움말 페이지에서 현재 인스턴스 구성 확인을 선택합니다.

직접 URL은 <gitlab_url>/help/instance_configuration입니다. GitLab.com의 경우 https://gitlab.com/help/instance_configuration를 방문할 수 있습니다.

요청 제한

요청 제한을 사용하여 GitLab의 보안 및 내구성을 개선할 수 있습니다.

요청 제한 구성 방법에 대해 자세히 알아보세요.

이슈 생성

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

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

  • 기본 요청 제한: 기본적으로 비활성화됨.

사용자 또는 IP별

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

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

  • 기본 요청 제한: 기본적으로 비활성화됨.

원시 엔드포인트별

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

원시 엔드포인트 요청 제한에 대해 자세히 알아보세요.

  • 기본 요청 제한: 프로젝트, 커밋, 파일 경로당 300개의 요청.

보호된 경로별

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

GitLab은 다음 경로에 대해 기본적으로 요청 제한을 적용합니다: 

'/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'

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

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

패키지 레지스트리

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

  • 기본 요청 제한: 기본적으로 비활성화됨.

Git LFS

이 설정은 사용자별 Git LFS 요청 속도를 제한합니다. 자세한 내용은 GitLab Git Large File Storage (LFS) Administration을 참조하세요.

  • 기본 요청 제한: 기본적으로 비활성화됨.

파일 API

이 설정은 파일 API별 사용자 또는 IP 주소당 요청 속도를 제한합니다. 자세한 내용은 파일 API 요청 제한을 참조하세요.

  • 기본 요청 제한: 기본적으로 비활성화됨.

폐기된 API 엔드포인트

이 설정은 사용자별 또는 IP 주소당 폐기된 API 엔드포인트의 요청 속도를 제한합니다. 자세한 내용은 폐기된 API 요청 제한을 참조하세요.

  • 기본 요청 제한: 기본적으로 비활성화됨.

가져오기/내보내기

이 설정은 그룹 및 프로젝트의 가져오기/내보내기 작업을 제한합니다.

제한 기본값 (분당 사용자당)
프로젝트 가져오기 6
프로젝트 내보내기 6
프로젝트 내보내기 다운로드 1
그룹 가져오기 6
그룹 내보내기 6
그룹 내보내기 다운로드 1

자세한 내용은 가져오기/내보내기 요청 제한을 참조하세요.

멤버 초대

그룹 계층 구조당 일일 최대 멤버 초대 횟수를 제한합니다.

  • GitLab.com: 무료 멤버는 하루에 20명의 멤버를 초대할 수 있으며, 프리미엄 체험 및 얼티메이트 체험 멤버는 하루에 50명의 멤버를 초대할 수 있습니다.
  • Self-managed: 초대 횟수를 제한하지 않습니다.

웹훅 속도 제한

웹훅이 분당당 호출될 수 있는 횟수를 최상위 네임스페이스당 제한합니다. 이는 프로젝트 및 그룹 웹훅에만 적용됩니다.

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

셀프 메니지드 설치에 대한 이 제한을 설정하려면, 다음을 GitLab Rails 콘솔에서 실행하세요: 

# 기본 요금제에 대한 제한이 없다면, 다음과 같이 생성할 수 있습니다:
# Plan.default.create_limits!

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

이를 0으로 설정하여 비활성화하세요.

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

검색 속도 제한

  • GitLab 14.9에 도입됨.
  • GitLab 15.9에서 이 변경됨으로 인해 이슈, 병합 요청 및 epic 검색이 속도 제한에 포함됩니다.
  • GitLab 16.0에서 인증된 요청을 위한 검색 스코프에 속도 제한이 적용되었습니다.

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

제한 기본값 (분당 요청)
인증된 사용자 300
인증되지 않은 사용자 100

분당 검색 요청 제한을 초과하는 경우 다음과 같은 오류가 발생합니다: 

이 엔드포인트가 너무 많은 요청을 받았습니다. 나중에 다시 시도하십시오.

파이프라인 생성 속도 제한

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

pipeline creation rate limits에 대해 자세히 알아보기.

Gitaly 동시성 제한

클론 트래픽은 Gitaly 서비스에 큰 부담을 줄 수 있습니다. 그런 작업량이 Gitaly 서버를 압도하지 않도록, Gitaly 구성 파일에서 동시성 제한을 설정할 수 있습니다.

Gitaly concurrency limits에 대해 자세히 알아보기.

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

이슈, 병합 요청 또는 커밋 당 댓글 수

이슈, 병합 요청 또는 커밋에 제출할 수 있는 댓글 수에는 제한이 있습니다. 제한에 도달하면 시스템 노트는 계속 추가될 수 있지만 사용자가 제출한 댓글은 실패합니다.

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

이슈, 병합 요청 및 epic의 설명 및 댓글 크기

이슈, 병합 요청, epic의 설명 및 댓글 크기에는 제한이 있습니다. 제한을 초과한 텍스트 본문을 추가하려고 하면 오류가 발생하며 아이템이 생성되지 않습니다.

이 제한은 나중에 낮은 숫자로 변경될 수 있습니다.

  • 최대 크기: ~1백만 문자 / ~1MB.

커밋 제목 및 설명의 크기

임의로 큰 메시지를 가진 커밋이 GitLab에 푸시될 수 있지만, 다음과 같은 디스플레이 제한이 적용됩니다:

  • 제목 - 커밋 메시지의 첫 줄. 1 KiB로 제한됨.
  • 설명 - 커밋 메시지의 나머지. 1 MiB로 제한됨.

커밋이 푸시되면 GitLab은 이슈(#123) 및 병합 요청(!123)에 대한 참조를 링크로 대체하여 처리합니다.

큰 수의 커밋이 포함된 브랜치가 푸시되면, 마지막 100개의 커밋만 처리됩니다.

마일스톤 개요에 있는 이슈 수

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

  • 제한: 500개의 이슈.

Git push 당 파이프라인 수

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

병합 요청 파이프라인에는 제한이 없습니다. Git push가 여러 병합 요청을 동시에 업데이트하는 경우, 업데이트된 각 병합 요청에 대해 병합 요청 파이프라인이 트리거될 수 있습니다.

단일 Git push 이벤트에 대해 모든 수의 파이프라인이 트리거될 수 있도록 제한을 제거하려면, 관리자는 git_push_create_all_pipelines 기능 플래그를 활성화할 수 있습니다. 이 기능 플래그를 활성화하는 것은 권장되지 않으며, 한 번에 너무 많은 변경 사항이 푸시되고 실수로 많은 파이프라인이 생성되면 GitLab 인스턴스에 과도한 부하를 발생시킬 수 있습니다.

활동 기록 보존

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

임베디드 메트릭 수

성능 상의 이유로 GitLab Flavored Markdown (GLFM)에 메트릭을 임베딩하는 데 제한이 있습니다.

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

웹훅 제한

웹훅 속도 제한도 참조하십시오.

웹훅 수

자체 관리형 설치에서 그룹 또는 프로젝트 웹훅의 최대 수를 설정하려면, 다음을 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의 웹훅 제한을 참조하십시오.

웹훅 페이로드 크기

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

웹훅 타임아웃

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에 기록됩니다.

풀 미러링 간격

풀 갱신 사이의 최소 대기 시간은 기본적으로 300초 (5분)입니다. 예를 들어, 특정 300초의 기간에 풀 갱신이 단 한 번만 실행되며, 이 횟수에 관계없이 트리거됩니다.

이 설정은 프로젝트 API를 통해 호출되는 풀 갱신 또는 설정 > 저장소 > 저장소 미러링에서 지금 업데이트()를 선택하여 강제로 업데이트하는 경우에 해당됩니다. 이 설정은 Sidekiq가 풀 미러링에 사용하는 자동 30분 간격 스케줄에 영향을 미치지 않습니다.

자체 관리형 설치에서 이 제한을 변경하려면, 다음을 GitLab Rails 콘솔에서 실행하십시오: 

# 기본 계획에 제한이 없는 경우, 다음으로 제한을 생성할 수 있습니다:
# Plan.default.create_limits!

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

자동 응답기에서 수신한 이메일

GitLab은 X-Autoreply 헤더를 찾아 자동 응답기에서 보낸 모든 수신 이메일을 무시합니다. 이러한 이메일은 이슈나 병합 요청에 댓글을 생성하지 않습니다.

에러 추적을 통한 Sentry를 통해 보내진 데이터 양

GitLab로 보내진 Sentry 페이로드는 보안상의 이유와 메모리 사용량을 제한하기 위해 1MB의 최대 제한이 있습니다.

REST API의 오프셋 기반 페이징으로 허용되는 최대 오프셋

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

자체 관리 설치에 이 제한을 설정하려면 다음을 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 SaaS 가입자는 계획별로 정의된 다른 제한을 가지며, 해당 계획 하의 모든 프로젝트에 영향을 미칩니다.
  • GitLab Premium 자체 관리 또는 더 높은 설치에서, 이 제한은 모든 프로젝트에 영향을 미치는 기본 계획 하에 정의되어 있습니다. 이 제한은 기본적으로 (0)로 비활성화되어 있습니다.

자체 관리 설치에 이 제한을 설정하려면 다음을 GitLab Rails 콘솔에서 실행하세요: 

# 기본 계획에 제한이 없는 경우 다음을 사용하여 생성할 수 있습니다:
# Plan.default.create_limits!

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

이를 비활성화하려면 제한을 0으로 설정하세요.

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

작업이 실행될 수 있는 기본 최대 시간은 60분입니다. 60분을 초과하는 작업은 시간 초과됩니다.

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

파이프라인에서 실행되는 배포 작업의 최대 수

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

GitLab 자체 관리 및 SaaS 계획에 대한 기본 제한은 기본 500입니다.

자체 관리 설치에 제한을 변경하려면 다음 GitLab Rails 콘솔 명령을 사용하여 기본 계획의 제한을 변경하세요: 

# 기본 계획에 제한이 없는 경우 다음을 사용하여 생성할 수 있습니다:
# Plan.default.create_limits!

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

이를 비활성화하려면 제한을 0으로 설정하세요.

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

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

새로운 구독이 제한을 초과하는 전체 구독 수를 초래하는 경우, 해당 구독은 유효하지 않은 것으로 간주됩니다.

  • GitLab SaaS: 제한은 계획별로 정의됩니다 및 해당 계획 하의 모든 프로젝트에 영향을 미칩니다.
  • 자체 관리: GitLab Premium 또는 Ultimate에서, 이 제한은 모든 프로젝트에 영향을 미치는 기본 계획 하에 정의되어 있으며 기본적으로 2의 제한이 있습니다.

자체 관리 설치에 이 제한을 설정하려면 다음을 GitLab Rails 콘솔에서 실행하세요: 

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

이를 비활성화하려면 제한을 0으로 설정하세요.

파이프라인 트리거 수 제한

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

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

이를 비활성화하려면 제한을 0으로 설정하세요. Self-Managed 인스턴스의 기본값은 150입니다.

Self-Managed 설치에서 이 제한을 100으로 설정하려면 GitLab 레일즈 콘솔에서 다음을 실행하세요: 

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

이 제한은 GitLab.com에서 활성화됩니다.

파이프라인 스케줄 수

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

GitLab SaaS 구독자는 플랜별로 정의된 다양한 제한이 적용되며 해당 플랜에 속하는 모든 프로젝트에 영향을 미칩니다.

GitLab Premium Self-Managed 또는 이상의 설치에서는 모든 프로젝트에 영향을 주는 default 플랜에 이 제한이 정의됩니다. 기본적으로 10개의 파이프라인 스케줄 제한이 있습니다.

Self-Managed 설치에서 이 제한을 설정하려면 GitLab 레일즈 콘솔에서 다음을 실행하세요: 

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

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

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

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

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

최소값은 24이며, 즉 60분당 한 번의 파이프라인입니다.
최대값은 없습니다.

Self-Managed 설치에서 이 제한을 1440으로 설정하려면 GitLab 레일즈 콘솔에서 다음을 실행하세요: 

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

이 제한은 GitLab.com에서 활성화됩니다.

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

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

기본적으로 Self-Managed 인스턴스에서는 처리 가능한 스케줄 규칙의 수에 제한을 두지 않습니다.

Self-Managed 설치에서 이 제한을 설정하려면 GitLab 레일즈 콘솔에서 다음을 실행하세요: 

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

이 제한은 GitLab.com에서 활성화됩니다.

인스턴스 레벨 변수 수

인스턴스 레벨 CI/CD 변수의 총 수는 인스턴스 레벨에서 제한됩니다.
이 제한은 새 인스턴스 레벨 변수가 생성될 때마다 확인됩니다.
새 변수가 총 변수 수를 제한을 초과하는 경우, 해당 새 변수는 생성되지 않습니다.

Self-Managed 인스턴스에서는 이 제한이 default 플랜에 대해 정의됩니다. 기본적으로 이 제한은 25로 설정됩니다.

Self-Managed 설치에서 이 제한을 새 값으로 업데이트하려면 GitLab 레일즈 콘솔에서 다음을 실행하세요: 

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

그룹 레벨 변수 수

인스턴스 레벨에서 그룹 레벨 CI/CD 변수의 총 수를 제한할 수 있습니다.
이 제한은 새 그룹 레벨 변수가 생성될 때마다 확인됩니다.
새 변수가 총 변수 수를 제한을 초과하는 경우, 해당 새 변수는 생성되지 않습니다.

Self-Managed 인스턴스에서는 이 제한이 default 플랜에 대해 정의됩니다. 기본적으로 이 제한은 30000으로 설정됩니다.

Self-Managed 설치에서 이 제한을 새 값으로 업데이트하려면 GitLab 레일즈 콘솔에서 다음을 실행하세요: 

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

프로젝트 레벨 변수의 수

프로젝트 레벨 CI/CD 변수의 총 수는 인스턴스 레벨로 제한됩니다. 이 제한은 새로운 프로젝트 레벨 변수가 만들어질 때마다 확인됩니다. 새 변수가 총 변수 수를 초과하게 하면 새 변수가 만들어지지 않습니다.

셀프 매니지드 인스턴스에서 이 제한은 default 플랜을 위해 정의됩니다. 기본적으로 이 제한은 8000으로 설정됩니다.

셀프 매니지드 인스톨러션에서 이 제한을 새 값으로 업데이트하려면, 다음을 GitLab 레일즈 콘솔에서 실행하세요: 

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

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

  • GitLab 16.3에서 ci_max_artifact_size_annotations 제한 도입됨.

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

제한은 메가바이트 단위로 설정되며, 정의할 수 있는 가장 작은 값은 1 MB입니다.

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

아티팩트 제한 이름 기본값
ci_max_artifact_size_accessibility 0
… (중략) … …

예를 들어, 셀프 매니지드 인스톨러션에서 ci_max_artifact_size_junit 제한을 10 MB로 설정하려면, 다음을 GitLab 레일즈 콘솔에서 실행하세요: 

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

GitLab Pages 웹사이트 당 파일 수

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

이것은 GitLab 셀프 매니지드 및 SaaS 플랜에 대한 기본 제한입니다.

셀프 매니지드 인스턴스에서 이 제한을 업데이트하려면 GitLab 레일즈 콘솔을 사용하세요. 예를 들어, 제한을 100으로 변경하려면: 

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

GitLab Pages 웹 사이트 당 사용자 정의 도메인 수

GitLab Pages 웹 사이트 당 총 사용자 정의 도메인 수는 GitLab SaaS에 대해 150으로 제한됩니다.

GitLab Self-Managed의 기본 제한은 0 (무제한)입니다. 자체 관리형 인스턴스의 제한을 설정하려면 관리 영역을 사용하세요.

범위별 등록된 러너 수

  • GitLab 13.12에 도입. 기본적으로 비활성화됨.
  • GitLab.com에서 GitLab 14.3에 활성화됨.
  • Self-Managed에서 GitLab 14.4에 활성화됨.
  • GitLab 14.4에서 기능 플래그 ci_runner_limits 제거됨.
  • GitLab 14.6에서 기능 플래그 ci_runner_limits_override 제거됨.

등록된 러너의 총 수는 그룹 및 프로젝트 수준에서 제한됩니다. 새 러너가 등록될 때마다, GitLab은 지난 3개월간 활성화된 러너 대상으로 이러한 제한을 확인합니다. 러너의 등록이 제한값을 초과하면 해당 범위 내의 러너 등록 토큰에 의해 결정됩니다. 제한값을 0으로 설정하면 제한이 비활성화됩니다.

GitLab SaaS 구독자는 해당 플랜을 사용하는 모든 프로젝트에 영향을주는 기본 제한이 정의되어 있습니다.

스스로 관리되는 GitLab Premium 및 Ultimate 제한은 모든 프로젝트에 영향을주는 기본 플랜에 의해 정의됩니다:

러너 범위 기본 값
ci_registered_group_runners 1000
ci_registered_project_runners 1000

이러한 제한을 업데이트하려면 다음을 실행하세요. GitLab 레일즈 콘솔에서: 

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

작업 로그의 최대 파일 크기

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

이 제한을 변경할 수 있습니다. GitLab 레일즈 콘솔에서 ci_jobs_trace_size_limit를 새 값으로 업데이트하세요. 

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

GitLab Runner에는 또한 러너의 최대 로그 크기를 구성하는 output_limit 설정 이 있습니다. 러너 제한을 초과하는 작업은 계속 실행되지만 로그는 제한에 도달하면 자르게 됩니다.

프로젝트 당 활성 DAST 프로파일 일정의 최대 수

프로젝트 당 활성 DAST 프로파일 일정의 수를 제한합니다. DAST 프로파일 일정은 활성 또는 비활성 일 수 있습니다.

이 제한을 변경할 수 있습니다. GitLab 레일즈 콘솔에서 dast_profile_schedules을 새 값으로 업데이트하세요. 

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

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

단일 CI/CD 구성 YAML 파일의 기본 최대 크기는 1MB이고 기본 깊이는 100입니다.

이러한 제한을 변경할 수 있습니다. GitLab 레일즈 콘솔에서:

  • 최대 YAML 크기를 업데이트하려면 max_yaml_size_bytes를 새 값으로 업데이트하세요. 단위는 MB입니다. 

    ApplicationSetting.update(max_yaml_size_bytes: 2.megabytes)

    max_yaml_size_bytes 값은 YAML 파일 크기와 직접적으로 관련이있는 것이 아니라 관련 객체에 할당 된 메모리입니다.

  • 최대 YAML 깊이를 업데이트하려면 max_yaml_depth를 새 값으로 업데이트하세요. 단위는 라인 수입니다. 

    ApplicationSetting.update(max_yaml_depth: 125)

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

모든 포함된 YAML 구성 파일을 사용하여 풀 파이프라인 구성을위한 메모리 할당의 최대 양입니다.

새로운 스스로 관리되는 인스턴스의 경우 기본값은 157286400 바이트 (150MB)입니다.

GitLab 16.3 이상으로 업그레이드하는 기존의 스스로 관리되는 인스턴스의 경우, 기본값은 [max_yaml_size_bytes (기본값 1MB)과 ci_max_includes (기본값 150) 을 곱해서 계산됩니다. 두 제한 모두 수정되지 않았다면 기본값은 1MB x 150 = 157286400 바이트 (150MB)로 설정됩니다.

이 제한을 변경할 수 있습니다. GitLab 레일즈 콘솔에서 ci_max_total_yaml_size_bytes를 새 값으로 업데이트하세요. 예를 들어, 20MB로 설정하려면: 

ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)

dotenv 변수 제한

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

이를 비활성화하려면 제한을 0으로 설정하십시오. Self-Managed 인스턴스의 기본 설정은 20입니다.

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

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

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

dotenv 파일 크기 제한

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

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

Self-Managed 설치에서 이 제한을 5 KB로 설정하려면 GitLab Rails 콘솔에서 다음을 실행하십시오: 

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

CI/CD 작업 주석 제한

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

이를 비활성화하려면 제한을 0으로 설정하십시오. Self-Managed 인스턴스의 기본 설정은 20입니다.

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

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

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

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

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

Self-Managed 설치에서 이 제한을 100 KB로 설정하려면 GitLab Rails 콘솔에서 다음을 실행하십시오: 

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

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

인바운드 장애 관리 알림 제한

이 설정은 일정 기간 동안 수신된 경고 페이로드의 수를 제한합니다.

장애 관리 속도 제한에 대해 자세히 읽어보세요.

Prometheus 경보 JSON 페이로드

notify.json 엔드포인트로 보낸 Prometheus 경보 페이로드는 1 MB로 제한됩니다.

일반적인 경보 JSON 페이로드

notify.json 엔드포인트로 보낸 경보 페이로드는 1 MB로 제한됩니다.

메트릭 대시보드 YAML 파일

구문 분석된 메트릭 대시보드 YAML 파일이 차지하는 메모리 용량은 1 MB를 초과할 수 없습니다.

각 YAML 파일의 최대 깊이는 100으로 제한됩니다. YAML 파일의 최대 깊이는 가장 깊이 중첩된 키의 중첩 수입니다. 가장 깊게 중첩된 키의 경로 상의 각 해시 및 배열은 해당 깊이에 포함됩니다. 예를 들어, 다음 YAML의 가장 깊게 중첩된 키의 깊이는 7입니다: 

dashboard: '테스트 대시보드'
links:
- title: 링크 1
  url: https://gitlab.com
panel_groups:
- group: 그룹 A
  priority: 1
  panels:
  - title: "슈퍼 차트 A1"
    type: "area-chart"
    y_label: "y_label"
    weight: 1
    max_value: 1
    metrics:
    - id: metric_a1
      query_range: '쿼리'
      unit: 단위
      label: 범례 레이블

환경 대시보드 제한

Tier: 프리미엄, 얼티메이트 Offering: GitLab.com, Self-managed, GitLab 전용

환경 대시보드에서 표시되는 프로젝트의 최대 수에 대해 자세히 알아보세요.

배포 보드의 환경 데이터

배포 보드는 쿠버네티스에서 환경 관련 정보를 로드합니다. 그러나 쿠버네티스에서 읽은 특정 환경의 데이터가 10 MB를 초과하면 표시되지 않습니다.

병합 요청

차이 제한

GitLab은 다음과 같은 제한을 가지고 있습니다:

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

  • 변경된 파일의 수.
  • 변경된 라인의 수.
  • 표시된 변경의 누적 크기.

하한 제한은 추가 차이가 축소되도록 합니다. 상한 제한은 더 이상 변경 사항을 렌더링하지 못하도록 합니다. 이러한 제한에 대한 자세한 정보는 개발 문서를 참조하세요.

병합 요청 보고서 크기 제한

20MB 제한을 초과하는 보고서는 로드되지 않습니다. 영향을 받는 보고서:

고급 검색 제한

색인화된 최대 파일 크기

Elasticsearch에 색인화된 저장소 파일 내용에 대한 제한을 설정할 수 있습니다. 이 제한을 초과하는 파일은 파일 이름만 색인화됩니다. 파일 내용은 색인화되지 않으며 검색할 수 없습니다.

이러한 제한을 설정하면 색인화 프로세스의 메모리 사용량과 전체 색인 크기를 줄일 수 있습니다. 이 값은 기본적으로 1024 KiB (1 MiB)로 설정되어 있으며, 이 크기를 초과하는 텍스트 파일은 사람이 읽을 목적이 아닐 가능성이 높습니다.

무제한 파일 크기는 지원되지 않기 때문에 이 제한을 반드시 설정해야 합니다. 이 값을 GitLab Sidekiq 노드의 메모리 양보다 크도록 설정하면 GitLab Sidekiq 노드는 색인화 중에 사전 할당된 이 메모리 양 때문에 메모리 부족 상태에 빠집니다.

최대 필드 길이

고급 검색용으로 인덱싱 된 텍스트 필드의 내용에 대한 제한을 설정할 수 있습니다. 최대값을 설정하면 색인화 프로세스의 부하를 줄일 수 있습니다. 텍스트 필드가 이 제한을 초과하면 텍스트가 이 문자 수로 자르게 되며, 나머지 텍스트는 색인되지 않으며 검색이 불가능합니다. 이 제한은 저장소 파일을 제외한 모든 색인화된 데이터에 적용됩니다. 자세한 내용은 색인화된 최대 파일 크기를 참조하세요.

  • GitLab.com에서의 필드 길이 제한: 20,000 문자
  • 자체 설치된 설치에서는 기본적으로 필드 길이에 제한이 없습니다.

자체 설치된 설치에서는 고급 검색 사용를 활성화할 때 이 제한을 구성할 수 있습니다. 제한을 해제하려면 0의 값으로 설정하세요.

수학 렌더링 제한

  • GitLab 16.5에서 도입됨.
  • Wiki 및 저장소 파일의 50노드 제한이 제거되었습니다.
  • GitLab 16.9에서 Wiki 및 저장소 파일의 수학 제한을 비활성화하는 그룹 수준 설정이 추가되었습니다.

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

이슈, 병합 요청, 에픽, 위키 및 저장소 파일의 제한:

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

이러한 제한은 자체 관리 인스턴스에서 해제하고 사용자 입력을 신뢰하는 경우에만 적용할 수 있습니다.

GitLab 레일스 콘솔을 사용해 이러한 제한을 비활성화할 수도 있습니다.

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

제한이 해제되면 이슈, 병합 요청, 에픽, 위키 및 저장소 파일에서 거의 무제한으로 수학이 렌더링됩니다. 즉, 악의적인 사용자가 브라우저에서 보기할 때 DoS를 유발할 수 있는 수학을 추가할 수 있습니다. 반드시 신뢰하는 사람만이 콘텐츠를 추가할 수 있도록 보장해야 합니다.

위키 제한

코드片 제한

코드片 설정에 관한 문서를 참조하세요.

디자인 관리 제한

이슈에 디자인 추가 섹션의 제한 사항을 확인하세요.

푸시 이벤트 제한

최대 푸시 크기

허용되는 최대 푸시 크기.

자체 관리 인스턴스의 경우 기본값이 설정되어 있지 않습니다. GitLab.com의 경우 계정 및 제한 설정을 참조하세요.

웹훅 및 프로젝트 서비스

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

자세한 정보는 다음을 참조하세요:

활동

단일 푸시에서의 총 변경 내용(브랜치 또는 태그)을 확인하여 개별 푸시 이벤트 또는 대량 푸시 이벤트가 생성되는지 확인합니다.

추가 정보는 푸시 이벤트 활동 제한 및 대량 푸시 이벤트 문서에서 확인할 수 있습니다.

패키지 레지스트리 제한

파일 크기 제한

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 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)

# 일반 패키지의 경우
Plan.default.actual_limits.update!(generic_packages_max_file_size: 100.megabytes)

제한을 0으로 설정하여 모든 파일 크기를 허용할 수 있습니다.

리턴된 패키지 버전

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

종속성 프록시 제한

의존성 프록시에서 캐시된 이미지의 최대 파일 크기는 파일 유형별로 다음과 같이 달라집니다:

  • 이미지 Blob: 5 GB
  • 이미지 Manifest: 10 MB

최대 담당자 및 검토자 수

  • 최대 담당자는 GitLab 15.6에서 도입됨.
  • 최대 검토자는 GitLab 15.9에서 도입됨.

이슈 및 병합 요청은 다음의 최대치를 적용합니다:

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

GitLab.com의 CDN 기반 제한

응용 프로그램 기반 제한 외에, GitLab.com은 클라우드플레어의 표준 DDoS 보호 및 Git over SSH 보호를 위해 구성되어 있습니다. 클라우드플레어는 클라이언트 TLS 연결을 종료하지만 응용프로그램 인식은 불가능하며 사용자 또는 그룹과 관련된 제한에 사용할 수 없습니다. 클라우드플레어 페이지 규칙 및 속도 제한은 테라폼으로 구성됩니다. 이러한 구성은 공개적으로 제공되지 않으며, 악의적인 활동을 감지하는 보안 및 남용 구현이 포함되어 있으며 이를 공개로 공개하면 이러한 운영을 저해할 수 있습니다.

컨테이너 레지스트리 태그 삭제 제한

컨테이너 레지스트리 태그는 컨테이너 레지스트리에 있으며, 따라서 각 태그 삭제는 컨테이너 레지스트리로의 네트워크 요청을 트리거합니다. 이로 인해, 단일 API 호출에서 삭제할 수 있는 태그 수를 20개로 제한합니다.

프로젝트 수준의 보안 파일 API 제한

보안 파일 API는 다음과 같은 제한을 적용합니다:

  • 파일 크기는 5 MB보다 작아야 합니다.
  • 프로젝트당 보안 파일은 100개를 초과할 수 없습니다.

변경 로그 API 제한

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

  • from과 to 사이의 커밋 범위는 15,000개를 초과할 수 없습니다.

가치 스트림 분석 한계

  • 각 네임스페이스(그룹 또는 프로젝트와 같은) 당 최대 50개의 가치 스트림이 가능합니다.
  • 각 가치 스트림 당 최대 15개의 단계가 가능합니다.

감사 이벤트 스트리밍 대상 한계

사용자 지정 HTTP 엔드포인트

  • 각 최상위 그룹 당 최대 5개의 사용자 지정 HTTP 스트리밍 대상이 가능합니다.

구글 클라우드 로깅

  • 각 최상위 그룹 당 최대 5개의 구글 클라우드 로깅 스트리밍 대상이 가능합니다.

Amazon S3

  • 각 최상위 그룹 당 최대 5개의 Amazon S3 스트리밍 대상이 가능합니다.

모든 인스턴스 제한 목록

모든 인스턴스 제한 값을 확인하려면 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: 100,
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]로 표시됩니다.