GitLab 애플리케이션 제한 사항

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

대부분의 대형 애플리케이션과 마찬가지로 GitLab은 일부 기능에서 제한 사항을 집행하여 최소한의 성능을 유지합니다. 일부 기능을 무제한으로 허용하면 보안, 성능, 데이터에 영향을 미칠 수도 있으며, 애플리케이션에 할당된 리소스를 고갈시킬 수도 있습니다.

인스턴스 구성

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

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

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

이 페이지는 누구에게나 표시되므로, 인증되지 않은 사용자는 자신에게 관련된 정보만 볼 수 있습니다.

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

  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초를 기다려야 함.

패키지 레지스트리

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

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

Git LFS

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

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

파일 API

이 설정은 사용자별이나 IP 주소별 패키지 API의 요청 속도를 제한합니다. 자세한 정보는 파일 API 요금 제한을(를) 참조하세요.

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

폐기된 API 엔드포인트

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

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

가져오기/내보내기

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

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

가져오기/내보내기 요금 제한을(를) 참조하세요.

멤버 초대

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

  • GitLab.com: 무료 멤버는 하루에 20명의 멤버를 초대할 수 있으며, Premium 체험 및 Ultimate 체험 멤버는 하루에 50명의 멤버를 초대할 수 있습니다.
  • Self-Managed: 초대에는 제한이 없습니다.

Webhook 요금 제한

  • GitLab 15.1에서 훅당 제한이 톱레벨 네임스페이스당으로 변경됨 (변경됨).

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

요금 제한을 설정하려면, Self-Managed형 설치에서 다음을 실행하세요. GitLab Rails 콘솔에서 다음을 실행하세요. 

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

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

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

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

검색 요금 제한

  • GitLab 15.9에서 이슈, Merge Request, 에픽 검색을 요금 제한에 포함하도록 변경됨.
  • GitLab 16.0에서 인증된 요청에 대한 검색 범위에 요금 제한을 적용하도록 변경됨.

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

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

분당 검색 요청이 요금 제한을 초과하는 경우 다음과 같은 오류가 반환됩니다: 

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

파이프라인 생성 요금 제한

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

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

Gitaly 동시성 제한

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

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

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

이슈, Merge Request, 또는 커밋 당 댓글 수

커밋, 이슈, 또는 Merge Request에 제출할 수 있는 댓글 수에는 제한이 있습니다. 제한에 도달하면 시스템 노트는 추가할 수 있어도 사용자가 제출한 댓글이 실패합니다.

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

이슈, Merge Request 및 에픽의 설명 크기

이슈, Merge Request 및 에픽의 설명에는 크기 제한이 있습니다. 제한을 초과하려고 하면 오류가 발생하며 해당 항목은 생성되지 않습니다.

이 제한이 향후 더 낮은 수로 변경될 수 있습니다.

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

커밋 제목과 설명의 크기

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

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

커밋이 푸시되면 GitLab은 이슈(#123) 및 Merge Request(!123)에 대한 참조를 해당 이슈와 Merge Request에 대한 링크로 대체합니다.

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

마일스톤 개요의 이슈 수

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

  • 제한: 500개의 이슈.

Git 푸시 당 파이프라인 수

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

Merge Request 파이프라인에는 제한이 없습니다. Git 푸시가 여러 Merge Request을 동시에 업데이트하는 경우 각 업데이트된 Merge Request마다 Merge Request 파이프라인이 트리거될 수 있습니다.

단일 Git 푸시 이벤트에 대해 파이프라인을 원하는 만큼 트리거할 수 있도록 제한을 제거하려면, 관리자는 git_push_create_all_pipelines 피처 플래그를 활성화할 수 있습니다. 이 피처 플래그를 활성화하는 것은 권장되지 않으며, 한 번에 너무 많은 변경 사항이 푸시되고 실수로 파이프라인이 대량으로 생성되는 문제를 발생시킬 수 있습니다.

활동 기록 보관

프로젝트 및 개인 프로필의 활동 기록은 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에 기록됩니다.

Pull 미러링 간격

pull 갱신 간의 최소 대기 시간은 기본적으로 300초(5분)입니다. 예를 들어, 트리거하는 횟수와 관계없이 주어진 300초 기간 동안 pull 갱신이 한 번만 실행됩니다.

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

Self-Managed형 설치에서 이 제한을 변경하려면, GitLab Rails 콘솔에서 다음을 실행하세요: 

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

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

자동 응답기로부터 수신되는 이메일 양

GitLab은 X-Autoreply 헤더를 찾아 자동 응답기로부터 수신된 모든 이메일을 무시합니다. 이러한 이메일은 이슈나 Merge Request에 댓글을 생성하지 않습니다.

Sentry를 통한 에러 추적으로부터 전송되는 데이터 양

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

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

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

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 SaaS 구독자는 해당 플랜에 따라 정의된 다른 제한을 갖으며, 해당 플랜에 속한 모든 프로젝트에 영향을 줍니다.
  • GitLab Premium Self-Managed형 또는 그 이상의 설치에서는 모든 프로젝트에 영향을 주는 default 플랜에 정의된 이 제한이 적용됩니다. 기본적으로 이 제한은 (0)으로 비활성화됩니다.

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분 이상이어야 합니다.

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

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

기본 제한은 GitLab Self-Managed 및 SaaS 계획에 대해 500입니다.

Self-Managed형 설치의 경우 기본 계획의 제한을 다음 GitLab Rails 콘솔 명령을 사용하여 변경할 수 있습니다: 

# 기본 계획에 대한 제한이 없는 경우 다음과 같이 만들 수 있습니다:
# Plan.default.create_limits!

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

이 제한을 해제하려면 제한을 0으로 설정합니다.

프로젝트의 CI/CD 구독 수

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

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

  • GitLab SaaS의 경우: 제한은 계획별로 정의되며 해당 계획 하의 모든 프로젝트에 영향을 미칩니다.
  • Self-Managed형의 경우: GitLab Premium 또는 Ultimate에서, 이 제한은 모든 프로젝트에 영향을 미치는 기본 계획에 정의됩니다. 기본적으로 2개의 구독에 대한 제한이 있습니다.

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

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

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

파이프라인 트리거 수 제한

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

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

제한을 해제하려면 해당 제한을 0으로 설정하세요. Self-Managed형 인스턴스의 경우 기본 값은 25000입니다.

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

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

이 제한은 GitLab.com에 적용됩니다.

파이프라인 스케줄링 수

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

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

GitLab Premium 이상의 Self-Managed형 인스턴스의 경우, 이 제한은 모든 프로젝트에 영향을 미치는 기본 계획에 정의됩니다. 기본적으로 10개의 파이프라인 스케줄에 대한 제한이 있습니다.

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

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

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

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

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

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

최소값은 24입니다. 제한값당 파이프라인 하나 당 60분입니다. 최대값은 없습니다.

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

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

이 제한은 GitLab.com에 적용됩니다.

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

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

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

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

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

이 제한은 GitLab.com에 적용됩니다.

CI/CD 변수 제한

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

Self-Managed형 설치의 경우 이러한 제한 중 하나의 default 계획을 업데이트하려면 GitLab Rails 콘솔에서 다음 명령을 실행하세요:

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

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

  • 그룹 수준 CI/CD 변수](../ci/variables/index.md#for-a-group) 제한(그룹당 기본값: 30000): 

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

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

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

다양한 유형의 artifact당 최대 파일 크기

artifacts:reports로 정의된 작업 artifact는 러너에 의해 업로드되며, 파일 크기가 최대 파일 크기 제한을 초과하는 경우 거부됩니다. 제한은 프로젝트의 최대 artifact 크기 설정과 주어진 artifact 유형에 대한 인스턴스 제한을 비교하여 더 작은 값이 선택됨으로써 결정됩니다.

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

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

Artifact 제한 이름 기본값
ci_max_artifact_size_accessibility 0
ci_max_artifact_size_annotations 0
ci_max_artifact_size_api_fuzzing 0
ci_max_artifact_size_archive 0
ci_max_artifact_size_browser_performance 0
ci_max_artifact_size_cluster_applications 0
ci_max_artifact_size_cobertura 0
ci_max_artifact_size_codequality 0
ci_max_artifact_size_container_scanning 0
ci_max_artifact_size_coverage_fuzzing 0
ci_max_artifact_size_dast 0
ci_max_artifact_size_dependency_scanning 0
ci_max_artifact_size_dotenv 0
ci_max_artifact_size_junit 0
ci_max_artifact_size_license_management 0
ci_max_artifact_size_license_scanning 0
ci_max_artifact_size_load_performance 0
ci_max_artifact_size_lsif 100 MB
ci_max_artifact_size_metadata 0
ci_max_artifact_size_metrics_referee 0
ci_max_artifact_size_metrics 0
ci_max_artifact_size_network_referee 0
ci_max_artifact_size_performance 0
ci_max_artifact_size_requirements 0
ci_max_artifact_size_requirements_v2 0
ci_max_artifact_size_sast 0
ci_max_artifact_size_secret_detection 0
ci_max_artifact_size_terraform 5 MB
ci_max_artifact_size_trace 0
ci_max_artifact_size_cyclonedx 5 MB

예를 들어, ci_max_artifact_size_junit 제한을 Self-Managed형 설치에서 10 MB로 설정하려면 GitLab Rails console에서 다음을 실행하세요: 

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

GitLab 페이지 웹사이트 당 파일 수

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

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

Self-Managed형 인스턴스에서 제한을 업데이트하려면 GitLab Rails console에서 제한을 변경하세요. 예를 들어, 제한을 100으로 변경하려면: 

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

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

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

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

복수 배포 사용 시 추가 페이지 배포 수

다중 Pages 배포를 사용할 때, 최상위 네임스페이스의 추가 페이지 배포 허용량은 1000입니다.

범위별 등록 러너 수의 최대치

등록된 러너의 총 수는 그룹 및 프로젝트 수준에서 제한됩니다. 새 러너가 등록될 때마다 GitLab은 지난 3개월간 활동한 러너를 기준으로 이러한 제한을 확인합니다. 제한 값이 0으로 설정된 경우 러너가 참여한 범위에 대한 제한이 비활성화됩니다.

GitLab SaaS 구독자는 해당 요금제를 사용하는 모든 프로젝트에 영향을 미치는 각각의 요금제에 따라 다른 제한이 정의되어 있습니다.

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

러너 범위 기본값
ci_registered_group_runners 1000
ci_registered_project_runners 1000

이러한 제한을 업데이트하려면 GitLab Rails console에서 다음을 실행하세요: 

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

작업 로그의 최대 파일 크기

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

기존 값을 메가바이트 단위로 변경하여 GitLab Rails console에서 제한을 변경할 수 있습니다: 

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

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

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

프로젝트 당 활성 DAST 프로필 일정의 수를 제한합니다. DAST 프로필 일정은 활성이거나 비활성일 수 있습니다.

이러한 제한을 GitLab Rails console에서 변경하려면 dast_profile_schedules를 새 값으로 업데이트하세요: 

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

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

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

이러한 제한은 GitLab Rails console에서 다음과 같이 업데이트할 수 있습니다:

  • 최대 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 구성 파일로 완전한 파이프라인 구성에 할당할 수 있는 최대 메모리 양(바이트 단위).

새로운 Self-Managed형 인스턴스의 경우, 기본값은 157286400 바이트(150MB)입니다.

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

이 제한은 GitLab Rails console을 통해 변경할 수 있습니다. CI/CD 구성에 할당할 수 있는 최대 메모리를 업데이트하려면 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 console에서 다음 명령을 실행하세요: 

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

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

dotenv 파일 크기 제한

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

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

Self-Managed형 설치에서 이 제한을 5KB로 설정하려면 GitLab Rails console에서 다음을 실행하세요: 

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

CI/CD 작업 주석 제한

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

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

Self-Managed형 인스턴스에서 이 제한을 100으로 설정하려면 GitLab Rails console에서 다음 명령을 실행하세요: 

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

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

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

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

Self-Managed형 설치에서 이 제한을 100KB로 설정하려면 GitLab Rails console에서 다음을 실행하세요: 

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

인스턴스 모니터링 및 지표

입받는 장애 관리 경보 제한

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

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

Prometheus 경보 JSON 페이로드

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

일반 경보 JSON 페이로드

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

메트릭 대시보드 YAML 파일

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

각 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: Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated

표시될 수 있는 프로젝트의 최대 수에 대한 세부 정보는 환경 대시보드를 참조하세요.

배포 보드의 환경 데이터

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

Merge Request

Diff 제한

GitLab은 다음과 같은 제한이 있습니다.

각각에 대해 상하한선이 적용됩니다.

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

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

Merge Request 보고서 크기 제한

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

고급 검색 제한

색인화된 최대 파일 크기

Elasticsearch에서 색인화된 리포지터리 파일의 내용에 대한 제한을 설정할 수 있습니다. 이 제한을 초과하는 파일은 파일 이름만 색인화되고 검색이 불가능합니다.

제한을 설정하여 색인화 프로세스의 메모리 사용량과 전체 색인 크기를 줄일 수 있습니다. 이 값의 기본값은 1024 KiB (1 MiB)이며, 이 값보다 큰 어떤 텍스트 파일도 인간이 읽기 위해 작성된 것이 아니기 때문에 이 값 이상의 파일 크기는 지원되지 않습니다.

무제한 파일 크기는 지원되지 않기 때문에 설정해주어야 합니다. 이 값은 GitLab Sidekiq 노드의 메모리 양보다 크게 설정하면 GitLab Sidekiq 노드가 메모리를 모두 사용하고 말겠습니다.

최대 필드 길이

고급 검색을 위해 색인화된 텍스트 필드의 내용에 대한 제한을 설정할 수 있습니다. 최대값 설정은 색인화 프로세스의 부담을 줄이는 데 도움이 됩니다. 텍스트 필드가 이 제한을 초과하는 경우 텍스트가 이 글자수로 줄어듭니다. 나머지 텍스트는 색인화되지 않으며 검색되지 않습니다. 이는 리포지터리 파일에 적용되는 별도의 제한과는 다릅니다. 더 많은 정보를 보려면 색인화된 최대 파일 크기를 확인하세요.

  • GitLab.com의 필드 길이 제한: 20,000 글자.
  • Self-Managed형 설치의 기본값은 무제한입니다.

Self-Managed형 설치에서는 Elasticsearch를 활성화시킬 때 이 제한을 설정할 수 있습니다. 이 제한을 비활성화하려면 0으로 설정하세요.

수학 렌더링 제한

- GitLab 16.5에 도입. - 위키 및 리포지터리 파일에서의 50 노드 제한이 제거되었습니다. - GitLab 16.9에서 위키 및 리포지터리 파일에 대한 수학 렌더링 제한을 비활성화하는 그룹 수준 설정이 추가되었으며, 기본적으로 수학 렌더링 제한이 다시 활성화되었습니다.

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

이슈, Merge Request, 에픽, 위키, 리포지터리 파일에 대한 제한은 다음과 같습니다:

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

이러한 제한은 Self-Managed형 인스턴스에서 실행 중이고 사용자 입력을 신뢰할 수 있는 경우에만 해제할 수 있습니다.

GitLab Rails 콘솔을 사용하여 이러한 제한을 해제할 수도 있습니다. 

ApplicationSetting.update(math_rendering_limits_enabled: false)

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

제한이 해제된 경우, 이슈, Merge Request, 에픽, 위키 및 리포지터리 파일에 대해서는 대부분 제한 없이 수학이 렌더링됩니다. 따라서 악의적인 사용자는 브라우저에서 보는 동안 DoS를 유발할 수 있는 수학을 추가할 수 있습니다. 따라서 신뢰할 수 있는 사람만 콘텐츠를 추가할 수 있도록 보장해야 합니다.

위키 제한

코드 스니펫 제한

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

디자인 관리 제한

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

푸시 이벤트 제한

최대 푸시 크기

허용되는 최대 푸시 크기입니다.

Self-Managed형 인스턴스의 경우 기본적으로 설정되지 않습니다. 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의 최대 파일 크기는 다를 수 있습니다.

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)

# 제네릭 패키지에 대해
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에서 최대 리뷰어가 도입되었습니다.

이슈 및 Merge Request에서는 다음의 최대 값이 적용됩니다:

  • 최대 담당자: 200
  • 최대 리뷰어: 200

GitLab.com의 CDN 기반 제한

애플리케이션 기반 제한에 추가하여, GitLab.com은 Cloudflare의 표준 DDoS 보호 및 Git over SSH 보호를 위해 Spectrum을 구성하고 있습니다. Cloudflare는 클라이언트 TLS 연결을 종료하지만 응용프로그램 인식이 불가능하며 사용자나 그룹에 연결된 제한에 사용할 수 없습니다. Cloudflare 페이지 규칙과 속도 제한은 Terraform으로 구성됩니다. 이러한 구성은 보안 및 악용을 탐지하는 구현을 포함하여 비공개로 유지되어야 합니다.

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

컨테이너 레지스트리에는 컨테이너 리포지터리의 태그 삭제가 네트워크 요청을 트리거합니다. 따라서 단일 API 호출에서 삭제할 수 있는 태그 수에 제한을 두고 있습니다.

프로젝트-레벨 보안 파일 API 제한

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

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

변경 로그 API 제한

- GitLab 15.1에서 changelog_commits_limitation이라는 플래그와 함께 도입되었습니다. 기본값은 비활성화되어 있습니다. - GitLab 15.3에서 GitLab.com에서 활성화되었으며, Self-Managed형에서 기본적으로 활성화되었습니다.

변경 로그 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,
ci_instance_level_variables: "[FILTERED]",
storage_size_limit: 0,
ci_max_artifact_size_lsif: 100,
ci_max_artifact_size_archive: 0,
...
...

limits_history: {},
audit_events_amazon_s3_configurations: 5

디렉터리의 일부 한도 값은 Rails 콘솔에서의 필터링으로 인해 [FILTERED]로 표시됩니다.