GitLab.com zaostrza limity API od 19 października — co musisz wiedzieć

17 września 2026 roku GitLab ogłosił, że od 19 października GitLab.com zaczyna egzekwować nowe limity przepustowości API dostosowane do planu subskrypcji. To zmiana, która dotyczy przede wszystkim kont Free i nieuwierzytelnionych żądań — ale jej kontekst jest szerszy: GitLab prognozuje kilkukrotny wzrost ruchu API w 2026 roku, napędzany przez agentów AI i zautomatyzowane narzędzia deweloperskie.

Dlaczego GitLab wprowadza te zmiany

Model działał dopóki większość ruchu generowali tradycyjni użytkownicy — skrypty, webhook'i i pipeline'y CI/CD pracujące w tempie typowym dla pracy człowieka.

Agenci AI zmienili ten rachunek fundamentalnie. GitLab prognozuje kilkukrotny wzrost ruchu w 2026 roku, napędzanego przez agentów AI i zautomatyzowane narzędzia deweloperskie. Jeden agent kodowania może w ciągu minuty wygenerować tyle żądań API co deweloper przez cały dzień — tworząc MR, komentując, sprawdzając statusy, pobierając konfiguracje. W środowisku z dziesiątkami równoległych agentów to obciążenie infrastruktury platformy staje się poważnym wyzwaniem.

GitLab mówi wprost: "aktualizacja limitów jest konieczna, by utrzymać stabilność platformy w miarę jej skalowania."

Co konkretnie się zmienia i kiedy

Harmonogram wdrożenia

Zmiana przebiega w trzech etapach:

7 i 14 października (15:00–19:00 UTC) — brownout windows

Dwa podglądowe okna „brownout" na 7 i 14 października (15:00–19:00 UTC) pozwalają ruchowi Free i nieuwierzytelnionemu przetestować zachowanie
z nowymi limitami.To próby generalne — GitLab włącza nowe limity na cztery godziny, a następnie je wyłącza. Jeśli Twoje pipeline'y lub skrypty zaczną zwracać błędy 429 podczas tych okien — masz sygnał do działania przed właściwą datą.

19 października 2026 — konta Free i żądania nieuwierzytelnione

Na październik 19 nowe limity wchodzą w życie dla kont Free i nieuwierzytelnionych żądań.

Styczeń 2027 — konta Premium i Ultimate

Premium i Ultimate przejdą na nowe limity w styczniu 2027.

Nowe limity według planu

GitLab.com od 19 października egzekwuje limity zgodne z poziomem subskrypcji,
a każde żądanie bez poświadczeń wpada w limit do 60 żądań na godzinę na adres IP.

Szczegółowe wartości według oficjalnej tabeli GitLab:

GitLab sprawdza najpierw limity planu, a następnie istniejące limity — stosuje się ten który jest niższy, więc uwierzytelniony ruch API użytkownika jest nadal ograniczony do 2 000 żądań na minutę niezależnie od poziomu.

Ważna granica: nowe limity planu obejmują żądania API, żądania webowe i uwierzytelniony Git przez HTTPS.

Kogo NIE dotyczy ta zmiana

Zmiany dotyczą wyłącznie GitLab.com — instalacje Self-Managed i Dedicated nie podlegają nowym limitom.

Jeśli eksploatujesz własną instancję GitLab (on-premises lub w prywatnej chmurze) — ta konkretna zmiana Cię nie obejmuje. Administratorzy Self-Managed mogą jednak skonfigurować analogiczne limity samodzielnie przez UI lub API ustawień aplikacji.

Kto faktycznie odczuje zmianę

GitLab twierdzi, że prawie wszyscy obecni użytkownicy już mieszczą się w nowych limitach i nie odczują żadnej różnicy — ograniczenia dotyczą przede wszystkim intensywnych workloadów automatyzacyjnych i niewielkiej części kont Free.

W praktyce zmiana będzie odczuwalna w kilku konkretnych scenariuszach:

Skrypty i narzędzia wykonywane bez uwierzytelnienia. Limit 60 żądań na godzinę per IP to bardzo niski próg — każde narzędzie odpytujące publiczne API GitLab bez tokenu dostępu uderzy w ten limit przy minimalnym użytkowaniu. Dotyczy to w szczególności: skryptów inwentaryzacji repozytoriów, narzędzi monitoringu publicznych projektów, CI/CD runnerów konfigurowanych bez CI_JOB_TOKEN.

Agenci AI bez właściwego uwierzytelnienia. Agent kodowania działający bez skonfigurowanego tokenu dostępu będzie ograniczony do 60 żądań na godzinę — co przy intensywnym użytkowaniu zatrzyma pracę w ciągu kilku minut.

Organizacje z dużą liczbą automatyzacji na koncie Free. Narzędzia DevSecOps skanujące repozytoria, boty do code review, automatyczne generatory raportów — jeśli działają na koncie Free, limit 5 000 żądań na godzinę może być osiągalny przy wielu równoległych procesach.

Co zrobić — praktyczne kroki

1. Uwierzytelnij wszystkie żądania

GitLab zaleca uwierzytelnianie żądań przez personal access token, OAuth lub CI/CD job token.

Nieuwierzytelnione żądania API to najczęstszy powód przekroczeń — szczególnie w skryptach pisanych „na szybko" gdzie token nie był potrzebny. Po 19 października każde takie żądanie ma limit 60/godzinę.

Dla pipeline'ów GitLab CI — używaj wbudowanego CI_JOB_TOKEN zamiast prywatnych tokenów:

yaml

# Zamiast hardkodowanego tokenu
script:
  - curl --header "PRIVATE-TOKEN: $MY_TOKEN" "https://gitlab.com/api/v4/projects"

# Używaj CI_JOB_TOKEN
script:
  - curl --header "JOB-TOKEN: $CI_JOB_TOKEN" "https://gitlab.com/api/v4/projects"

2. Zaimplementuj obsługę błędu 429

Przekroczenie limitu zwraca HTTP 429 z nagłówkami Retry-After i RateLimit-*.

Każdy skrypt lub narzędzie wywołujące API GitLab powinno obsługiwać 429 z exponential backoff:

python

import time
import requests

def gitlab_api_call(url, headers, max_retries=5):
    for attempt in range(max_retries):
        response = requests.get(url, headers=headers)
        if response.status_code == 429:
            retry_after = int(response.headers.get('Retry-After', 60))
            print(f"Rate limit hit. Retrying after {retry_after}s")
            time.sleep(retry_after)
            continue
        return response
    raise Exception("Max retries exceeded")

3. Ogranicz niepotrzebne odpytywanie

GitLab zaleca buforowanie często żądanych danych, wsadowe wykonywanie operacji API i ograniczenie zbędnego pollingu, by pozostać poniżej progów.

Konkretne wzorce dla pipeline'ów CI/CD:

Buforowanie stanu zamiast pollingu — zamiast odpytywać status MR co 30 sekund, używaj webhooków GitLab do otrzymywania powiadomień przy zmianie stanu.

Stronicowanie zamiast wielokrotnych żądań — API GitLab obsługuje paginację przez nagłówki X-Next-Page i X-Total-Pages. Pobieraj dane strona po stronie zamiast wysyłać osobne żądanie dla każdego obiektu.

Wsadowe operacje GraphQL — GitLab API obsługuje GraphQL, który pozwala pobrać wiele zasobów w jednym żądaniu zamiast N oddzielnych wywołań REST.

4. Monitoruj użycie przed 19 października

GitLab zapowiedział panel monitorowania zużycia limitów — sprawdź czy jest już dostępny dla Twojego konta pod gitlab.com → Usage Quotas → API Usage.

Alternatywnie: przejrzyj logi pipeline'ów CI/CD z ostatnich 30 dni pod kątem liczby wywołań API i zidentyfikuj które joby generują największy ruch.

Co z agentami AI i narzędziami automatyzacji

To najistotniejszy aspekt tej zmiany z perspektywy 2026 roku.

GitLab powiedział wprost: głównym powodem zmiany jest rosnący ruch od agentów AI. Jeden agent kodowania może wygenerować w ciągu godziny więcej żądań API niż ludzki deweloper w ciągu tygodnia — sprawdzając statusy pipeline'ów, pobierając konfiguracje, tworząc komentarze i analizując kod.

GitLab planuje w przyszłości płatny dodatek pojemnościowy powyżej limitów planu — co sugeruje, że organizacje z intensywnym użyciem agentów AI będą miały dedykowaną ścieżkę dla większych limitów, choć szczegóły nie zostały jeszcze ogłoszone.

Dla środowisk z Claude Code, Cursor, GitHub Copilot lub własnymi agentami integrującymi się z GitLab API przez MCP — upewnij się że:

• Agent używa dedykowanego service account z tokenem dostępu (nie konta osobistego)
• Token ma minimalny wymagany zakres uprawnień
• Agent implementuje backoff przy 429
• Operacje są grupowane tam gdzie to możliwe

Harmonogram działań

Przed 7 października (już teraz): Zinwentaryzuj skrypty i narzędzia wywołujące GitLab API — sprawdź czy używają uwierzytelnienia.

7 i 14 października (15:00–19:00 UTC): Monitoruj pipeline'y podczas brownout windows — błędy 429 to sygnał do naprawy.

Do 18 października: Wdróż poprawki dla wszystkich narzędzi, które wystąpiły z problemami podczas brownout.

19 października: Nowe limity wchodzą w życie dla Free i nieuwierzytelnionych żądań.

Styczeń 2027: Nowe limity dla Premium i Ultimate — zaplanuj rewizję dla tego poziomu.

Podsumowanie

Zmiana GitLab.com jest w dużej mierze przezroczysta dla standardowego użycia — GitLab twierdzi że niemal wszyscy obecni użytkownicy nie przekraczają nowych limitów. Ryzyko koncentruje się w dwóch scenariuszach: nieuwierzytelnione żądania (drastyczny limit 60/godzinę) i intensywne automatyzacje na kontach Free z agentami AI.

Dwa tygodnie do 19 października to wystarczający czas na inwentaryzację i poprawki — szczególnie że brownout windows 7 i 14 października dają możliwość przetestowania przed właściwym wdrożeniem.

Źródła: GitLab Blog — „Rate limits on GitLab.com are changing" (17 września 2026), WorkOS Blog, daily.dev, npmx.dev GitHub Issues