GitLabアプリケーションの制限

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は、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秒間待機してから再試行する必要があります。

パッケージレジストリ

この設定は、ユーザーまたはIPアドレスごとのパッケージAPIに対するリクエストレートを制限します。詳細については、パッケージレジストリレート制限を参照してください。

• デフォルトのレート制限: デフォルトでは無効になっています。

Git LFS

この設定は、ユーザーごとのGit LFSリクエストに対してリクエストレートを制限します。詳細については、GitLab Git Large File Storage（LFS）の管理を参照してください。

• デフォルトのレート制限: デフォルトでは無効になっています。

ファイルAPI

この設定は、ユーザーまたはIPアドレスごとのファイルAPIに対するリクエストレートを制限します。詳細については、ファイルAPIのレート制限を参照してください。

• デフォルトのレート制限: デフォルトでは無効になっています。

非推奨のAPIエンドポイント

この設定は、ユーザーまたはIPアドレスごとの非推奨のAPIエンドポイントに対するリクエストレートを制限します。詳細については、非推奨のAPIのレート制限を参照してください。

• デフォルトのレート制限: デフォルトでは無効になっています。

インポートとエクスポート

これらの設定は、グループとプロジェクトのファイルのインポートとエクスポートを制限します。

これらの設定は構成できます。

直接転送の移行

直接転送による移行には、次の制限が適用されます。

設定可能な制限を変更する方法の詳細については、インポートとエクスポートの設定を参照してください。

メンバーの招待

グループ階層ごとに、1日に招待できるメンバーの最大数を制限します。

• GitLab.com: Freeのメンバーは1日あたり20人のメンバーを招待でき、PremiumトライアルおよびUltimateトライアルのメンバーは1日あたり50人のメンバーを招待できます。
• GitLab Self-Managed: 招待数に制限はありません。

Webhookのレート制限

トップレベルのネームスペースにあるWebhookが1分間に呼び出される回数を制限します。ネームスペース内のすべてのプロジェクトおよびグループのWebhookは、この制限を共有します。

レート制限を超過した呼び出しはauth.logにログされます。

Self-Managedインスタンスのこの制限を設定するには、プラン制限APIを使用するか、GitLab Railsコンソールで次のコマンドを実行します:

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

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

制限を0に設定すると、無効になります。

• デフォルトのレート制限: 無効（無制限）。

検索のレート制限

この設定では、検索リクエストを次のように制限します。

1分あたりの検索レート制限を超えた検索リクエストは、次のエラーを返します。

This endpoint has been requested too many times. Try again later.

オートコンプリートユーザーのレート制限

この設定は、オートコンプリートユーザーのリクエストを次のように制限します。

1分あたりのオートコンプリートのレート制限を超えたオートコンプリートリクエストは、次のエラーを返します。

This endpoint has been requested too many times. Try again later.

パイプライン作成のレート制限

この設定は、パイプライン作成エンドポイントへのリクエストレートを制限します。

パイプライン作成のレート制限の詳細を参照してください。

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件のイシュー。

Gitプッシュごとのパイプライン数

複数のタグまたはブランチなど、1回のGitプッシュで複数の変更をプッシュする場合、トリガーできるタグまたはブランチのパイプラインは、デフォルトでは4つまでです。この制限により、git push --allまたはgit push --mirrorを使用する際に、意図せず大量のパイプラインが作成されるのを防ぐことができます。

マージリクエストパイプラインは制限の対象です。Gitプッシュによって複数のマージリクエストを同時に更新する場合、制限に達するまでは、更新されたすべてのマージリクエストに対してマージリクエストパイプラインをトリガーできます。

GitLab Self-ManagedとGitLab.comのデフォルト値は4です。

GitLab Self-Managedインスタンスでこの制限を変更するには、管理者エリアを使用します。

アクティビティ履歴の保持

プロジェクトおよび個人のプロファイルのアクティビティ履歴は3年間に制限されます。

埋め込みメトリクスの数

パフォーマンス上の理由から、GitLab Flavored Markdown（GLFM）にメトリクスを埋め込む場合は制限があります。

• 最大数: 100個の埋め込み。

HTTPレスポンスの制限

Gzip圧縮の最大サイズ

この設定は、解凍後のGzip圧縮されたHTTP応答で許可される最大サイズをMiBで制限します。

デフォルトの最大サイズは100 MiBです。この制限を無効にするには、値を0に設定します。

この制限を変更するには、GitLab Railsコンソールを使用するか、application setting API（アプリケーション設定API）を使用します。

ApplicationSetting.update(max_http_decompressed_size: 50)

送信リクエストからのHTTP応答の最大サイズ

この設定は、解凍されたHTTP応答で許可される最大サイズをMiBで制限します。これは、インテグレーション、インポーター、およびWebhookに適用されます。

デフォルトの最大サイズは100 MiBです。この制限を無効にするには、値を0に設定します。

この制限を変更するには、GitLab Railsコンソールを使用するか、application setting API（アプリケーション設定API）を使用します。

ApplicationSetting.update(max_http_response_size_limit: 60)

送信リクエストからのJSON HTTP応答で許可されるオブジェクトの最大数

この設定は、送信リクエストからのJSON HTTP応答で許可されるオブジェクトの最大数を制限します。オブジェクトの数は、応答中の:、,、{、および[の出現回数に基づいて推定されます。

デフォルトの最大数は1,000,000オブジェクトです。この制限を無効にするには、値を0に設定します。

この制限は、GitLab Railsコンソールを使用するか、アプリケーション設定APIを使用して変更できます:

ApplicationSetting.update(max_http_response_json_structural_chars: 500000)

送信リクエストからのJSON HTTP応答で許可される最大ネスト深度

この設定は、送信リクエストからのJSON HTTP応答で許可される最大ネスト深度を制限します。

デフォルトの最大ネスト深度は32です。

この制限は、GitLab Railsコンソールを使用するか、アプリケーション設定APIを使用して変更できます:

ApplicationSetting.update(max_http_response_json_depth: 100)

送信リクエストからのXML HTTP応答で許可されるオブジェクトの最大数

この設定は、送信リクエストからのXML HTTP応答で許可されるオブジェクトの最大数を制限します。オブジェクトの数は、応答中の<、=の出現回数に基づいて推定されます。

デフォルトの最大数は250,000オブジェクトです。この制限を無効にするには、値を0に設定します。

この制限は、GitLab Railsコンソールを使用するか、アプリケーション設定APIを使用して変更できます:

ApplicationSetting.update(max_http_response_xml_structural_chars: 500000)

送信リクエストからのCSV HTTP応答で許可されるオブジェクトの最大数

この設定は、送信リクエストからのCSV HTTP応答で許可されるオブジェクトの最大数を制限します。オブジェクトの数は、応答中の,、;、\t、および\nの出現回数に基づいて推定されます。

デフォルトの最大数は250,000オブジェクトです。この制限を無効にするには、値を0に設定します。

この制限は、GitLab Railsコンソールを使用するか、アプリケーション設定APIを使用して変更できます:

ApplicationSetting.update(max_http_response_csv_structural_chars: 500000)

HTTPリクエストの制限

デフォルトでは、リクエスト内のJSONパラメータは制限されます。詳細については、JSON検証のエンドポイントごとの制限を参照してください。

gitlab:
  webservice:
    extraEnv:
      GITLAB_JSON_GLOBAL_VALIDATION_MODE: "disabled"

エンドポイントごとのJSON検証制限

一部のAPIエンドポイントには、特定のJSON検証制限があります。

脚注:

1. Terraformステートの最大サイズ制限は、アプリケーション設定APIを使用してmax_terraform_state_size_bytesを設定することで設定できます。

環境変数の設定

次の環境変数は、デフォルトの制限と検証モードを変更します:

GITLAB_JSON_GLOBAL_VALIDATION_MODE環境変数は、これらのモードのいずれかに設定できます。

GITLAB_JSON_GLOBAL_VALIDATION_MODEを使用する場合:

• ルート固有の設定は、デフォルトの制限をオーバーライドしますが、グローバル検証モードはオーバーライドしません。
• 適用済みモードで制限を超過すると、応答はJSONエラーメッセージを含むHTTP 400となります。
• 総要素数は、JSON構造全体にわたる配列とハッシュ内のすべての要素を含みます。

Webhookの制限

Webhookのレート制限も参照してください。

Webhookの数

GitLab Self-ManagedインスタンスでグループまたはプロジェクトのWebhookの最大数を設定するには、GitLab Railsコンソールで次のコマンドを実行します。

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

# For project webhooks
Plan.default.actual_limits.update!(project_hooks: 200)

# For group webhooks
Plan.default.actual_limits.update!(group_hooks: 100)

制限を0に設定すると、無効になります。

Webhookのデフォルトの最大数は、プロジェクトあたり100、グループあたり50です。サブグループのWebhookは、親グループのWebhook制限にはカウントされません。

GitLab.comについては、GitLab.comのWebhook制限を参照してください。

Webhookペイロードのサイズ

Webhookペイロードの最大サイズは25 MBです。

Webhookのタイムアウト

GitLabがWebhookを送信した後、HTTPレスポンスを待機する秒数です。

Webhookのタイムアウト値を変更するには、次の手順に従います。

1. Sidekiqを実行しているすべてのGitLabノードで、/etc/gitlab/gitlab.rbを編集します。

   gitlab_rails['webhook_timeout'] = 60

2. ファイルを保存します。

3. 変更を有効にするには、GitLabを再設定して再起動します。

   gitlab-ctl reconfigure
   gitlab-ctl restart

GitLab.comのWebhook制限も参照してください。

再帰的なWebhook

GitLabは、再帰的なWebhookや、他のWebhookからトリガーされるWebhookの上限を超えるものを検出してブロックします。これにより、Webhookを利用してAPIを非再帰的に呼び出すワークフローや、過剰な数のWebhookをトリガーしないワークフローを引き続きサポートできます。

Webhookが自身のGitLabインスタンス（APIなど）を呼び出すように設定されている場合に再帰が発生する可能性があります。この呼び出しが同じWebhookを再びトリガーし、無限ループを生じるためです。

Webhookが他のWebhookをトリガーする一連の処理で、インスタンスに対して送信できる最大リクエスト数は100です。この制限に達すると、GitLabはそれ以降にトリガーされる他のWebhookをブロックします。

ブロックされた再帰的なWebhook呼び出しは、auth.logに"Recursive webhook blocked from executing"というメッセージとともに記録されます。

インポート時のプレースホルダーユーザーの制限

インポート中に作成されるプレースホルダーユーザーの数は、トップレベルのネームスペースごとに制限できます。

GitLab Self-Managedのデフォルトの制限は0（無制限）です。

GitLab Self-Managedインスタンスでこの制限を変更するには、GitLab Railsコンソールで次のコマンドを実行します。

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

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

制限を0に設定すると、無効になります。

プルミラーリング間隔

プル更新間の最小待機時間は、デフォルトで300秒（5分）に設定されています。たとえば、特定の300秒間に何回トリガーしても、プル更新は1回しか実行されません。

この設定は、projects APIを使用して実行したプル更新のコンテキスト、または設定 > リポジトリ > リポジトリのミラーリングで、今すぐ更新（ ）を選択して強制的に更新する場合に適用されます。この設定は、Sidekiqが自動的に実行する30分間隔のプルミラーリングのスケジュールには影響しません。

GitLab Self-Managedインスタンスでこの制限を変更するには、GitLab Railsコンソールで次のコマンドを実行します。

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

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

自動応答からの受信メール

GitLabは、X-Autoreplyヘッダーを確認することで、自動応答から送信された受信メールをすべて無視します。このようなメールによって、イシューまたはマージリクエストにコメントが作成されることはありません。

エラートラッキングを通じてSentryから送信されるデータ量

セキュリティ上の理由とメモリ消費を制限するため、SentryからGitLabに送信されるペイロードのサイズは、最大1 MBに制限されています。

REST APIにおけるオフセットベースのページネーションで許可される最大オフセット

REST APIでオフセットベースのページネーションを使用する場合、結果セットに対してリクエストできる最大オフセットの制限があります。この制限は、キーセットベースのページネーションもサポートしているエンドポイントにのみ適用されます。ページネーションオプションの詳細については、APIドキュメントのページネーションに関するセクションを参照してください。

GitLab Self-Managedインスタンスでこの制限を設定するには、GitLab Railsコンソールで次のコマンドを実行します。

# If limits don't exist for the default plan, you can create one with:
# 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.comでは、サブスクリプションプランごとに制限が定義されており、この制限はそのプランのすべてのプロジェクトに影響します。
• GitLab Self-ManagedのPremiumまたはUltimateサブスクリプションでは、この制限はdefaultプランで定義され、すべてのプロジェクトに影響します。この制限は、デフォルトで無効（0）になっています。

GitLab Self-Managedインスタンスでこの制限を設定するには、GitLab Railsコンソールで次のコマンドを実行します。

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

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

制限を0に設定すると、無効になります。

ジョブが実行できる最大時間

ジョブが実行できるデフォルトの最大時間は60分です。60分を超えて実行されるジョブはタイムアウトになります。

ジョブがタイムアウトになるまでの最大実行時間は変更できます。

• プロジェクトレベル: 特定のプロジェクトについて、プロジェクトのCI/CD設定で変更します。この制限は、10分から1か月の間でなければなりません。
• Runnerレベル: この制限は10分以上でなければなりません。

設定されているタイムアウト制限に関係なく、GitLabは非アクティブな期間が60分間に達したジョブをすべて終了します。非アクティブなジョブとは、新しいログまたはトレース更新を生成していないジョブのことです。

パイプライン内のジョブの最大数

パイプライン内のジョブの最大数を制限できます。パイプライン内のジョブの数は、パイプラインの作成時と新しいコミットステータスの作成時にチェックされます。ジョブが多すぎるパイプラインは、size_limit_exceededエラーで失敗します。

• GitLab.comでは、サブスクリプションプランごとに制限が定義されており、この制限はそのプランのすべてのプロジェクトに影響します。
• GitLab Self-ManagedのPremiumまたはUltimateサブスクリプションでは、この制限はdefaultプランで定義され、すべてのプロジェクトに影響します。この制限は、デフォルトで無効（0）になっています。

GitLab Self-Managedインスタンスの制限を変更するには、次のGitLab Railsコンソールのコマンドで、defaultプランの制限を変更します。

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

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

制限を0に設定すると、無効になります。

パイプライン内のデプロイジョブの最大数

パイプライン内のデプロイジョブの最大数を制限できます。デプロイとは、environmentが指定されたジョブのことです。パイプライン内のデプロイ数は、パイプラインの作成時にチェックされます。デプロイが多すぎるパイプラインは、deployments_limit_exceededエラーで失敗します。

すべてのGitLab Self-ManagedおよびGitLab.comサブスクリプションにおけるデフォルトの制限は500です。

GitLab Self-Managedインスタンスの制限を変更するには、次のGitLab Railsコンソールのコマンドで、defaultプランの制限を変更します。

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

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

制限を0に設定すると、無効になります。

パイプライン階層サイズを制限する

デフォルトでは、パイプライン階層に含めることができるダウンストリームパイプラインの最大数は1,000個です。この制限を超えると、パイプラインの作成はdownstream pipeline tree is too largeというエラーで失敗します。

インスタンスでこの制限を変更するには、管理者エリアまたはプラン制限APIでGitLab UIを使用します。

GitLab Railsコンソールで次のコマンドを実行することもできます。

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

この制限はGitLab.comで有効になっており、変更できません。

プロジェクトに対するCI/CDサブスクリプションの数

サブスクリプションの総数は、プロジェクトごとに制限できます。この制限は、新しいサブスクリプションが作成されるたびにチェックされます。

新しいサブスクリプションによってサブスクリプションの総数が制限を超える場合、そのサブスクリプションは無効と見なされます。

• GitLab.comでは、サブスクリプションプランごとに制限が定義されており、この制限はそのプランのすべてのプロジェクトに影響します。
• GitLab Self-ManagedのPremiumまたはUltimateでは、この制限はdefaultプランで定義され、すべてのプロジェクトに影響します。デフォルトでは、サブスクリプション数の制限は2です。

GitLab Self-Managedインスタンスでこの制限を設定するには、GitLab Railsコンソールで次のコマンドを実行します。

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

制限を0に設定すると、無効になります。

パイプライントリガー数を制限する

プロジェクトごとにパイプライントリガーの最大数を制限できます。この制限は、新しいトリガーが作成されるたびにチェックされます。

新しいトリガーによってパイプライントリガーの総数が制限を超える場合、そのトリガーは無効と見なされます。

制限を0に設定すると、無効になります。GitLab Self-Managedでは、デフォルトの制限は25000です。

GitLab Self-Managedインスタンスでこの制限を100に設定するには、GitLab Railsコンソールで次のコマンドを実行します。

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

この制限はGitLab.comで有効になっています。

パイプラインスケジュール数

パイプラインスケジュールの総数は、プロジェクトごとに制限できます。この制限は、新しいパイプラインスケジュールが作成されるたびにチェックされます。新しいパイプラインスケジュールによってパイプラインスケジュールの総数が制限を超える場合、そのパイプラインスケジュールは作成されません。

GitLab.comでは、サブスクリプションプランごとに制限が定義されており、この制限はそのプランのすべてのプロジェクトに影響します。

GitLab Self-ManagedおよびGitLab Dedicatedでは、この制限はすべてのプロジェクトに影響を与えるdefaultプランで定義されています。デフォルトでは、パイプラインスケジュール数の制限は10です。

この制限を設定するには、プラン制限APIを使用します。

GitLab Self-Managedの場合は、GitLab Railsコンソールを使用することもできます。たとえば、制限を100に設定するには:

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

1日にパイプラインスケジュールによって作成できるパイプラインの数を制限する

個々のパイプラインスケジュールが1日にトリガーできるパイプライン数を制限できます。

制限を超えてパイプラインを実行しようとするスケジュールは、最大実行頻度まで抑制されます。この頻度は、1,440（1日の分数）を制限値で割ることで計算されます。最大頻度ごとの例を示します。

• 1分に1回の場合、制限値は1440になります。
• 10分に1回の場合、制限値は144になります。
• 60分に1回の場合、制限値は24になります。

最小値は24、つまり60分に1回のパイプライン実行です。最大値の制限はありません。

GitLab Self-Managedインスタンスでこの制限を1440に設定するには、GitLab Railsコンソールで次のコマンドを実行します。

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

この制限はGitLab.comで有効になっています。

セキュリティポリシープロジェクトに定義できるスケジュールルールの数を制限する

セキュリティポリシープロジェクトごとに、スケジュールルールの総数を制限できます。この制限は、スケジュールルールを含むポリシーが更新されるたびにチェックされます。新しいスケジュールルールによってスケジュールルールの総数が制限を超える場合、新しいスケジュールルールは処理されません。

デフォルトでは、GitLab Self-Managedでは処理可能なスケジュールルール数に制限はありません。

GitLab Self-Managedインスタンスでこの制限を設定するには、GitLab Railsコンソールで次のコマンドを実行します。

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

この制限はGitLab.comで有効になっています。

CI/CD変数の制限

プロジェクト、グループ、インスタンスの各設定で定義できるCI/CD変数の数は、インスタンス全体で制限されています。これらの制限は、新しい変数が作成されるたびにチェックされます。新しい変数によって変数の総数がそれぞれの制限を超える場合、新しい変数は作成されません。

GitLab Self-Managedインスタンスで、これらの制限のdefaultプランを更新するには、GitLab Railsコンソールで次のコマンドを実行します。

• インスタンスレベルのCI/CD変数制限（デフォルト: 25）:

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

• グループレベルのCI/CD変数制限（グループごと、デフォルト: 30000）:

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

• プロジェクトレベルのCI/CD変数制限（プロジェクトごと、デフォルト: 8000）:

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

アーティファクトのタイプごとの最大ファイルサイズ

artifacts:reportsで定義されたジョブアーティファクトについて、Runnerによってアップロードされたファイルが最大ファイルサイズ制限を超える場合、そのファイルは拒否されます。この制限は、プロジェクトの最大アーティファクトサイズ設定と、指定されたアーティファクトタイプに対するインスタンスの制限を比較し、小さい方の値が適用されます。

制限はメガバイト単位で設定されるため、定義できる最小値は1 MBです。

アーティファクトのタイプごとにサイズ制限を設定できます。デフォルトが0の場合、その特定のアーティファクトタイプには制限がなく、プロジェクトの最大アーティファクトサイズ設定が使用されます。

たとえば、ci_max_artifact_size_junit制限をGitLab Self-Managedで10 MBに設定するには、GitLab Railsコンソールで次のコマンドを実行します。

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

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（無制限）です。インスタンスに制限を設定するには、管理者エリアを使用します。

Pagesの並列デプロイ数

Pagesの並列デプロイを使用する場合、トップレベルのネームスペースで許可されるPagesの並列デプロイの総数は1,000です。

プロジェクトでユニークドメインが有効になっている場合、そのプロジェクトのユニークドメインは、1000デプロイという個別の制限を持つ独自のトップレベルネームスペースとして扱われます。

スコープごとの登録Runner数

グループとプロジェクトに登録できるRunnerの総数は制限されています。新しいRunnerが登録されるたびに、GitLabは過去7日間に作成された、またはアクティブだったRunnerに対してこの制限をチェックします。Runner登録トークンで決定されるスコープの制限を超えた場合、Runnerの登録は失敗します。制限値がゼロに設定されている場合、制限は無効になります。

GitLab.comのサブスクライバーは、サブスクリプションごとに異なる制限が定義されており、そのサブスクリプションを使用するすべてのプロジェクトに影響します。

GitLab Self-ManagedのPremiumおよびUltimateでは、この制限はデフォルトプランで定義され、すべてのプロジェクトに影響します。

これらの制限を更新するには、GitLab Railsコンソールで次のコマンドを実行します。

# Use ci_registered_group_runners or ci_registered_project_runners
# depending on desired scope
Plan.default.actual_limits.update!(ci_registered_project_runners: 100)

ジョブログの最大ファイルサイズ

GitLabのジョブログファイルサイズの制限は、デフォルトで100 MBです。制限を超過したジョブは失敗とマークされ、Runnerによって破棄されます。

この制限はGitLab Railsコンソールで変更できます。ci_jobs_trace_size_limitに、新しい値をメガバイト単位で設定します。

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

GitLab Runnerには、Runner内の最大ログサイズを指定するoutput_limitという設定もあります。Runnerの制限を超えたジョブは引き続き実行されますが、ログは制限に達すると切り詰められます。

プロジェクトごとのアクティブなDASTプロファイルスケジュールの最大数

プロジェクトごとのアクティブなDASTプロファイルスケジュールの数を制限できます。DASTプロファイルスケジュールは、アクティブまたは非アクティブにすることができます。

この制限はGitLab Railsコンソールで変更できます。dast_profile_schedulesに新しい値を設定します。

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

CIアーティファクトアーカイブの最大サイズ

この設定は、動的な子パイプラインにおけるYAMLのサイズを制限するために使用されます。

CIアーティファクトアーカイブのデフォルトの最大サイズは5メガバイトです。

この制限を変更するには、GitLab Railsコンソールを使用します。CIアーティファクトアーカイブの最大サイズを更新するには、max_artifacts_content_include_sizeに新しい値を設定します。たとえば、20 MBに設定するには、次のコマンドを実行します。

ApplicationSetting.update(max_artifacts_content_include_size: 20.megabytes)

CI/CD設定YAMLファイルの最大サイズと最大深度

単一のCI/CD設定YAMLファイルに対するデフォルトの最大サイズは2メガバイトで、デフォルトの最大深度は100です。

これらの制限は、GitLab Railsコンソールで変更できます。

• YAMLの最大サイズを更新するには、max_yaml_size_bytesに新しい値をメガバイト単位で設定します。

  ApplicationSetting.update(max_yaml_size_bytes: 4.megabytes)

  max_yaml_size_bytesの値はYAMLファイルのサイズに直接関係するのではなく、関連オブジェクトに割り当てられるメモリに関係します。

• YAMLの最大深度を更新するには、max_yaml_depthに行数単位で新しい値を設定します。

  ApplicationSetting.update(max_yaml_depth: 125)

CI/CD設定全体の最大サイズ

すべてのYAML設定ファイルを含む、パイプライン設定全体に対して割り当て可能な最大メモリ量（バイト単位）です。

デフォルト値は、max_yaml_size_bytes（デフォルトは2 MB）とci_max_includes（デフォルトは150）を乗算することで算出されます。

• GitLab 17.2以前: 1 MB × 150 = 157286400バイト（150 MB）。
• GitLab 17.3以降: 2 MB × 150 = 314572800バイト（314.6 MB）。

この制限を変更するには、GitLab Railsコンソールを使用します。CI/CD設定に割り当て可能な最大メモリ量を更新するには、ci_max_total_yaml_size_bytesに新しい値を設定します。たとえば、20 MBに設定するには、次のコマンドを実行します。

ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)

dotenv変数を制限する

dotenvアーティファクト内の変数の最大数に制限を設定できます。この制限は、dotenvファイルがアーティファクトとしてエクスポートされるたびにチェックされます。

制限を0に設定すると、無効になります。GitLab Self-Managedでは、デフォルトの制限は20です。

インスタンスでこの制限を100に設定するには、GitLab Railsコンソールで次のコマンドを実行します。

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

この制限は、GitLab UIまたはプラン制限APIを使用して設定することもできます。

この制限はGitLab.comで有効になっています。

dotenvファイルサイズを制限する

dotenvアーティファクトの最大サイズに制限を設定できます。この制限は、dotenvファイルがアーティファクトとしてエクスポートされるたびにチェックされます。

制限を0に設定すると、無効になります。デフォルトは5 KBです。

GitLab Self-Managedインスタンスでこの制限を5 KBに設定するには、GitLab Railsコンソールで次のコマンドを実行します。

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

CI/CDジョブのアノテーション数を制限する

CI/CDジョブごとのアノテーションの最大数に制限を設定できます。

制限を0に設定すると、無効になります。GitLab Self-Managedでは、デフォルトの制限は20です。

インスタンスでこの制限を100に設定するには、GitLab Railsコンソールで次のコマンドを実行します。

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

CI/CDジョブのアノテーションファイルサイズを制限する

CI/CDジョブのアノテーションの最大サイズに制限を設定できます。

制限を0に設定すると、無効になります。デフォルトは80 KBです。

GitLab Self-Managedインスタンスでこの制限を100 KBに設定するには、GitLab Railsコンソールで次のコマンドを実行します。

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

CI/CDテーブルの最大データベースパーティションサイズ

パーティション分割テーブルのパーティションが使用できる最大ディスク容量（バイト単位）。これを超えると新しいパーティションが自動的に作成されます。デフォルトは100 GBです。

この制限を変更するには、GitLab Railsコンソールを使用します。この制限を変更するには、ci_partitions_size_limitを新しい値で更新します。たとえば、20 GBに設定するには、次のコマンドを実行します。

ApplicationSetting.update(ci_partitions_size_limit: 20.gigabytes)

自動パイプラインクリーンアップの最大設定値

CI/CDパイプラインの有効期限の上限を設定します。デフォルトは1年です。

この制限を変更するには、GitLab Railsコンソールを使用します。この制限を変更するには、ci_delete_pipelines_in_seconds_limit_human_readableを新しい値で更新します。たとえば3年に設定するには、次のコマンドを実行します。

ApplicationSetting.update(ci_delete_pipelines_in_seconds_limit_human_readable: '3 years')

インスタンスのモニタリングとメトリクス

受信できるインシデント管理アラートを制限する

この設定は、一定期間に受信できるアラートのペイロード数を制限します。

インシデント管理のレート制限の詳細を参照してください。

PrometheusアラートのJSONペイロード

notify.jsonエンドポイントに送信されるPrometheusアラートのペイロードは、サイズが1 MBに制限されています。

汎用アラートのJSONペイロード

notify.jsonエンドポイントに送信されるアラートのペイロードは、サイズが1 MBに制限されています。

環境ダッシュボードの制限

表示されるプロジェクトの最大数については、環境ダッシュボードを参照してください。

デプロイボードの環境データ

デプロイボードは、Kubernetesからポッドとデプロイに関する情報を読み込みます。ただし、特定の環境についてKubernetesから読み取られたデータが10 MBを超える場合、そのデータは表示されません。

マージリクエスト

差分の制限

GitLabには、以下の制限があります。

• 単一ファイルのパッチサイズ。これはGitLab Self-Managedで設定可能です。
• マージリクエストに含まれるすべての差分の合計サイズ。

以下のそれぞれに、上限と下限が適用されます。

• 変更されたファイル数。
• 変更された行数。
• 表示される変更の累積サイズ。

下限に到達すると、追加の差分が折りたたまれます。上限を上回ると、それ以上の変更は表示されません。これらの制限の詳細については、差分の操作に関するGitLab開発ドキュメントを参照してください。

差分バージョンの制限

GitLabでは、各マージリクエストを1,000件の差分バージョンに制限しています。この制限に達したマージリクエストは、それ以上更新できません。代わりに、影響を受けたマージリクエストをクローズし、新しいマージリクエストを作成してください。

マージリクエストのレポートサイズ制限

20 MBを超えるレポートは読み込まれません。影響を受けるレポートは次のとおりです。

• マージリクエストのセキュリティレポート
• CI/CDパラメータartifacts:expose_as
• 単体テストレポート

高度な検索の制限

インデックスが作成されるファイルの最大サイズ

Elasticsearchでインデックスを作成するリポジトリファイルの内容に、制限を設定できます。この制限よりも大きいファイルは、ファイル名のみがインデックス作成の対象となります。ファイルの内容についてはインデックスが作成されず、検索できません。

制限を設定することで、インデックス作成プロセスのメモリ使用量とインデックス全体のサイズを削減できます。この値は、デフォルトで1024 KiB（1 MiB）に設定されています。これよりも大きいテキストファイルは、人間が読むことを目的としていない可能性が高いためです。

無制限のファイルサイズはサポートしていないため、必ず制限を設定する必要があります。この値をGitLab Sidekiqノードのメモリ量よりも大きく設定すると、インデックス作成時にこのメモリ量が事前に割り当てられるため、GitLab Sidekiqノードのメモリが不足する可能性があります。

最大フィールド長

高度な検索用にインデックスが作成されるテキストフィールドの内容に、制限を設定できます。最大値を設定すると、インデックス作成プロセスの負荷を軽減できます。テキストフィールドがこの制限を超えると、テキストは指定した文字数に切り詰められます。テキストの残りの部分についてはインデックスが作成されず、検索できません。別の制限が適用されるリポジトリファイルを除く、インデックス作成対象のすべてのデータにこの制限が適用されます。詳細については、インデックスが作成されるファイルの最大サイズを参照してください。

• GitLab.comでは、フィールドの文字数制限は20,000文字です。
• GitLab Self-Managedインスタンスの場合、デフォルトでフィールドの文字数に制限はありません。

Elasticsearchを有効にする際に、GitLab Self-Managedインスタンスに対してこの制限を設定できます。制限を0に設定すると、無効になります。

数式のレンダリング制限

GitLabでは、Markdownフィールドで数式をレンダリングする際に、デフォルトの制限が課せられます。これらの制限により、セキュリティとパフォーマンスが向上します。

イシュー、マージリクエスト、エピック、Wiki、リポジトリファイルに対する制限は次のとおりです。

• マクロ展開の最大数: 1000。
• ユーザー指定の最大サイズ（em単位）: 20。
• レンダリングされるノードの最大数: 50。
• 数式ブロック内の最大文字数: 1000。
• 最大レンダリング時間: 2000 ms。

GitLab Self-Managedを実行しており、ユーザー入力を信頼できる場合は、これらの制限を無効にできます。

GitLab Railsコンソールを使用します。

ApplicationSetting.update(math_rendering_limits_enabled: false)

これらの制限は、GraphQLまたはREST APIを使用して、グループ単位で無効にすることもできます。

この制限を無効にすると、イシュー、マージリクエスト、エピック、Wiki、リポジトリファイル内の数式はほぼ無制限にレンダリングされます。これは、悪意のある第三者が、ブラウザでの閲覧時にDoSを引き起こす可能性のある数式を追加できることを意味します。そのため、信頼できるユーザーのみがコンテンツを追加できるようにする必要があります。

Wikiの制限

• Wikiページコンテンツのサイズ制限。
• ファイル名とディレクトリ名の長さ制限。

スニペットの制限

スニペットの設定に関するドキュメントを参照してください。

設計管理の制限

イシューにデザインを追加するセクションの制限を参照してください。

プッシュイベントの制限

最大プッシュサイズ

許可されるプッシュサイズの最大値。

GitLab Self-Managedでは、デフォルトで設定されていません。GitLab.comについては、アカウントと制限の設定を参照してください。

Webhookとプロジェクトサービス

単一のプッシュで行われる変更（ブランチまたはタグ）の合計数。変更数が指定された制限を超えると、フックは実行されません。

詳細については、以下を参照してください。

• Webhookプッシュイベント
• プロジェクトインテグレーションのプッシュフック制限

アクティビティ

単一のプッシュにおける変更（ブランチまたはタグ）の合計数。この値を基準に、個別のプッシュイベントを作成するか、一括プッシュイベントを作成するかが決まります。

詳細については、プッシュイベントアクティビティの制限と一括プッシュイベントに関するドキュメントを参照してください。

パッケージレジストリの制限

ファイルサイズの制限

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の最大ファイルサイズは異なる場合があります。

GitLab Self-Managedインスタンスでこれらの制限を設定するには、管理者エリアを使用するか、GitLab Railsコンソールで次のコマンドを実行します。

# File size limit is stored in bytes

# 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件のバージョンを返します。

依存プロキシの制限

依存プロキシでキャッシュされるイメージの最大ファイルサイズは、ファイルタイプによって異なります。

• イメージblob: 5 GB
• イメージマニフェスト: 10 MB

担当者とレビュアーの最大数

イシューとマージリクエストでは、次の最大数が適用されます。

• 担当者の最大数: 200
• レビュアーの最大数: 200

プロジェクトのプッシュミラーの最大数

各プロジェクトで有効にできるプッシュミラーの最大数は10個です。この制限は、過剰な同時同期ジョブによるパフォーマンスの問題を防ぎます。

より多くのミラーが必要な場合は、次のことができます:

• 未使用のミラーを無効にします。
• 複数の宛先を1つのミラーに結合して、ミラーを統合します。

GitLab.comのCDNベースの制限

アプリケーションベースの制限に加えて、GitLab.comでは、Cloudflare（標準的なDDoS保護）とSpectrum（SSH経由のGitアクセスの保護）を使用するよう設定されています。CloudflareはクライアントTLS接続を終端しますが、アプリケーションを認識しないため、ユーザーやグループに関連付けられた制限には使用できません。Cloudflareのページルールとレート制限はTerraformで設定されています。これらの設定は、悪意のあるアクティビティを検出するセキュリティ対策や不正行為防止対策が含まれているため、公開されていません。公開すると、これらの対策の効果が損なわれるおそれがあります。

コンテナリポジトリのタグ削除制限

コンテナリポジトリタグはコンテナレジストリ内にあるため、タグを削除するたびに、コンテナレジストリへのネットワークリクエストがトリガーされます。このため、1回のAPIコールで削除できるタグの数を20に制限しています。

プロジェクトレベルのセキュアファイルAPIの制限

セキュアファイルAPIには、次の制限が適用されます。

• ファイルは5 MB未満である必要があります。
• プロジェクトに登録できる安全なファイルの最大数は100です。

変更履歴APIの制限

変更履歴APIには、次の制限が適用されます。

• fromとtoの間のコミット範囲は、15,000コミットを超えることはできません。

バリューストリーム分析の制限

• 各ネームスペース（グループやプロジェクトなど）は、最大50個のバリューストリームを持つことができます。
• 各バリューストリームは、最大15個のステージを持つことができます。

監査イベントストリーミングの配信先の制限

カスタムHTTPエンドポイント

• 各トップレベルグループには、最大5つのカスタムHTTPストリーミング配信先を設定できます。

Google Cloud Logging

• 各トップレベルグループには、最大5つのGoogle Cloud Loggingストリーミング配信先を設定できます。

Amazon S3

• 各トップレベルグループには、最大5つのAmazon S3ストリーミング配信先を設定できます。

依存関係スキャン（SBOMを使用）の制限

The 依存関係スキャン（SBOMを使用する機能）は、次の制限を持つ内部APIを使用します:

• プロジェクトごとの1時間あたりの最大アップロードリクエスト数: 400
• プロジェクトごとの1時間あたりの最大ダウンロードリクエスト数: 6000

これらの制限は、GitLab Self-Managedインスタンスの依存関係スキャンの設定を使用して設定できます。

コミットとファイルAPIの制限

コミットとファイルAPIは、次のエンドポイントで最大サイズとレート制限を適用します:

• POST /projects/:id/repository/commits - コミットを作成

• POST /projects/:id/repository/files/:file_path - リポジトリ内にファイルを作成

• PUT /projects/:id/repository/files/:file_path - リポジトリ内のファイルを更新

• Maximum request size: この制限を超過するリクエストは、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 Self-ManagedでGITLAB_COMMITS_MAX_REQUEST_SIZE_BYTES環境変数を設定することで設定可能です。この変数は、最大リクエストサイズをバイト単位で設定します。環境変数の設定方法については、HTTPリクエスト制限を参照してください。

すべてのインスタンス制限値を一覧表示する

すべてのインスタンス制限値を一覧表示するには、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,
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]と表示されます。