Rate Limiting

This page exists to consolidate GitLab Rate Limiting documentation into a single source of truth. It is intended to reflect the current state of our rate limits, with the target audience being Operators (SRE and Support team members).

Overview

Rate limiting is a critical feature in GitLab that enhances security and performance by restricting the number of requests users or IP addresses can make within a set timeframe. GitLab’s approach to rate limiting helps prevent abuse, ensures fair resource allocation, and maintains system stability, effectively safeguarding against potential attacks and ensuring a reliable user experience.

Rate limited requests will return a 429 - Too Many Requests response.

Processes

GitLab Rate Limit Architecture

GitLab.com

GitLab

Cloudflare WAF

HAProxy

gitlab.com

customers.gitlab.com

*.gitlab.io

registry.gitlab.com

Internet

gitlab.com zone

customers.gitlab.com zone

pages kubernetes limits

registry_https

https + ssh

nginx

pages application limits

Rack::Attack

Gitlab::ApplicationRateLimiter

Cloud Connector

GitLab

Cloudflare WAF

AWS

GKE

CloudRun / GKE

cloud.gitlab.com

cloud.gitlab.com

cloud.gitlab.com

Internet

cloud.gitlab.com zone

Cloud Connector backends

gitlab.com

GitLab Dedicated

Rate limits exist in multiple layers for GitLab.com, each boxed area above represents a place where rate limits are implemented.

Limits

To minimise duplication, please see the following sources to determine the current active rate limits:

Cloudflare
Application

Bypasses

Published rate limits apply to all customers and users with no exceptions.

Customers or internal teams seeking a bypass should refer to the Rate Limit Bypass Policy.

Traffic management Rate Limits

Cloudflare

Cloudflare serves as our “outer-most” layer of protection, sitting at the network edge on inbound traffic. We use Cloudflare’s standard DDoS (Distributed Denial of Service) protection plus Spectrum to protect git over ssh.

How rate limits are applied in Cloudflare:

Gitlab.com Page Rules
  • Configured by Terraform in config-mgmt.
  • URL pattern matching.
  • Control Cloudflare’s DDoS interventions and caching (e.g. bypasses, security levels etc).
  • No rate limits configured by default, but they can be enabled when under an attack
Gitlab.com Rate Limiting
  • Configured by Terraform in config-mgmt.
  • Covers a wide range of cases:
    • Global limits per IP
    • Global limits per session (cookies) or tokens (headers) can be used as rate counters to avoid IP scope false positives, e.g. many users behind a single IP, VPN.
  • Endpoint-specific limits.
  • Independent of application rate limits.
Cloud Connector Rate Limiting
  • Configured by Terraform (see runbook links).
  • Limits per application-specific HTTP header fields.
  • Throttles both end-user clients such as IDEs as well as GitLab Rails instances (GL.com, SM and Dedicated.)
  • Primarily used to throttle consumption of non-horizontally scalable resources such as AI vendor limits.
  • Can be configured for each Cloud Connector backend individually.
  • Backends can segment requests using custom selectors and map them to buckets. Each bucket:
    • Might represent a certain user or customer cohort.
    • Can define a per-user and per-instance rate limit.
    • For example, we segment AI requests into Small, Medium and Large customers based on the number of Duo seats they purchased from us. The more seats they have, the more requests they get.
    • It is possible and allowed to define a single catch-all bucket that matches all requests, in which case each request observes the same static rate limit.

Note: Cloudflare is not application aware and does not know how to map to our users and groups.

Cloudflare is also responsible for applying the X-GitLab-Rate-Limit-Bypass header to a subset of requests from:

  • Legacy customer IP rate limit bypasses
  • Third party vendors with whom we have integrations
  • Internal infrastructure

For a full list of conditions where the header will be applied, see this configuration.

Our Cloudflare runbook contains more detail on configuring this layer of our infrastructure.

Changes to Cloudflare rate limits require a Change Request, and should be discussed with the Production Engineering::Foundations SRE team before implementing.

HAProxy

The majority of GitLab’s traffic management rate limits have been moved out of HAProxy and into Cloudflare (see this confidential issue for more details).

However, HAProxy is still responsible for Registry rate limits, as that component is not fronted by Cloudflare. See Registry for more details.

Currently HAProxy also handles applying the X-GitLab-Rate-Limit-Bypass for a limited number of special paths. The list can be found here, but there is work underway to move this logic out into Cloudflare as well.

Application Rate Limits

There are multiple application rate limiting mechanisms in place that can often be referred to interchangeably. These allow for more informed traffic management compared to that implemented by Cloudflare as the application has access to user information:

Please see Application Limits Development to contribute application limits to GitLab.

Overview

The rate limit period is 1 minute (60 seconds).

Category

Identifier

Unauthenticated

IP address

Authenticated

User information (user, project, etc)

Protected Paths

Configurable list of paths e.g. /user/sign_in

RackAttack

GitLab utilises RackAttack as middleware to throttle Rack requests. These can be configured by extending Gitlab::RackAttack and Gitlab::RackAttack::Request.

For more information about configuring rate limits for a GitLab instance, see the User and IP rate limits doc.

You can read more information about rate limits specific to GitLab.com, alongside RackAttack configuration documentation in runbooks.

ApplicationRateLimiter

The GitLab application has simple rate limit logic that can be used to throttle certain actions which is used when we need more flexibility than what Rack Attack can provide, since it can throttle at the controller or API level. These rate limits are configured in application_rate_limiter.rb. The scope is up to the individual limit implementation and can be any ActiveRecord object or combination of multiple. It is commonly per-user or per-project (or both), but it can be anything, e.g. the RawController limits by project and path.

There is no way to bypass these rate limits (e.g. for select users/groups/projects); when the rate limit is reached a plain response with a 429 status code is issued without rate limiting headers.

Instructions for configuring these rate limits can be found in the GitLab docs.

For more information about introducing new Rate Limits for GitLab, see the Product Processes Handbook page.

Other Rate Limits

GitLab Pages

Because GitLab Pages is not behind CloudFlare and doesn’t have CDN support, rate limits are set in several places:

  1. Within the Kubernetes settings for GitLab.com.
  2. In the Go ratelimiter module for Pages.

For more information, see the Pages Rate Limit documentation.

Registry

Registry is not fronted by Cloudflare (see this confidential issue for full details around why). There is no application-level setting for it either (though there is an open feature request to add that), so the only place where there is rate limiting in place for Registry is in HAProxy.

There are no rate limit exceptions available for Registry.

Headers

The list of semi-standard rate limiting response headers can be found here.

  • Cloudflare does not return rate limit response headers on any request.
  • RackAttack returns rate limit response headers on throttled requests only.
  • ApplicationRateLimiter does not return rate limit response headers.
  • GraphQL endpoints currently do not return rate limit response headers.

See this issue for improvements to returning rate limiting response headers.

Avoiding Rate Limits

To minimize the risk of hitting rate limits, you can try the following:

Troubleshooting

Please see Rate Limiting Troubleshooting.


Bypass Policy
This policy relates to the rate limits for GitLab.com, for Self-Managed and Dedicated please reach out to your administrator.
Rate Limiting Troubleshooting
This documentation is intended to aid in investigations related to GitLab.com rate limiting and potential IP blocks.
Last modified January 24, 2025: Update rate limiting docs (043436a8)