GitLab 애플리케이션 제한
GitLab v19.5Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
요약
GitLab은 대부분의 대규모 애플리케이션과 마찬가지로 최소한의 성능 품질을 유지하기 위해 특정 기능에 제한을 적용합니다. 인스턴스 구성 페이지에서는 현재 GitLab 인스턴스에 사용 중인 일부 설정 정보를 확인할 수 있습니다.
GitLab은 대부분의 대규모 애플리케이션과 마찬가지로 최소한의 성능 품질을 유지하기 위해 특정 기능에 제한을 적용합니다. 일부 기능을 무제한으로 허용하면 보안, 성능, 데이터에 영향을 주거나 애플리케이션에 할당된 리소스를 소진시킬 수 있습니다.
인스턴스 구성#
인스턴스 구성 페이지에서는 현재 GitLab 인스턴스에 사용 중인 일부 설정 정보를 확인할 수 있습니다.
구성한 제한에 따라 다음 항목을 확인할 수 있습니다.
- SSH 호스트 키 정보
- CI/CD 제한
- GitLab Pages 제한
- 패키지 레지스트리 제한
- 속도 제한
- 크기 제한
이 페이지는 모든 사용자에게 공개되므로, 인증되지 않은 사용자는 자신과 관련된 정보만 확인할 수 있습니다.
인스턴스 구성 페이지로 이동하려면 다음 단계를 따릅니다.
- 왼쪽 사이드바에서 Help ([question-o]) > Help를 선택합니다.
- Help 페이지에서 Check the current instance configuration을 선택합니다.
직접 접근하는 URL은 <gitlab_url>/help/instance_configuration 입니다. GitLab.com에서는
https://gitlab.com/help/instance_configuration을 방문할 수 있습니다.
속도 제한#
속도 제한을 사용하면 GitLab의 보안과 내구성을 높일 수 있습니다.
전체 속도 제한 목록과 각 제한을 변경하는 방법은 속도 제한을 참고합니다.
보호된 경로별 제한#
이 설정은 특정 경로의 요청 속도를 제한합니다.
GitLab은 기본적으로 POST 요청에 대해 다음 경로의 속도를 제한합니다.
'/users/password',
'/users/sign_in',
'/api/#{API::API.version}/session.json',
'/api/#{API::API.version}/session',
'/users',
'/users/confirmation',
'/unsubscribes/',
'/import/github/personal_access_token',
'/admin/session'
GitLab은 기본적으로 GET 요청에 대해 다음 경로의 속도를 제한합니다.
'/users/sign_in_path'
보호된 경로 속도 제한에 대한 자세한 내용을 참고합니다.
- 기본 속도 제한: 요청 10회 이후 클라이언트는 60초를 기다린 뒤 다시 시도해야 합니다.
가져오기 및 내보내기#
이 설정은 그룹과 프로젝트의 파일 가져오기 및 내보내기를 제한합니다.
| 제한 | 기본값(사용자당 분당) |
|---|---|
| 프로젝트 가져오기 | 가져오기 요청 6회 |
| 프로젝트 내보내기 | 내보내기 요청 6회 |
| 프로젝트 내보내기 다운로드 | 다운로드 요청 1회 |
| 그룹 가져오기 | 가져오기 요청 6회 |
| 그룹 내보내기 | 내보내기 요청 6회 |
| 그룹 내보내기 다운로드 | 다운로드 요청 1회 |
이 설정은 구성할 수 있습니다.
직접 전송 마이그레이션#
직접 전송 방식으로 마이그레이션할 때 다음 제한이 적용됩니다.
| 제한 | 기본값 | 구성 가능 |
|---|---|---|
| 사용자당 분당 대상 GitLab 인스턴스별 마이그레이션 수. | 6 | ❌ |
| 아카이브 파일 압축 해제 대기 시간. | 210초 | ❌ |
| NDJSON 행 길이. | 50 MB | ❌ |
| 소스 인스턴스에서 빈 내보내기 상태가 발생할 때까지의 시간. | 5분 | ❌ |
| 소스 인스턴스에서 다운로드할 수 있는 관계 크기. | 5 GiB | ✅ |
| 압축 해제된 아카이브 크기. | 10 GiB | ✅ |
구성 가능한 제한을 변경하는 방법에 대한 자세한 내용은 가져오기 및 내보내기 설정을 참고합니다.
멤버 초대#
그룹 계층별로 허용되는 일일 최대 멤버 초대 수를 제한합니다.
- GitLab.com: Free 멤버는 하루에 20명, Premium 트라이얼 및 Ultimate 트라이얼 멤버는 하루에 50명을 초대할 수 있습니다.
- GitLab Self-Managed: 초대 수에 제한이 없습니다.
웹훅 속도 제한#
최상위 네임스페이스의 웹훅이 분당 호출될 수 있는 횟수를 제한합니다. 네임스페이스의 모든 프로젝트 웹훅과 그룹 웹훅이 이 제한을 공유합니다.
속도 제한을 초과한 호출은 auth.log에 기록됩니다.
GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 Plan Limits API를 사용하거나 GitLab Rails 콘솔에서 다음을 실행합니다.
Plan.default.actual_limits.update!(web_hook_calls: 10)
제한을 0으로 설정하면 비활성화됩니다.
- 기본 속도 제한: 비활성화됨(무제한).
Service Desk 이메일 속도 제한#
히스토리
service_desk_email_rate_limit이라는 기능 플래그와 함께 GitLab 19.4에서 도입되었습니다. 기본적으로 비활성화되어 있습니다.
이 기능의 가용성은 기능 플래그로 제어됩니다. 자세한 내용은 히스토리를 참고합니다.
최상위 네임스페이스가 시간당 그리고 하루당 보낼 수 있는 Service Desk 아웃바운드 알림 이메일 수를 제한합니다. 여기에는 티켓 생성 확인 이메일, 새 댓글 알림 이메일, 새 참여자 알림 이메일이 포함됩니다. 네임스페이스의 모든 프로젝트와 하위 그룹이 이 제한을 공유합니다. 발송된 이메일 한 통이 1 증가로 계산되므로, 참여자 10명에게 알림을 보내는 댓글은 이메일 10통으로 계산됩니다.
네임스페이스가 두 제한 중 하나에 도달하면 GitLab은 아웃바운드 이메일을 억제하지만, 티켓 생성, 댓글 처리, 참여자 추가는 그대로 수행합니다. GitLab은 이메일 발송이 억제되었음을 기록하기 위해 해당 티켓에 내부 노트를 추가하며, 이 노트는 티켓당 시간당 최대 한 번만 추가됩니다.
GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 Plan Limits API를 사용하거나 GitLab Rails 콘솔에서 다음을 실행합니다.
Plan.default.actual_limits.update!(
service_desk_outbound_emails_per_hour: 100,
service_desk_outbound_emails_per_day: 1000
)
제한을 0으로 설정하면 비활성화됩니다.
- 기본 속도 제한: GitLab Self-Managed에서는 비활성화됨(무제한). GitLab.com의 플랜별 제한은 GitLab.com의 속도 제한을 참고합니다.
검색 속도 제한#
이 설정은 검색 요청을 다음과 같이 제한합니다.
| 제한 | 기본값(분당 요청 수) |
|---|---|
| 인증된 사용자 | 30 |
| 인증되지 않은 사용자 | 10 |
분당 검색 속도 제한을 초과한 검색 요청은 다음 오류를 반환합니다.
This endpoint has been requested too many times. Try again later.
자동 완성 사용자 속도 제한#
히스토리
이 설정은 자동 완성 사용자 요청을 다음과 같이 제한합니다.
| 제한 | 기본값(분당 요청 수) |
|---|---|
| 인증된 사용자 | 300 |
| 인증되지 않은 사용자 | 100 |
분당 자동 완성 속도 제한을 초과한 자동 완성 요청은 다음 오류를 반환합니다.
This endpoint has been requested too many times. Try again later.
Dependency Proxy 속도 제한#
컨테이너 이미지용 Dependency Proxy에 대한 인증된 요청은 인증된 웹 요청 속도 제한 대신 전용 속도 제한을 사용할 수 있습니다.
- 기본 속도 제한: 비활성화됨. 활성화하면 사용자당 15초당 1,000회 요청이 기본값입니다.
MCP 서버 속도 제한#
GitLab MCP 서버(POST /api/v4/mcp)에 대한 인증된 요청은
인증된 API 요청 속도 제한에 더해
전용 속도 제한을
사용할 수 있습니다.
- 기본 속도 제한: 비활성화됨. 활성화하면 사용자당 60초당 600회 요청이 기본값입니다.
Gitaly 동시성 제한#
클론 트래픽은 Gitaly 서비스에 큰 부하를 줄 수 있습니다. 이러한 워크로드가 Gitaly 서버를 압도하지 않도록 Gitaly 구성 파일에서 동시성 제한을 설정할 수 있습니다.
Gitaly 동시성 제한에 대한 자세한 내용을 참고합니다.
- 기본 속도 제한: 비활성화됨.
이슈, 머지 리퀘스트, 커밋당 댓글 수#
이슈, 머지 리퀘스트, 커밋에 제출할 수 있는 댓글 수에는 제한이 있습니다. 제한에 도달하면 이벤트 기록이 손실되지 않도록 시스템 노트는 계속 추가되지만, 사용자가 제출한 댓글은 실패합니다.
- 최대 제한: 댓글 5,000개.
이슈, 머지 리퀘스트, 에픽의 댓글 및 설명 크기#
이슈, 머지 리퀘스트, 에픽의 댓글 및 설명 크기에는 제한이 있습니다. 제한보다 큰 본문 텍스트를 추가하려고 하면 오류가 발생하며, 해당 항목도 생성되지 않습니다.
이 제한은 향후 더 낮은 값으로 변경될 수 있습니다.
- 최대 크기: 약 100만 자 / 약 1 MB.
커밋 제목 및 설명 크기#
임의로 큰 메시지를 가진 커밋도 GitLab에 푸시할 수 있지만, 다음 표시 제한이 적용됩니다.
- 제목 - 커밋 메시지의 첫 번째 줄입니다. 1 KiB로 제한됩니다.
- 설명 - 커밋 메시지의 나머지 부분입니다. 1 MiB로 제한됩니다.
커밋을 푸시하면 GitLab은 제목과 설명을 처리하여 이슈(#123)와
머지 리퀘스트(!123) 참조를 해당 이슈와 머지 리퀘스트 링크로
대체합니다.
커밋 수가 많은 브랜치를 푸시하면 마지막 100개 커밋만 처리됩니다.
리베이스 작업 중 크기#
커밋을 리베이스하면 크기 제한을 초과하는 커밋 메시지는 잘립니다. 이 제한은 커밋 제목 및 설명의 크기 제한과는 별개입니다.
- 제한: 10,240바이트(10 KB).
마일스톤 개요의 이슈 수#
마일스톤 개요 페이지에 로드되는 최대 이슈 수는 500개입니다. 이 수를 초과하면 페이지에 알림이 표시되고, 마일스톤에 포함된 모든 이슈의 페이지네이션된 이슈 목록으로 연결되는 링크가 제공됩니다.
- 제한: 이슈 500개.
활동 기록 보존#
프로젝트와 개인 프로필의 활동 기록은 3년으로 제한됩니다.
임베드된 메트릭 수#
성능상의 이유로 GitLab Flavored Markdown(GLFM)에 메트릭을 임베드할 때 제한이 있습니다.
- 최대 제한: 임베드 100개.
HTTP 응답 제한#
최대 Gzip 압축 크기#
히스토리
- GitLab 17.10에서 도입되었습니다.
이 설정은 Gzip으로 압축된 HTTP 응답을 압축 해제한 후 허용되는 최대 크기를 MiB 단위로 제한합니다.
기본 최대 크기는 100 MiB 입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.
이 제한은 GitLab Rails 콘솔이나 애플리케이션 설정 API로 변경할 수 있습니다.
ApplicationSetting.update(max_http_decompressed_size: 50)
아웃바운드 요청에서 최대 HTTP 응답 크기#
히스토리
- GitLab 17.10에서 도입되었습니다.
이 설정은 압축 해제된 HTTP 응답에 허용되는 최대 크기를 MiB 단위로 제한합니다. 이 제한은 통합, 가져오기 도구, 웹훅에 적용됩니다.
기본 최대 크기는 100 MiB 입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.
이 제한은 GitLab Rails 콘솔이나 애플리케이션 설정 API로 변경할 수 있습니다.
ApplicationSetting.update(max_http_response_size_limit: 60)
아웃바운드 요청에서 JSON HTTP 응답의 최대 허용 오브젝트 수#
히스토리
- GitLab 18.4에서 도입되었습니다.
이 설정은 아웃바운드 요청에서 반환되는 JSON HTTP 응답의 최대 허용
오브젝트 수를 제한합니다. 오브젝트 수는 응답에 나타나는
:, ,, {, [의 출현 횟수를 기준으로 추정됩니다.
기본 최대 개수는 오브젝트 1,000,000개입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.
이 제한은 GitLab Rails 콘솔이나 애플리케이션 설정 API로 변경할 수 있습니다.
ApplicationSetting.update(max_http_response_json_structural_chars: 500000)
아웃바운드 요청에서 JSON HTTP 응답의 최대 허용 중첩 깊이#
히스토리
- GitLab 18.4에서 도입되었습니다.
이 설정은 아웃바운드 요청에서 반환되는 JSON HTTP 응답의 최대 허용 중첩 깊이를 제한합니다.
기본 최대 중첩 깊이는 32 입니다.
이 제한은 GitLab Rails 콘솔이나 애플리케이션 설정 API로 변경할 수 있습니다.
ApplicationSetting.update(max_http_response_json_depth: 100)
아웃바운드 요청에서 XML HTTP 응답의 최대 허용 오브젝트 수#
히스토리
- GitLab 18.4에서 도입되었습니다.
이 설정은 아웃바운드 요청에서 반환되는 XML HTTP 응답의 최대 허용
오브젝트 수를 제한합니다. 오브젝트 수는 응답에 나타나는
<, =의 출현 횟수를 기준으로 추정됩니다.
기본 최대 개수는 오브젝트 250,000개입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.
이 제한은 GitLab Rails 콘솔이나 애플리케이션 설정 API로 변경할 수 있습니다.
ApplicationSetting.update(max_http_response_xml_structural_chars: 500000)
아웃바운드 요청에서 CSV HTTP 응답의 최대 허용 오브젝트 수#
히스토리
- GitLab 18.4에서 도입되었습니다.
이 설정은 아웃바운드 요청에서 반환되는 CSV HTTP 응답의 최대 허용
오브젝트 수를 제한합니다. 오브젝트 수는 응답에 나타나는
,, ;, \t, \r, \n의 출현 횟수를 기준으로 추정됩니다.
기본 최대 개수는 오브젝트 250,000개입니다. 이 제한을 비활성화하려면 값을 0으로 설정합니다.
이 제한은 GitLab Rails 콘솔이나 애플리케이션 설정 API로 변경할 수 있습니다.
ApplicationSetting.update(max_http_response_csv_structural_chars: 500000)
HTTP 요청 제한#
기본적으로 요청의 JSON 파라미터는 제한됩니다. 자세한 내용은 엔드포인트별 JSON 유효성 검사 제한을 참고합니다.
이 검사를 비활성화하려면 다음 단계를 따릅니다.
-
Puma를 실행하는 모든 노드에서
GITLAB_JSON_GLOBAL_VALIDATION_MODE환경 변수를 설정합니다.sudo -e /etc/gitlab/gitlab.rbgitlab_rails['env'] = { 'GITLAB_JSON_GLOBAL_VALIDATION_MODE' => 'disabled' } -
변경 사항이 적용되도록 업데이트된 노드를 재구성합니다.
sudo gitlab-ctl reconfigure
이 검사를 비활성화하려면 --set gitlab.webservice.extraEnv.GITLAB_JSON_GLOBAL_VALIDATION_MODE="disabled"를 사용하거나,
values 파일에 다음을 지정합니다.
gitlab:
webservice:
extraEnv:
GITLAB_JSON_GLOBAL_VALIDATION_MODE: "disabled"
엔드포인트별 JSON 유효성 검사 제한#
일부 API 엔드포인트에는 특정 JSON 유효성 검사 제한이 적용됩니다.
| 엔드포인트 | 설명 | 메서드 | 최대 깊이 | 최대 배열 크기 | 최대 해시 크기 | 최대 전체 요소 | 최대 JSON 크기 | 모드 |
|---|---|---|---|---|---|---|---|---|
| 기타 모든 경로 | 기본 | 전체 | 32 | 50,000 | 50,000 | 100,000 | 0 (비활성화) | enforced |
/api/v4/projects/{id}/terraform/state/ |
Terraform 상태 | POST | 64 | 50,000 | 50,000 | 250,000 | 50 MB | logging1 |
/api/v4/packages/npm/-/npm/v1/security/{advisories/bulk|audits/quick} |
NPM 인스턴스 패키지 | POST | 32 | 50,000 | 50,000 | 250,000 | 50 MB | enforced |
/api/v4/groups/{id}/-/packages/npm/-/npm/v1/security/{advisories/bulk|audits/quick} |
NPM 그룹 패키지 | POST | 32 | 50,000 | 50,000 | 250,000 | 50 MB | enforced |
/api/v4/projects/{id}/packages/npm/-/npm/v1/security/{advisories/bulk|audits/quick} |
NPM 프로젝트 패키지 | POST | 32 | 50,000 | 50,000 | 250,000 | 50 MB | enforced |
/api/v4/internal/* |
내부 API | POST | 32 | 50,000 | 50,000 | 0 (비활성화) | 10 MB | enforced |
/api/v4/ai/duo_workflows/workflows/* |
GitLab Duo Workflow API | POST | 32 | 5,000 | 5,000 | 0 (비활성화) | 25 MB | enforced |
환경 변수 구성#
다음 환경 변수는 기본 제한과 유효성 검사 모드를 변경합니다.
| 환경 변수 | 목적 | 기본값 | 범위 |
|---|---|---|---|
GITLAB_JSON_MAX_DEPTH |
기본 최대 중첩 깊이 | 32 | 기본 제한만 |
GITLAB_JSON_MAX_ARRAY_SIZE |
기본 최대 배열 요소 | 50,000 | 기본 제한만 |
GITLAB_JSON_MAX_HASH_SIZE |
기본 최대 해시 키 | 50,000 | 기본 제한만 |
GITLAB_JSON_MAX_TOTAL_ELEMENTS |
기본 최대 전체 요소 | 100,000 | 기본 제한만 |
GITLAB_JSON_MAX_JSON_SIZE_BYTES |
기본 최대 본문 크기 | 0 (비활성화) | 기본 제한만 |
GITLAB_JSON_VALIDATION_MODE |
기본 유효성 검사 모드 | enforced |
기본 제한만 |
GITLAB_JSON_GLOBAL_VALIDATION_MODE |
모든 엔드포인트 모드 재정의 | 설정 안 됨 | 모든 엔드포인트(전역 재정의) |
GITLAB_JSON_GLOBAL_VALIDATION_MODE 환경 변수는 다음 모드 중 하나로 설정할 수 있습니다.
| 모드 | 설명 |
|---|---|
enforced |
제한을 초과하는 요청을 검증하고 차단합니다(HTTP 400 반환). 프로덕션 환경 보호에 사용합니다. |
logging |
위반을 검증하고 기록하지만 요청은 통과시킵니다. 모니터링과 디버깅에 사용합니다. 모든 엔드포인트가 로그만 기록하며, 이는 enforced를 재정의합니다. |
| disabled | 유효성 검사를 완전히 건너뜁니다. 비상 우회 수단으로 사용합니다. |
GITLAB_JSON_GLOBAL_VALIDATION_MODE를 사용할 때 적용되는 사항은 다음과 같습니다.
- 경로별 구성은 기본 제한을 재정의하지만 전역 유효성 검사 모드는 재정의하지 않습니다.
- enforced 모드에서 제한을 초과하면 JSON 오류 메시지와 함께 HTTP 400 이 응답됩니다.
- 전체 요소 수에는 전체 JSON 구조에 있는 배열과 해시의 모든 요소가 포함됩니다.
웹훅 제한#
웹훅 속도 제한도 함께 참고합니다.
웹훅 수#
GitLab Self-Managed 인스턴스에서 그룹 웹훅 또는 프로젝트 웹훅의 최대 개수를 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다.
# For project webhooks
Plan.default.actual_limits.update!(project_hooks: 200)
# For group webhooks
Plan.default.actual_limits.update!(group_hooks: 100)
제한을 0으로 설정하면 비활성화됩니다.
웹훅의 기본 최대 개수는 프로젝트당 100 개, 그룹당 50 개입니다. 하위 그룹의 웹훅은 상위 그룹의 웹훅 제한에 포함되지 않습니다.
GitLab.com의 경우 GitLab.com의 웹훅 제한을 참고합니다.
웹훅 페이로드 크기#
웹훅 페이로드의 최대 크기는 25 MB 입니다.
웹훅 타임아웃#
GitLab 이 웹훅을 전송한 후 HTTP 응답을 기다리는 시간(초)입니다.
웹훅 타임아웃 값을 변경하려면 다음 단계를 따릅니다.
-
Sidekiq을 실행 중인 모든 GitLab 노드에서
/etc/gitlab/gitlab.rb를 편집합니다.gitlab_rails['webhook_timeout'] = 60 -
파일을 저장합니다.
-
변경 사항이 적용되도록 GitLab을 재구성하고 재시작합니다.
gitlab-ctl reconfigure gitlab-ctl restart
GitLab.com의 웹훅 제한도 함께 참고합니다.
재귀 웹훅#
GitLab은 재귀적으로 동작하거나 다른 웹훅에서 트리거될 수 있는 웹훅 수의 제한을 초과하는 웹훅을 탐지하고 차단합니다. 이를 통해 GitLab은 웹훅으로 API를 비재귀적으로 호출하는 워크플로나, 다른 웹훅을 지나치게 많이 트리거하지 않는 워크플로를 계속 지원할 수 있습니다.
재귀는 웹훅이 자신의 GitLab 인스턴스(예: API)를 호출하도록 구성된 경우에 발생할 수 있습니다. 이 호출이 동일한 웹훅을 다시 트리거하여 무한 루프를 만듭니다.
다른 웹훅을 트리거하는 일련의 웹훅이 인스턴스에 보낼 수 있는 최대 요청 수는 100 회입니다. 제한에 도달하면 GitLab은 해당 연쇄에서 트리거될 이후의 웹훅을 모두 차단합니다.
차단된 재귀 웹훅 호출은 "Recursive webhook blocked from executing" 메시지와 함께 auth.log에 기록됩니다.
가져오기 플레이스홀더 사용자 제한#
히스토리
- GitLab 17.4에서 도입되었습니다.
가져오기 중에 생성되는 플레이스홀더 사용자 수는 최상위 네임스페이스별로 제한할 수 있습니다.
GitLab Self-Managed의 기본 제한은 0(무제한)입니다.
GitLab Self-Managed 인스턴스에서 이 제한을 변경하려면 GitLab Rails 콘솔에서 다음을 실행합니다.
Plan.default.actual_limits.update!(import_placeholder_user_limit_tier_1: 200)
제한을 0으로 설정하면 비활성화됩니다.
풀 미러링 간격#
풀 새로 고침 사이의 최소 대기 시간의 기본값은 300초(5분)입니다. 예를 들어 풀 새로 고침은 트리거한 횟수와 관계없이 지정된 300초 동안 한 번만 실행됩니다.
이 설정은 프로젝트 API로 호출한 풀 새로 고침이나, Settings > Repository > Mirroring repositories에서 Update now ([retry])를 선택해 업데이트를 강제하는 경우에 적용됩니다. 이 설정은 Sidekiq 이 풀 미러링에 사용하는 30분 간격의 자동 스케줄에는 영향을 주지 않습니다.
GitLab Self-Managed 인스턴스에서 이 제한을 변경하려면 GitLab Rails 콘솔에서 다음을 실행합니다.
Plan.default.actual_limits.update!(pull_mirror_interval_seconds: 200)
자동 응답에서 수신되는 이메일#
GitLab은 X-Autoreply 헤더를 확인하여 자동 응답기가 보낸 수신 이메일을 모두
무시합니다. 이러한 이메일은 이슈나 머지 리퀘스트에 댓글을 생성하지 않습니다.
오류 추적을 통해 Sentry에서 전송되는 데이터 양#
GitLab으로 전송되는 Sentry 페이로드에는 보안상의 이유와 메모리 사용량 제한을 위해 최대 1 MB 제한이 적용됩니다.
REST API의 오프셋 기반 페이지네이션에서 허용되는 최대 오프셋#
REST API에서 오프셋 기반 페이지네이션을 사용할 때 결과 집합에 요청할 수 있는 최대 오프셋에는 제한이 있습니다. 이 제한은 키셋 기반 페이지네이션도 지원하는 엔드포인트에만 적용됩니다. 페이지네이션 옵션에 대한 자세한 내용은 페이지네이션에 관한 API 문서에서 확인할 수 있습니다.
GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다.
Plan.default.actual_limits.update!(offset_pagination_limit: 10000)
- 기본 오프셋 페이지네이션 제한:
50000.
제한을 0으로 설정하면 비활성화됩니다.
GitLab Pages 제한#
GitLab Pages 웹사이트당 파일 수#
파일 항목의 총 개수(디렉터리와 심볼릭 링크 포함)는 GitLab Pages 웹사이트당
200,000 개로 제한됩니다.
이는 GitLab Self-Managed와 GitLab.com의 기본 제한입니다.
GitLab Self-Managed 인스턴스에서 이 제한을 업데이트하려면
GitLab Rails 콘솔을 사용합니다.
예를 들어 제한을 100으로 변경하려면 다음을 실행합니다.
Plan.default.actual_limits.update!(pages_file_entries: 100)
GitLab Pages 웹사이트당 커스텀 도메인 수#
GitLab Pages 웹사이트당 커스텀 도메인의 총 개수는 GitLab.com에서 150 개로 제한됩니다.
GitLab Self-Managed의 기본 제한은 0(무제한)입니다.
인스턴스에 제한을 설정하려면
Admin area를 사용합니다.
병렬 Pages 배포 수#
병렬 Pages 배포를 사용할 때 최상위 네임스페이스에 허용되는 병렬 Pages 배포의 총 개수는 1000개입니다.
프로젝트에 고유 도메인이 활성화되어 있으면, 해당 프로젝트의 고유 도메인은 자체 최상위 네임스페이스로 간주되어 배포 1000개의 별도 제한이 적용됩니다.
인스턴스 모니터링 및 메트릭#
인바운드 인시던트 관리 알림 제한#
이 설정은 일정 기간 동안 수신되는 알림 페이로드 수를 제한합니다.
인시던트 관리 속도 제한에 대한 자세한 내용을 참고합니다.
Prometheus Alert JSON 페이로드#
notify.json 엔드포인트로 전송되는 Prometheus 알림 페이로드의 크기는 1 MB로 제한됩니다.
일반 Alert JSON 페이로드#
notify.json 엔드포인트로 전송되는 알림 페이로드의 크기는 1 MB로 제한됩니다.
환경 대시보드 제한#
표시되는 프로젝트의 최대 개수는 환경 대시보드를 참고합니다.
배포 보드의 환경 데이터#
배포 보드는 Kubernetes에서 Pod와 Deployment에 대한 정보를 로드합니다. 다만 Kubernetes에서 읽어 온 특정 환경의 데이터가 10 MB를 초과하면 표시되지 않습니다.
머지 리퀘스트#
Diff 제한#
GitLab에는 다음 항목에 대한 제한이 있습니다.
- 단일 파일의 패치 크기. GitLab Self-Managed에서 구성할 수 있습니다.
- 머지 리퀘스트의 모든 diff 총 크기.
각 항목에는 상한과 하한이 적용됩니다.
- 변경된 파일 수.
- 변경된 줄 수.
- 표시되는 변경 사항의 누적 크기.
하한에 도달하면 추가 diff가 접힙니다. 상한에 도달하면 더 이상 변경 사항이 렌더링되지 않습니다. 이러한 제한에 대한 자세한 내용은 diff 작업에 관한 GitLab 개발 문서를 참고합니다.
Diff 버전 제한#
히스토리
- GitLab 17.10에서
merge_requests_diffs_limit이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다. - GitLab 17.10에서 GitLab.com에 활성화되었습니다.
- GitLab 19.0에서 일반 가용 상태가 되었습니다. 기능 플래그
merge_requests_diffs_limit가 제거되었습니다.
GitLab은 머지 리퀘스트마다 diff 버전을 1000개로 제한합니다. 이 제한에 도달한 머지 리퀘스트는 더 이상 업데이트할 수 없습니다. 이 경우 해당 머지 리퀘스트를 닫고 새 머지 리퀘스트를 생성합니다.
이 제한을 구성하는 방법은 diff 제한 관리를 참고합니다.
머지 리퀘스트 리포트 크기 제한#
20 MB 제한을 초과하는 리포트는 로드되지 않습니다. 영향을 받는 리포트는 다음과 같습니다.
고급 검색 제한#
인덱싱된 최대 파일 크기#
Elasticsearch에 인덱싱되는 리포지터리 파일의 콘텐츠에 제한을 설정할 수 있습니다. 이 제한보다 큰 파일은 파일 이름만 인덱싱됩니다. 파일 콘텐츠는 인덱싱되지 않으며 검색할 수도 없습니다.
제한을 설정하면 인덱싱 프로세스의 메모리 사용량과 전체 인덱스 크기를
줄이는 데 도움이 됩니다. 이 값의 기본값은 1024 KiB(1 MiB)이며, 이보다 큰
텍스트 파일은 사람이 읽기 위한 것이 아닐 가능성이 높기 때문입니다.
무제한 파일 크기는 지원되지 않으므로 반드시 제한을 설정해야 합니다. 이 값을 GitLab Sidekiq 노드의 메모리 용량보다 크게 설정하면 인덱싱 중에 해당 크기만큼 메모리가 미리 할당되므로 GitLab Sidekiq 노드의 메모리가 부족해집니다.
최대 필드 길이#
고급 검색을 위해 인덱싱되는 텍스트 필드의 콘텐츠에 제한을 설정할 수 있습니다. 최대값을 설정하면 인덱싱 프로세스의 부하를 줄이는 데 도움이 됩니다. 텍스트 필드가 이 제한을 초과하면 해당 글자 수까지 텍스트가 잘립니다. 나머지 텍스트는 인덱싱되지 않으며 검색할 수도 없습니다. 이 제한은 별도의 제한이 적용되는 리포지터리 파일을 제외한 모든 인덱싱 데이터에 적용됩니다. 자세한 내용은 인덱싱된 최대 파일 크기를 참고합니다.
- GitLab.com에서 필드 길이 제한은 20,000자입니다.
- GitLab Self-Managed 인스턴스에서 필드 길이는 기본적으로 무제한입니다.
GitLab Self-Managed 인스턴스에서는 Elasticsearch를 활성화할 때
이 제한을 구성할 수 있습니다.
제한을 0으로 설정하면 비활성화됩니다.
수학 렌더링 제한#
히스토리
- GitLab 19.2에서 렌더링되는 최대 노드 수가 50 개에서 1000 개로 증가했습니다.
GitLab은 Markdown 필드에서 수식을 렌더링할 때 기본 제한을 적용합니다. 이 제한은 보안과 성능을 개선합니다.
이슈, 머지 리퀘스트, 에픽, 위키, 리포지터리 파일에 적용되는 제한은 다음과 같습니다.
- 최대 매크로 확장 수:
1000. - 사용자가 지정할 수 있는 최대 크기(em 단위):
20. - 렌더링되는 최대 노드 수:
1000. - 수식 블록의 최대 글자 수:
1000. - 최대 렌더링 시간:
2000 ms.
GitLab Self-Managed를 운영하면서 사용자 입력을 신뢰할 수 있는 경우 이 제한을 비활성화할 수 있습니다.
GitLab Rails 콘솔을 사용합니다.
ApplicationSetting.update(math_rendering_limits_enabled: false)
이 제한은 GraphQL 또는 REST API를 사용하여 그룹별로 비활성화할 수도 있습니다.
제한을 비활성화하면 이슈, 머지 리퀘스트, 에픽, 위키, 리포지터리 파일에서 수식이 사실상 제한 없이 렌더링됩니다. 이 경우 악의적인 사용자가 브라우저에서 볼 때 서비스 거부를 유발하는 수식을 추가할 수 있습니다. 신뢰할 수 있는 사용자만 콘텐츠를 추가할 수 있도록 해야 합니다.
Wiki 제한#
스니펫 제한#
스니펫 설정 문서를 참고합니다.
Design Management 제한#
제한은 이슈에 디자인 추가 섹션을 참고합니다.
Push 이벤트 제한#
최대 push 크기#
허용되는 최대 push 크기입니다.
GitLab Self-Managed에서는 기본적으로 설정되어 있지 않습니다. GitLab.com의 경우 계정 및 제한 설정을 참고합니다.
웹훅 및 프로젝트 서비스#
단일 push의 총 변경 수(브랜치 또는 태그)입니다. 변경 수가 지정된 제한을 초과하면 훅이 실행되지 않습니다.
자세한 내용은 다음을 참고합니다.
활동#
개별 push 이벤트를 생성할지 대량 push 이벤트를 생성할지 결정하는 데 사용하는 단일 push의 총 변경 수(브랜치 또는 태그)입니다.
자세한 내용은 push 이벤트 활동 제한 및 대량 push 이벤트 문서에서 확인할 수 있습니다.
패키지 레지스트리 제한#
파일 크기 제한#
히스토리
- GitLab 19.3에서 Cargo 패키지의 파일 크기 제한이 도입되었습니다.
GitLab 패키지 레지스트리에 업로드되는 패키지의 기본 최대 파일 크기는 형식에 따라 다릅니다.
- Cargo: 5 GB
- Conan: 3 GB
- Generic: 5 GB
- Helm: 5 MB
- Maven: 3 GB
- npm: 500 MB
- NuGet: 500 MB
- PyPI: 3 GB
- Terraform: 1 GB
GitLab.com의 최대 파일 크기는 다를 수 있습니다.
GitLab Self-Managed 인스턴스에 이 제한을 설정하려면 Admin area 에서 설정하거나 GitLab Rails 콘솔에서 다음을 실행합니다.
# File size limit is stored in bytes
# For Cargo Packages
Plan.default.actual_limits.update!(cargo_max_file_size: 100.megabytes)
# For Conan Packages
Plan.default.actual_limits.update!(conan_max_file_size: 100.megabytes)
# For npm Packages
Plan.default.actual_limits.update!(npm_max_file_size: 100.megabytes)
# For NuGet Packages
Plan.default.actual_limits.update!(nuget_max_file_size: 100.megabytes)
# For Maven Packages
Plan.default.actual_limits.update!(maven_max_file_size: 100.megabytes)
# For PyPI Packages
Plan.default.actual_limits.update!(pypi_max_file_size: 100.megabytes)
# For Debian Packages
Plan.default.actual_limits.update!(debian_max_file_size: 100.megabytes)
# For Helm Charts
Plan.default.actual_limits.update!(helm_max_file_size: 100.megabytes)
# For Generic Packages
Plan.default.actual_limits.update!(generic_packages_max_file_size: 100.megabytes)
제한을 0으로 설정하면 모든 파일 크기를 허용합니다.
반환되는 패키지 버전#
특정 NuGet 패키지 이름의 버전을 요청하면 GitLab 패키지 레지스트리는 최대 300개의 버전을 반환합니다.
Dependency Proxy 제한#
Dependency Proxy에 캐시된 이미지의 최대 파일 크기는 파일 유형에 따라 다릅니다.
- 이미지 blob: 5 GB
- 이미지 매니페스트: 10 MB
최대 담당자 및 검토자 수#
이슈와 머지 리퀘스트에는 다음 최대값이 적용됩니다.
- 최대 담당자: 200
- 최대 검토자: 200
작업 항목의 최대 레이블 수#
작업 항목(이슈, 에픽, 작업)은 레이블을 최대 100개까지 가질 수 있습니다. 이미 레이블이 100개를 넘는 작업 항목은 영향을 받지 않습니다. 해당 작업 항목에서 레이블은 계속 제거할 수 있지만 더 추가할 수는 없습니다.
머지 리퀘스트는 이 제한의 영향을 받지 않습니다.
최대 프로젝트 push 미러 수#
히스토리
- GitLab 18.9에서 도입되었습니다.
각 프로젝트에는 활성화된 push 미러를 최대 10개까지 둘 수 있습니다. 이 제한은 동시 동기화 job 이 과도하게 실행되어 발생하는 성능 문제를 방지합니다.
미러가 더 필요하면 다음 방법을 사용할 수 있습니다.
- 사용하지 않는 미러를 비활성화합니다.
- 여러 대상을 하나의 미러로 묶어 미러를 통합합니다.
GitLab.com의 CDN 기반 제한#
GitLab.com은 애플리케이션 기반 제한 외에도 Cloudflare의 표준 DDoS 보호와 Spectrum을 사용하여 SSH 기반 Git 트래픽을 보호하도록 구성되어 있습니다. Cloudflare는 클라이언트 TLS 연결을 종료하지만 애플리케이션을 인식하지는 못하므로 사용자나 그룹에 연동된 제한에는 사용할 수 없습니다. Cloudflare 페이지 규칙과 속도 제한은 Terraform으로 구성합니다. 이 구성은 악의적인 활동을 탐지하는 보안 및 악용 대응 구현을 포함하고 있어 공개할 경우 해당 대응이 무력화되므로 공개하지 않습니다.
컨테이너 리포지터리 태그 삭제 제한#
컨테이너 리포지터리 태그는 컨테이너 레지스트리에 있으므로 태그를 삭제할 때마다 컨테이너 레지스트리로 네트워크 요청이 발생합니다. 이 때문에 단일 API 호출로 삭제할 수 있는 태그 수를 20개로 제한합니다.
프로젝트 수준 Secure Files API 제한#
secure files API에는 다음 제한이 적용됩니다.
- 파일은 5 MB 미만이어야 합니다.
- 프로젝트는 secure file을 100개를 초과해 보유할 수 없습니다.
Changelog API 제한#
히스토리
- GitLab 15.1에서
changelog_commits_limitation이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다. - GitLab 15.3에서 GitLab.com 및 GitLab Self-Managed에서 기본적으로 활성화되었습니다.
- GitLab 17.3에서 일반 가용 상태가 되었습니다. 기능 플래그
changelog_commits_limitation가 제거되었습니다.
changelog API에는 다음 제한이 적용됩니다.
from과to사이의 커밋 범위는 15000개 커밋을 초과할 수 없습니다.
Value Stream Analytics 제한#
- 각 네임스페이스(그룹 또는 프로젝트 등)는 최대 50개의 value stream을 가질 수 있습니다.
- 각 value stream은 최대 15개의 Stage를 가질 수 있습니다.
감사 이벤트 스트리밍 대상 제한#
커스텀 HTTP 엔드포인트#
- 각 최상위 그룹은 최대 5개의 커스텀 HTTP 스트리밍 대상을 가질 수 있습니다.
Google Cloud Logging#
- 각 최상위 그룹은 최대 5개의 Google Cloud Logging 스트리밍 대상을 가질 수 있습니다.
Amazon S3#
- 각 최상위 그룹은 최대 5개의 Amazon S3 스트리밍 대상을 가질 수 있습니다.
SBOM을 사용한 의존성 스캐닝 제한#
SBOM을 사용한 의존성 스캐닝 기능은 다음 제한이 적용되는 내부 API를 사용합니다.
- 프로젝트당 시간당 최대 업로드 요청 수: 400
- 프로젝트당 시간당 최대 다운로드 요청 수: 6000
의존성 스캐닝 설정을 사용하여 GitLab Self-Managed 인스턴스에서 이러한 업로드 및 다운로드 제한을 구성할 수 있습니다.
API는 프로젝트의 모든 파이프라인을 합쳐 프로젝트당 시간당 SBOM 스캔 50건의 소프트 스로틀도 적용합니다. 이 임계값을 넘는 스캔도 실행되지만 우선순위가 낮아 완료까지 더 오래 걸릴 수 있습니다. 이 스로틀은 업로드 및 다운로드 제한과 별개이며 구성할 수 없습니다.
커밋 및 Files API 제한#
히스토리
- GitLab 18.7에서 도입되었습니다.
Commits API와 Files API는 다음 엔드포인트에 최대 크기 제한과 속도 제한을 적용합니다.
POST /projects/:id/repository/commits- 커밋 생성POST /projects/:id/repository/files/:file_path- 리포지터리에 파일 생성PUT /projects/:id/repository/files/:file_path- 리포지터리의 파일 업데이트- 최대 요청 크기: 이 제한을 초과하는 요청은 다음 메시지와 함께
413 Request Entity Too Large오류를 받습니다:RequestBody: upload failed: the upload size <size> is over maximum of 314572800 bytes: entity is too large. 기본값은 300 MB(314,572,800바이트)입니다. - 속도 제한: 20 MB를 초과하는 요청에 대해 30초당 3회 요청.
최대 요청 크기는 GITLAB_COMMITS_MAX_REQUEST_SIZE_BYTES 환경 변수를 설정하여 GitLab Self-Managed에서 구성할 수 있습니다. 이 변수는 최대 요청 크기를 바이트 단위로 설정합니다. 환경 변수를 설정하는 방법에 대한 지침은 HTTP 요청 제한에서 확인할 수 있습니다.
Secrets Manager 제한#
히스토리
- GitLab 18.9에서 도입되었습니다.
GitLab Secrets Manager에는 다음 제한이 적용됩니다.
| 제한 | 기본값 | 구성 가능 |
|---|---|---|
| 프로젝트당 시크릿 수 | 100 | ✅ |
| 그룹당 시크릿 수 | 500 | ✅ |
| 시크릿 값 크기 | 10 KB (10,000 bytes) | ❌ |
시크릿 개수 제한을 변경하려면 애플리케이션 설정 API의
project_secrets_limit 및 group_secrets_limit 설정을 사용합니다. 이 설정은 인스턴스의
모든 프로젝트와 그룹에 적용됩니다.
project_secrets_limit 또는 group_secrets_limit를 0으로 설정하면 제한이 완전히 사라집니다. 제한이 없으면 사용자가 시크릿을 무제한으로 생성할 수 있어 인스턴스 리소스가 소진될 수 있습니다.
모든 인스턴스 제한 나열#
모든 인스턴스 제한값을 나열하려면 GitLab Rails 콘솔에서 다음을 실행합니다.
Plan.default.actual_limits
샘플 출력은 다음과 같습니다.
id: 1,
plan_id: 1,
ci_pipeline_size: 0,
ci_active_jobs: 0,
project_hooks: 100,
group_hooks: 50,
ci_project_subscriptions: 3,
ci_pipeline_schedules: 10,
offset_pagination_limit: 50000,
ci_instance_level_variables: "[FILTERED]",
storage_size_limit: 0,
ci_max_artifact_size_lsif: 200,
ci_max_artifact_size_archive: 0,
ci_max_artifact_size_metadata: 0,
ci_max_artifact_size_trace: "[FILTERED]",
ci_max_artifact_size_junit: 0,
ci_max_artifact_size_sast: 0,
ci_max_artifact_size_dependency_scanning: 350,
ci_max_artifact_size_container_scanning: 150,
ci_max_artifact_size_dast: 0,
ci_max_artifact_size_codequality: 0,
ci_max_artifact_size_license_management: 0,
ci_max_artifact_size_license_scanning: 100,
ci_max_artifact_size_performance: 0,
ci_max_artifact_size_metrics: 0,
ci_max_artifact_size_metrics_referee: 0,
ci_max_artifact_size_network_referee: 0,
ci_max_artifact_size_dotenv: 0,
ci_max_artifact_size_cobertura: 0,
ci_max_artifact_size_terraform: 5,
ci_max_artifact_size_accessibility: 0,
ci_max_artifact_size_cluster_applications: 0,
ci_max_artifact_size_secret_detection: "[FILTERED]",
ci_max_artifact_size_requirements: 0,
ci_max_artifact_size_coverage_fuzzing: 0,
ci_max_artifact_size_browser_performance: 0,
ci_max_artifact_size_load_performance: 0,
ci_needs_size_limit: 2,
cargo_max_file_size: 5368709120,
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]로 표시됩니다.
Footnotes
-
Terraform 상태의 최대 크기 제한은 애플리케이션 설정 API로
max_terraform_state_size_bytes를 설정하여 지정할 수 있습니다. ↩