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 요청 제한에 대해 자세히 알아보세요.

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

raw 엔드포인트 별

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

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

  • 기본 요청 제한: 프로젝트, 커밋 및 파일 경로별로 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명의 멤버를 초대할 수 있으며, Premium 평가 및 Ultimate 평가 멤버는 하루에 50명을 초대할 수 있습니다.
  • Self-managed: 초대에 제한이 없습니다.

웹훅 요청 제한

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

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

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

# 기본 플랜에 대해 제한이 없는 경우 다음으로 제한을 만들 수 있습니다:
# Plan.default.create_limits!

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

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

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

검색 속도 제한

  • GitLab 14.9에서 소개됨.
  • GitLab 15.9에서 이슈, Merge Request 및 epic 검색을 속도 제한에 포함하도록 변경됨.
  • GitLab 16.0에서 인증된 요청의 전체 검색 범위에 대해 속도 제한을 적용하는 것으로 변경됨. 검색 범위에 대한 설정입니다.

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

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

분당 검색 요청이 검색 속도 제한을 초과하면 다음과 같은 오류가 반환됩니다: 

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

파이프라인 생성 속도 제한

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

자세한 내용은 파이프라인 생성 속도 제한을 확인하세요.

Gitaly 동시성 제한

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

자세한 내용은 Gitaly 동시성 제한을 확인하세요.

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

이슈, Merge Request 또는 커밋당 코멘트 수

이슈, Merge Request 또는 커밋에 제출할 수 있는 코멘트 수에는 한도가 있습니다. 한도에 도달하면 시스템 노트를 추가하여 이벤트의 이력이 손실되지 않도록 할 수는 있지만, 사용자가 제출한 코멘트는 실패합니다.

  • 최대 제한: 5,000 개의 코멘트.

이슈, Merge Request 및 epic의 코멘트 및 설명 크기

이슈, Merge Request 및 epic의 코멘트 및 설명 크기에는 제한이 있습니다. 제한을 초과하는 텍스트 본문을 추가하려고 하면 오류가 발생하고 항목이 생성되지 않습니다.

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

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

커밋 제목 및 설명 크기

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

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

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

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

마일스톤 개요 페이지의 이슈 수

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

  • 제한: 500 개의 이슈.

Git 푸시 당 파이프라인 수

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

Merge Request 파이프라인에는 제한이 없습니다. 단일 Git 푸시 이벤트로 여러 Merge Request을 업데이트하는 경우 각 업데이트된 Merge Request에 대해 Merge Request 파이프라인이 트리거될 수 있습니다.

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

활동 이력의 유지 기간

프로젝트 및 개인 프로필에 대한 활동 이력은 세 해로 제한됩니다.

임베드된 메트릭 수

성능상의 이유로 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의 웹훅 제한을 참고하세요.

웹훅 페이로드 크기

웹훅 페이로드의 최대 크기는 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은 해당 시리즈에서 트리거될 수 있는 추가 웹훅을 차단합니다.

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

Pull Mirroring Interval

풀 갱신 간의 최소 대기 시간은 기본적으로 300초(5분)로 설정됩니다. 예를 들어, 주어진 300초 동안 풀 갱신은 한 번만 실행되며 몇 번 트리거하든 상관없습니다.

이 설정은 프로젝트 API를 통해 호출된 풀 갱신 또는 설정 > 리포지터리 > 미러링 리포지터리에서 지금 업데이트()를 선택하여 강제로 업데이트할 때 적용됩니다. 이 설정은 풀 미러링에 대해 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 설치 이상에서는 이 한도가 모든 프로젝트에 영향을 미치는 기본 계획에 정의되어 있습니다. 이 한도는 기본적으로 비활성화(0)되어 있습니다.

Self-managed 설치의 경우 이 한도를 설정하려면 다음을 GitLab Rails 콘솔에서 실행하세요: 

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

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

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

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

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

작업의 최대 시간 초과를 방지하려면 다음 위치에서 가능합니다:

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

파이프라인에서 실행될 수 있는 배포 작업의 최대 수를 제한할 수 있습니다. 배포는 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 구독 수

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

새 구독이 전체 구독 수를 초과하면 해당 구독은 유효하지 않은 것으로 간주됩니다.

Self-managed 설치의 경우 이 한도를 설정하려면 다음을 GitLab Rails 콘솔에서 실행하세요: 

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

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

파이프라인 트리거 수 제한

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

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

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

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

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

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

파이프라인 스케줄 수

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

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

GitLab Premium Self-managed 또는 그 이상의 설치에서, 기본으로 모든 프로젝트에 영향을 주는 default 계획 하에 이 제한이 정의됩니다. 기본적으로 파이프라인 스케줄 수는 10으로 제한됩니다.

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

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

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

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

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

  • 분당 한 번이면, 제한은 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 변수의 총 수는 인스턴스 수준에서 제한됩니다. 이 제한은 새로운 인스턴스 수준 변수가 생성될 때마다 확인됩니다. 새 변수가 총 변수 수를 제한을 초과하게 되면 해당 새 변수는 생성되지 않습니다.

Self-managed 인스턴스에서, 이 제한은 default 계획을 위해 정의됩니다. 기본적으로, 이 제한은 25로 설정됩니다.

Self-managed 설치에서 이 제한을 새 값으로 업데이트하려면 다음을 GitLab Rails 콘솔에서 실행하십시오: 

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

그룹 수준 변수 수

그룹 수준 CI/CD 변수의 총 수는 인스턴스 수준에서 제한됩니다. 이 제한은 새로운 그룹 수준 변수가 생성될 때마다 확인됩니다. 새 변수가 총 변수 수를 제한을 초과하게 되면 해당 새 변수는 생성되지 않습니다.

Self-managed 인스턴스에서, 이 제한은 default 계획을 위해 정의됩니다. 기본적으로, 이 제한은 30000으로 설정됩니다.

Self-managed 설치에서 이 제한을 새 값으로 업데이트하려면 다음을 GitLab Rails 콘솔에서 실행하십시오: 

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

프로젝트 수준 변수 수

프로젝트 수준 CI/CD 변수의 총 수는 인스턴스 수준에서 제한됩니다. 이 제한은 새로운 프로젝트 수준 변수가 생성될 때마다 확인됩니다. 새 변수가 총 변수 수를 제한을 초과하게 되면 해당 새 변수는 생성되지 않습니다.

Self-managed 인스턴스에서, 이 제한은 default 계획을 위해 정의됩니다. 기본적으로, 이 제한은 8000으로 설정됩니다.

Self-managed 설치에서 이 제한을 새 값으로 업데이트하려면 다음을 GitLab Rails 콘솔에서 실행하십시오: 

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

각 유형의 artifact당 최대 파일 크기

  • ci_max_artifact_size_annotations는 GitLab 16.3에서 도입되었습니다.

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

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

각 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 1 MB

예를 들어, Self-managed 설치에서 ci_max_artifact_size_junit 제한을 10MB로 설정하려면 다음을 GitLab Rails 콘솔에서 실행하십시오: 

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

GitLab Pages 웹사이트 당 파일 수

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

이는 모든 GitLab Self-managed 및 SaaS 요금제에 대한 기본 제한입니다.

Self-managed 인스턴스에서 이 제한을 업데이트하려면 GitLab Rails 콘솔에서 다음과 같이 limit를 변경하십시오: 

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

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

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

GitLab Self-managed의 기본 제한은 0 (무제한)입니다. Self-managed 인스턴스에 제한을 설정하려면 관리 영역을 사용하십시오.

범위별 등록 러너 수

  • 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 가입자는 계획별로 정의된 다른 제한이 적용되며, 해당 계획을 사용하는 모든 프로젝트에 영향을 미칩니다.

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

러너 범위 기본값
ci_registered_group_runners 1000
ci_registered_project_runners 1000

이러한 제한을 업데이트하려면 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 러너에도 output_limit 설정이 있어 러너에서의 로그 크기 최댓값을 구성합니다. 러너 제한을 초과하는 작업은 계속 실행되지만, 제한에 도달하면 로그가 잘립니다.

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

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

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

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

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

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

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

  • 최대 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 콘솔을 통해 이 제한을 변경할 수 있습니다. 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 콘솔에서 다음 명령을 실행하세요: 

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

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

dotenv 파일 크기 제한

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

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

Self-managed 설치에서 이 제한을 5KB로 설정하려면 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으로 설정하세요. 기본값은 80KB입니다.

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

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

인스턴스 모니터링 및 지표

인바운드 장애 관리 경보 제한

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

자세한 내용은 장애 관리 속도 제한을 참조하세요.

프로메테우스 경보 JSON 페이로드

notify.json 엔드포인트로 전송된 프로메테우스 경보 페이로드의 크기는 1MB로 제한됩니다.

일반 경보 JSON 페이로드

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

지표 대시보드 YAML 파일

구문 분석된 지표 대시보드 YAML 파일이 1MB를 초과할 수 없습니다.

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

대시보드: '테스트 대시보드'
링크:
- 제목: 링크 1
  url: https://gitlab.com
패널 그룹:

- 그룹: 그룹 A
  우선 순위: 1
  패널:
  - 제목: "슈퍼 차트 A1"
    유형: "면적 차트"
    y_label: "y_label"
    가중치: 1
    최대 값: 1
    지표:
    - id: 지표_a1
      query_range: '쿼리'
      unit: 단위
      레이블: 레전드 레이블

환경 대시보드 제한

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

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

배포 보드의 환경 데이터

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

Merge Request

차이 제한

GitLab은 다음 사항에 대해 제한을 둡니다:

각각에 대한 상한선과 하한선이 적용됩니다:

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

하한선은 추가 차이가 축소되도록 하고, 상한선은 더 이상 변경이 렌더링되지 않도록 합니다. 이러한 제한에 대한 자세한 내용은 개발 문서를 참조하세요.

Merge Request 보고서 크기 제한

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

고급 검색 제한

색인화된 최대 파일 크기

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

이러한 제한을 설정하면 색인 프로세스의 메모리 사용량과 전체 색인 크기를 줄일 수 있습니다. 이 값은 기본적으로 1024 KiB (1 MiB)이며 이보다 큰 텍스트 파일은 일반적으로 사람이 읽으려고 하는 것이 아니기 때문에 이 값으로 설정됩니다.

무제한 파일 크기는 지원되지 않으므로 제한을 설정해야 합니다. 이 값이 GitLab Sidekiq 노드의 메모리 양보다 크게 설정되면 색인하는 동안 GitLab Sidekiq 노드가 메모리 부족 상태가 됩니다.

최대 필드 길이

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

  • GitLab.com의 필드 길이 제한: 20,000 문자
  • Self-managed 설치의 필드 길이: 기본적으로 무제한

Self-managed 설치의 경우 고급 검색을 활성화할 때 이 제한을 구성할 수 있습니다. 이 제한을 비활성화하려면 0으로 설정하세요.

수학 렌더링 제한

마크다운 필드에서 수학을 렌더링할 때 GitLab은 기본 제한을 가합니다. 이러한 제한은 더 나은 보안 및 성능을 제공합니다.

이슈, Merge Request, 에픽, 위키 및 리포지터리 파일에 대한 제한:

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

이러한 제한은 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
  • 일반: 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개 버전을 반환합니다.

의존성 프록시 제한

  • GitLab 14.5에 도입되었습니다.

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

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

최대 담당자 및 리뷰어 수

  • 최대 담당자는 GitLab 15.6에 도입되었습니다.
  • 최대 리뷰어는 GitLab 15.9에 도입되었습니다.

이슈 및 Merge Request에서 다음과 같은 최대 값이 적용됩니다:

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

GitLab.com의 CDN 기반 제한

애플리케이션 기반 제한 외에도, GitLab.com은 클라우드플레어의 표준 DDoS(분산 서비스 거부) 방어 및 Git over SSH를 보호하기 위해 Spectrum을 구성하고 있습니다. 클라우드플레어는 클라이언트 TLS 연결을 종료하지만 응용 프로그램을 인식하거나 사용자 또는 그룹과 관련된 제한에 사용할 수는 없습니다. 클라우드플레어 페이지 규칙 및 속도 제한은 테라폼으로 구성되어 있습니다. 이러한 구성은 보안 및 악용 검출을 포함하기 때문에 공개되어서는 안 되며, 악의적인 활동을 감지할 수 있는 구현을 노출하면 해당 작업이 저해될 수 있습니다.

컨테이너 리포지터리 태그 삭제 제한

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

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

  • GitLab 14.8에 도입되었습니다.

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

  • 파일 크기는 5 MB보다 작아야 합니다.
  • 프로젝트당 안전 파일이 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,
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]로 표시됩니다.