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 대형 파일 저장소 (LFS) 관리를 참조하세요.

  • 기본 요금 제한: 기본 값은 비활성화됨.

파일 API

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

  • 기본 요금 제한: 기본 값은 비활성화됨.

사용되지 않는 API 엔드포인트

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

  • 기본 요금 제한: 기본 값은 비활성화됨.

가져오기/내보내기

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

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

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

구성원 초대

그룹 계층구조 당 하루에 허용되는 최대 구성원 초대 수를 제한합니다.

  • GitLab.com: 무료 구성원은 하루에 20명의 구성원을 초대할 수 있으며, 프리미엄 체험 및 얼티메이트 체험 구성원은 하루에 50명의 구성원을 초대할 수 있습니다.
  • Self-Managed: 초대에 제한이 없습니다.

웹훅 요금 제한

  • GitLab 15.1에서 훅 당에서 상위 레벨 네임스페이스 당으로 변경됨.

프로젝트 및 그룹 웹훅에 대해 분당 요청 횟수를 제한합니다.

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

자체 관리 설치에 이 한도를 설정하려면 다음을 실행하세요. GitLab 레일스 콘솔에서 다음을 실행하세요. 

# 기본 계획에 대한 한도가 없는 경우 다음과 같이 생성할 수 있습니다:
# Plan.default.create_limits!

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

이 한도를 0으로 설정하여 비활성화할 수 있습니다.

  • 기본 요금 제한: 비활성화됨 (무제한).

검색 요금 제한

  • GitLab 15.9에서 이슈, 병합 요청 및 에픽 검색을 요금 제한에 포함되도록 변경됨.
  • GitLab 16.0에서 인증된 요청을 위해 검색 범위에 요금 제한이 적용되도록 변경됨.

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

제한 기본값 (분당 요청 수)
인증된 사용자 300
미인증된 사용자 100

분당 검색 요청이 제한을 초과하면 다음과 같은 오류가 발생합니다. 

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

파이프라인 생성 요금 제한

  • GitLab 15.0에서 도입됨.

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

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

Gitaly 동시성 제한

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

자세한 내용은 Gitaly 동시성 제한을 참조하세요.

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

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

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

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

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

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

앞으로 이 제한이 더 낮은 숫자로 변경될 수 있습니다.

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

커밋 제목 및 설명의 크기

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

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

커밋이 푸시되면 GitLab은 이슈(#123) 및 병합 요청(!123)을 참조하는 부분을 이슈와 병합 요청의 링크로 대체합니다.

커밋이 많은 브랜치가 푸시되면 마지막 100개의 커밋만 처리됩니다.

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

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

  • 제한: 500개 이슈.

Git 푸시 당 파이프라인 수

단일 Git 푸시로 여러 변경 사항(여러 태그 또는 브랜치)을 푸시하는 경우, 태그 또는 브랜치 파이프라인은 4개만 트리거됩니다. 이 제한은 git push --all 또는 git push --mirror를 사용하여 실수로 많은 파이프라인을 만드는 것을 방지합니다.

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

단일 Git 푸시 이벤트에 대해 임의의 수의 파이프라인이 트리거될 수 있도록 제한을 제거하려면 관리자는 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에서 차단됩니다.

차단된 재귀 웹훅 호출은 "재귀 웹훅 실행으로부터 차단" 메시지와 함께 auth.log에 기록됩니다.

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

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

GitLab 자체 관리의 기본 제한은 0입니다(무제한).

자체 관리 설치의 경우 다음을 GitLab Rails 콘솔에서 실행하여 이 제한을 변경할 수 있습니다: 

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

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

제한을 해제하려면 0으로 설정하세요.

Pull mirroring interval

풀 갱신 간의 최소 대기 시간은 기본적으로 300초(5분)로 설정됩니다. 예를 들어, 풀 갱신은 300초 동안 한 번만 실행되며, 여러 번 트리거해도 동일한 기간에 한 번만 실행됩니다.

이 설정은 프로젝트 API를 사용하여 호출된 풀 갱신이나 Settings > Repository > Mirroring repositories에서 Update now ()를 선택하여 업데이트를 강제로 실행할 때 적용됩니다. 이 설정은 풀 미러링에 의해 Sidekiq에서 사용되는 자동 30분 간격 스케줄에 영향을 주지 않습니다.

이 한도를 자체 설치에 대해 변경하려면 다음을 GitLab 레일즈 콘솔에서 실행하세요: 

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

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

다양한 방법으로 생성한 병합 요청 알아보기

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

Sentry를 통한 오류 추적을 통해 전송된 데이터 양

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

REST API에서 오프셋 기반 페이징의 최대 오프셋 허용

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

이 한도를 자체 설치에 대해 변경하려면 다음을 GitLab 레일즈 콘솔에서 실행하세요: 

# 기본 플랜에 대한 제한이 없는 경우, 다음을 사용하여 제한을 생성할 수 있습니다:
# 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 이상의 자체 관리형 설치에서, 이 한도는 모든 프로젝트에 영향을 주는 default 플랜 하에 정의되어 있습니다. 기본적으로 이 한도는 (0)로 비활성화됩니다.

이 한도를 자체 설치에 대해 변경하려면 다음을 GitLab 레일즈 콘솔에서 실행하세요: 

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

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

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

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

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

  • 특정 프로젝트에서 프로젝트의 CI/CD 설정에서 해당 한도를 변경할 수 있습니다. 이 한도는 10분부터 1개월 사이여야 합니다.
  • 러너 레벨에서도 변경 가능합니다. 이 한도는 10분 이상이어야 합니다.

파이프라인에서 허용되는 최대 배포 작업 수

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

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

이 한도를 변경하려면 다음 GitLab Rails 콘솔 명령을 사용하여 default 플랜의 한도를 변경하세요: 

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

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

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

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

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

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

  • GitLab SaaS: 제한은 계획별로 정의됩니다 및 해당 계획의 모든 프로젝트에 영향을 줍니다.
  • 자체 관리형: GitLab Premium 또는 Ultimate에서, 이 한도는 모든 프로젝트에 영향을 주는 default 플랜 하에 정의되어 있으며, 기본적으로 2의 구독 한도가 설정되어 있습니다.

이 한도를 자체 설치에 대해 변경하려면 다음을 GitLab Rails 콘솔에서 실행하세요: 

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

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

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

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

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

이를 비활성화하려면 제한을 0으로 설정하면 됩니다. 셀프 매니지드 인스턴스의 기본값은 25000입니다.

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

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

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

파이프라인 스케줄 수

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

GitLab SaaS 구독자에는 계획별로 정의된 서로 다른 제한이 적용되며, 해당 계획에 속한 모든 프로젝트에 영향을 줍니다.

GitLab Premium의 셀프 매니지드 또는 더 높은 설치에서는 이 제한이 모든 프로젝트에 영향을 주는 기본 계획에 정의되어 있습니다. 기본값은 10개의 파이프라인 스케줄 제한이 있습니다.

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

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

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

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

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

  • 1분마다 실행되려면 제한값은 1440이어야 합니다.
  • 10분마다 실행되려면 제한값은 144이어야 합니다.
  • 60분마다 실행되려면 제한값은 24이어야 합니다.

최소값은 24이며, 60분당 한 번의 파이프라인입니다. 최대값은 존재하지 않습니다.

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

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

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

GitLab Pages 웹 사이트 당 파일 수

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

이는 GitLab Self-Managed 및 SaaS 요금제의 기본 제한입니다.

여러분은 GitLab 레일즈 콘솔을 사용하여 스스로 관리되는 인스턴스에서 이 제한을 업데이트할 수 있습니다. 예를 들어, 제한을 100으로 변경하려면: 

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

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

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

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

병렬 Pages 배포 수

병렬 Pages 배포를 사용하는 경우, 최상위 네임스페이스 당 허용되는 병렬 Pages 배포 수는 1000개입니다.

범위 당 등록된 러너 수

  • GitLab 17.1에서 러너 휴면 시간 제한이 3개월에서 7일로 변경되었습니다.

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

GitLab SaaS 가입자는 해당 요금제를 사용하는 모든 프로젝트에 영향을 미치는 다양한 제한을 갖습니다.

자체 관리 GitLab 프리미엄 및 얼티메이트의 제한은 모든 프로젝트에 영향을 미치는 기본 요금제로 정의됩니다:

러너 범위 기본 값
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를 업데이트하세요(megabytes 단위): 

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

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

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

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

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

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

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

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

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

ApplicationSetting.update(max_artifacts_content_include_size: 20.megabytes)

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

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

이러한 제한을 GitLab 레일즈 콘솔을 사용하여 변경할 수 있습니다:

  • 최대 YAML 크기를 업데이트하려면, max_yaml_size_bytes를 새 값으로 업데이트하세요(메가바이트 단위): 

    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/CD 구성에 할당할 수 있는 최대 메모리를 새 값으로 업데이트하세요. 예를 들어, 20MB로 설정하려면: 

ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)

dotenv 변수 제한

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

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

셀프 매니지드 인스턴스에서 이 제한을 100으로 설정하려면 GitLab 레일즈 콘솔에서 다음 명령을 실행하세요: 

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

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

dotenv 파일 크기 제한

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

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

셀프 매니지드 설치에서 이 제한을 5 KB로 설정하려면 GitLab 레일즈 콘솔에서 다음을 실행하세요: 

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

CI/CD 작업 주석 제한

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

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

셀프 매니지드 인스턴스에서 이 제한을 100으로 설정하려면 GitLab 레일즈 콘솔에서 다음 명령을 실행하세요: 

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

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

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

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

셀프 매니지드 설치에서 이 제한을 100 KB로 설정하려면 GitLab 레일즈 콘솔에서 다음을 실행하세요: 

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

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

인바운드 재해 관리 경보 제한

이 설정은 일정 기간 동안 수신된 경보 payloads의 수를 제한합니다.

재해 관리 속도 제한에 대해 자세히 알아보세요.

Prometheus 경보 JSON payloads

notify.json 엔드포인트로 전송된 Prometheus 경보 payloads는 크기가 1 MB로 제한됩니다.

일반 경보 JSON payloads

notify.json 엔드포인트로 전송된 경보 payloads는 크기가 1 MB로 제한됩니다.

메트릭 대시보드 YAML 파일

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

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

dashboard: 'Test dashboard'
links:
- title: Link 1
  url: https://gitlab.com
panel_groups:
- group: Group A
  priority: 1
  panels:
  - title: "Super Chart A1"
    type: "area-chart"
    y_label: "y_label"
    weight: 1
    max_value: 1
    metrics:
    - id: metric_a1
      query_range: 'query'
      unit: unit
      label: Legend Label

환경 대시보드 제한

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

최대 표시되는 프로젝트 수에 대한 환경 대시보드를 확인하세요.

배포 보드의 환경 데이터

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

병합 요청

차이 제한

GitLab은 다음과 관련된 제한이 있습니다:

각각의 최대 및 최소 제한이 적용됩니다:

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

최소 제한은 추가 diff를 축소시킵니다. 최대 제한은 더 이상의 변경을 렌더링하지 못하게 합니다. 이러한 제한에 대한 자세한 내용은 개발 문서를 참조하세요.

병합 요청 보고서 크기 제한

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

고급 검색 제한

색인화된 최대 파일 크기

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

제한을 설정하여 색인화 프로세스의 메모리 사용량과 전체 색인 크기를 줄일 수 있습니다. 이 값의 기본값은 1024 KiB (1 MiB)로 설정됩니다. 이 값을 설정해야 하며 무제한 파일 크기는 지원되지 않습니다. 이 값을 GitLab Sidekiq 노드 메모리 양보다 크게 설정하면 GitLab Sidekiq 노드가 색인화 중에 메모리를 소진하여 동작하지 않을 수 있습니다.

최대 필드 길이

고급 검색을 위해 색인화된 텍스트 필드의 내용에 한도를 설정할 수 있습니다. 최대값을 설정하면 색인화 프로세스의 부하를 줄일 수 있습니다. 텍스트 필드가이 한도를 초과하는 경우 해당 텍스트는 이 수의 문자로 줄여집니다. 나머지 텍스트는 색인화되지 않으며 검색할 수 없습니다. 이는 리포지토리 파일이 아닌 모든 색인화된 데이터에 적용됩니다. 더 많은 정보는 색인화된 최대 파일 크기를 읽어보세요.

  • GitLab.com에서 필드 길이 제한은 20,000자입니다.
  • Self-Managed 설치에서는 기본적으로 필드 길이에 제한이 없습니다.

Elasticsearch를 활성화하면 Self-Managed 설치의 경우 이 한도를 구성할 수 있습니다. 이 한도를 0으로 설정하여 비활성화할 수 있습니다.

수식 렌더링 한도

  • GitLab 16.5에서 도입.
  • Wiki 및 리포지토리 파일의 노드 제한 50개를 제거.
  • GitLab 16.9에서 위키 및 리포지토리 파일의 수식 한도를 비활성화할 수 있도록 하는 그룹 수준 설정을 추가.

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

이슈, 병합 요청, 에픽, 위키 및 리포지토리 파일의 제한사항:

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

이러한 제한을 Self-Managed 인스턴스에서 비활성화하고 사용자 입력을 신뢰할 경우 제한을 해제할 수 있습니다.

GitLab Rails 콘솔을 사용하여 이러한 제한도 그룹별로 비활성화할 수 있습니다.

제한이 비활성화된 경우 브라우저에서 볼 때 DoS를 유발할 수 있는 수식을 추가할 수도 있습니다. 이를 방지하려면 신뢰할 수 있는 사용자만이 콘텐츠를 추가할 수 있도록 해야 합니다.

위키 제한

스니펫 제한

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

디자인 관리 제한

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

푸시 이벤트 제한

최대 푸시 크기

허용되는 푸시 크기의 최대값.

Self-Managed 인스턴스의 기본값은 설정되어 있지 않습니다. GitLab.com의 경우 계정 및 제한 설정을 참조하세요.

웹훅 및 프로젝트 서비스

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

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

활동

단일 푸시에서 변경 사항 (브랜치 또는 태그)의 총 수를 통해 개별 푸시 이벤트 또는 대량 푸시 이벤트를 생성할지 여부를 결정합니다.

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

패키지 레지스트리 제한

파일 크기 제한

GitLab 패키지 레지스트리에 업로드되는 패키지의 기본 최대 파일 크기는 다음과 같습니다.

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

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

Self-Managed 설치를 위해 이러한 제한을 설정하려면 관리자 영역을 통해 또는 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개의 버전을 반환합니다.

종속성 프록시 제한

의존성 프록시에 캐시된 이미지의 최대 파일 크기는 파일 유형에 따라 다릅니다.

  • 이미지 blob: 5 GB
  • 이미지 매니페스트: 10 MB

최대 담당자 및 검토어 수

  • 최대 담당자를 도입한 GitLab 15.6.
  • 최대 검토어를 도입한 GitLab 15.9.

이슈 및 병합 요청에서 다음 최대 제한사항이 적용됩니다:

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

GitLab.com의 CDN 기반 제한

응용 프로그램 기반 제한 외에도 GitLab.com은 Cloudflare의 표준 DDoS(Distributed Denial of Service) 방어 및 Git over SSH 보호를 위해 Spectrum을 사용하도록 구성되어 있습니다. Cloudflare는 클라이언트 TLS 연결을 해제하지만 애플리케이션을 인식하지는 않으며 사용자 또는 그룹과 관련된 제한에 사용할 수 없습니다. Cloudflare 페이지 규칙 및 속도 제한은 Terraform을 사용하여 구성됩니다. 이러한 구성은 공개되어 있지 않습니다 (악용된 활동을 감지하고 이러한 작업을 악화시킨다면 위협하는 보안 및 악용 구현을 포함하기 때문입니다).

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

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

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

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

  • 파일 크기는 5MB보다 작아야 합니다.
  • 프로젝트당 100개를 넘는 보안 파일을 가질 수 없습니다.

변경 로그 API 제한

  • GitLab 15.1에서 도입, 기본적으로 사용되지는 않지만 changelog_commits_limitation이라는 플래그로 함께 제공됩니다 (기능 플래그 참조). 해제된 상태로 제공됩니다.
  • GitLab 15.3에서 GitLab.com에서 활성화되며 기본적으로 사용됩니다(자체 관리 참조).
  • GitLab 17.3에서 일반 사용 가능 합니다. 기능 플래그 changelog_commits_limitation이 삭제되었습니다.

변경 로그 API는 다음 제한을 적용합니다:

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

가치 스트림 분석 제한

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

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

사용자 정의 HTTP 엔드포인트

  • 각 최상위 그룹당 최대 5개의 사용자 정의 HTTP 스트리밍 대상을 가질 수 있습니다.

Google Cloud Logging

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

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,
...

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