GitLab.com меняет лимиты запросов по тарифам

GitLab объявил, что с 19 октября 2026 года лимиты запросов к API на GitLab.com станут зависеть от тарифа. Первыми под новые правила попадают бесплатные аккаунты и неавторизованные (анонимные) запросы, с 19 октября; пользователи Premium и Ultimate переходят на новые лимиты позже, в январе 2027 года. Запрос без учётных данных получает лимит 60 запросов в час на IP-адрес; авторизация, личным токеном доступа, OAuth-токеном или токеном CI/CD-задания, сразу переводит запрос на лимит соответствующего тарифа, который заметно выше. Сами числовые значения лимитов по тарифам GitLab в посте не приводит, отсылая к отдельной документации; известно лишь, что, по словам компании, лимит для бесплатного тарифа и анонимного доступа соответствует принятому в индустрии уровню, а лимиты Premium и Ultimate выше и сопоставимы с тем, что другие платформы обычно резервируют для корпоративных тарифов или вовсе не публикуют. Перед тем как изменения вступят в силу для бесплатного тарифа и анонимных запросов, пройдут два тестовых окна, 7 и 14 октября, с 15:00 до 19:00 UTC, в которые новые лимиты кратковременно включат и снова выключат, чтобы пользователи могли заранее увидеть, как их нагрузка ведёт себя под новыми ограничениями; на авторизованные запросы Premium и Ultimate эти окна не влияют. Пользователь, состоящий сразу в нескольких группах верхнего уровня, получает лимит по самому щедрому из доступных ему тарифов. При превышении лимита сервис возвращает код 429 Too Many Requests с заголовком Retry-After, который указывает, сколько ждать до повторной попытки; GitLab также советует следить за заголовком RateLimit-Remaining в ответах API и позже обещает встроенную в продукт панель использования. Владельцам публичных проектов с большим анонимным трафиком компания предлагает три варианта: перевести обращающуюся к проекту автоматизацию на авторизацию, закрыть проект от анонимного доступа, если трафик идёт не от целевой аудитории, либо перейти на Premium или Ultimate. Для интеграций, которые в принципе не могут авторизоваться (пример из поста, публичный бейдж статуса), GitLab просит написать на limits@gitlab.com. Отдельно компания говорит, что прорабатывает платную опцию докупить лимит сверх тарифа, но детали, включая цену, обещает раскрыть позже в этом году. Изменение касается только GitLab.com, на GitLab Self-Managed и GitLab Dedicated новые лимиты не распространяются.

Ключевые факты

С 19 октября 2026 года лимиты запросов к API GitLab.com для бесплатных аккаунтов и анонимных обращений будут зависеть от тарифа; для Premium и Ultimate изменения начнутся в январе 2027 года.
Запрос без авторизации получает лимит 60 запросов в час на IP-адрес; авторизация через личный токен, OAuth или токен CI/CD-задания переводит запрос на куда более высокий лимит тарифа.
7 и 14 октября с 15:00 до 19:00 UTC пройдут два тестовых окна, в которые новые лимиты кратковременно включат только для бесплатного тарифа и анонимных запросов.
При превышении лимита сервис вернёт код 429 Too Many Requests с заголовком Retry-After, указывающим, сколько ждать до повтора.
Изменение касается только GitLab.com; на GitLab Self-Managed и GitLab Dedicated лимиты не распространяются.

Почему это важно

GitLab объясняет перемену ростом нагрузки: спрос на платформу быстро растёт, и компания ожидает многократное увеличение нагрузки на GitLab.com в течение года, в том числе за счёт автоматизации и ИИ-агентов, которые обращаются к платформе программно. Привязка лимитов к тарифу должна удержать GitLab.com быстрым для всех пользователей и не дать отдельным тяжёлым нагрузкам замедлять его для остальных.

Кому это важно

В первую очередь, владельцам публичных проектов на GitLab.com с большим анонимным трафиком (боты, интеграции без авторизации), а также разработчикам, которые строят автоматизацию и агентов поверх API GitLab.com на бесплатном тарифе. Пользователей Premium и Ultimate изменения затронут позже, в январе 2027 года, и, по словам GitLab, почти никто из уже авторизованных пользователей не заметит разницы, потому что их обычная нагрузка укладывается в новые лимиты.

Как это применить

GitLab советует три конкретных шага. Во-первых, авторизовать запросы, личным токеном доступа, OAuth-токеном или токеном CI/CD-задания, это сразу переводит их с анонимного лимита 60 запросов в час на куда более высокий лимит тарифа. Во-вторых, следить за заголовком RateLimit-Remaining в ответах API, чтобы видеть остаток текущего окна, а позже, за встроенной в продукт панелью использования, которую GitLab обещает выпустить позже в этом году. В-третьих, оптимизировать сам вызов API: группировать запросы, кэшировать ответы и использовать постраничную выгрузку вместо частого опроса в цикле; при получении 429 нужно ждать интервал из заголовка Retry-After и увеличивать паузу экспоненциально при повторных отказах. Владельцам публичных проектов с большим анонимным трафиком GitLab предлагает либо перевести вызывающую автоматизацию на авторизацию, либо закрыть проект от анонимного доступа, либо перейти на Premium или Ultimate.

Можно ли доверять

Источник, официальный блог GitLab, опубликованный 17 сентября 2026 года, то есть это прямое заявление самой компании о собственном сервисе, а не пересказ третьей стороны. При этом пост не публикует точные цифры лимитов по тарифам, только ссылку на отдельную документацию, не называет ни автора текста, ни точную цену будущей возможности докупить лимит сверх тарифа: срок для неё указан размыто, «позже в этом году».

Риски и подводные камни

Главный риск, для публичных проектов, чей трафик идёт в основном от неавторизованных обращений: после 19 октября такие обращения упрутся в лимит 60 запросов в час на IP, если владелец заранее не переведёт вызывающие сервисы на авторизацию или не закроет проект от анонимного доступа. GitLab признаёт, что бывают легитимные сценарии без авторизации (например, публичный бейдж статуса), и предлагает таким интеграциям писать на limits@gitlab.com, но конкретной альтернативы для них в посте не описано. Отдельный риск, сама неопределённость: точные числа лимитов, цена дополнительной ёмкости и дата панели использования в посте не названы, так что оценить последствия для конкретного проекта заранее можно только по документации или на тестовых окнах 7 и 14 октября.

«Почти все пользователи уже укладываются в новые лимиты и не заметят никаких изменений.»

— GitLab, блог компании