GitLab.com siết rate limit theo subscription từ 19/10

GitLab vừa thông báo sẽ gắn rate limit trên GitLab.com theo đúng subscription tier của người dùng. Ai đang chạy automation hoặc integration gọi API mà chưa đăng nhập, tháng sau nên kiểm tra lại ngay.

Chuyện gì đang xảy ra

Theo bài blog chính thức công bố ngày 17/9/2026, GitLab.com đang phát triển nhanh và team hạ tầng cần giới hạn tải để tránh một workload nào đó làm chậm cả platform cho người khác. Giải pháp: tách rate limit theo ba tier — Free, Premium, Ultimate — áp riêng cho mỗi user và mỗi top-level group.

Thời điểm hiệu lực chia làm hai giai đoạn:

• 19/10/2026: limit mới áp dụng cho tài khoản Free và mọi request chưa xác thực
• Tháng 1/2027: limit mới áp dụng cho Premium và Ultimate

Request không kèm credential nào — dù gọi từ tài khoản trả phí — sẽ bị giới hạn cứng ở 60 request/giờ/địa chỉ IP. Đây là điểm dễ bị bỏ sót nhất: một CI job hay bot chạy background mà quên gắn token vẫn bị tính là anonymous, bất kể plan đang dùng là gì.

So what — ảnh hưởng gì tới developer?

GitLab đưa ra hai lần "brownout" — cửa sổ preview ngắn để cho thấy hành vi thật dưới limit mới — vào 7/10 và 14/10, từ 15:00 đến 19:00 UTC. Trong khung giờ này limit mới được bật tạm thời rồi tắt lại, không ảnh hưởng gì khác ngoài rate limit. Đây là cơ hội để team test workload thật trước khi limit chính thức có hiệu lực, thay vì đợi ngày 19/10 mới biết có bị chặn hay không.

Khi vượt limit, response trả về HTTP 429 kèm header Retry-After — client đọc header này để tự backoff thì phần lớn sẽ tự phục hồi, không cần can thiệp thủ công. Nhưng retry ngay lập tức hoặc polling liên tục trong loop là cách nhanh nhất để đốt hết allowance.

Ba việc nên làm trước 19/10:

• Xác thực mọi request: personal access token, OAuth token, hoặc CI/CD job token đều đưa request ra khỏi mức 60/giờ anonymous, chuyển sang limit theo plan — cao hơn đáng kể
• Batch và cache: polling liên tục trong tight loop là nguyên nhân phổ biến nhất khiến automation chạm limit trước cả người dùng thật
• Theo dõi header RateLimit-Remaining trên response để biết còn bao nhiêu allowance trong window hiện tại

Điều không đổi

GitLab nói rõ: đây chỉ là thay đổi trên GitLab.com (SaaS). GitLab Self-Managed và GitLab Dedicated không bị ảnh hưởng — limit vẫn do người vận hành tự quyết. Việc truy cập và export dữ liệu, repository của người dùng cũng không bị giới hạn thêm.

Với project public có traffic lớn từ nguồn ẩn danh, GitLab gợi ý ba hướng. Một là yêu cầu automation gọi vào project đăng nhập. Hai là chuyển project sang private nếu traffic không phải từ đúng đối tượng mong muốn. Ba là upgrade lên Premium/Ultimate để có limit cao hơn nhiều. Có cả kế hoạch bán thêm capacity vượt limit chuẩn, dự kiến chi tiết công bố cuối năm nay.

Điểm đáng chú ý: mức limit ở tier Free được GitLab mô tả là "khớp chuẩn ngành", còn Premium/Ultimate được đặt ở mức mà nhiều platform khác chỉ dành riêng cho enterprise hoặc không công khai. Nói cách khác, đây không chỉ là siết chặt — với ai đã trả phí, limit thực ra rộng hơn mặt bằng chung.

Điều cần biết

• Rate limit mới có hiệu lực từ 19/10/2026 (Free + anonymous) và tháng 1/2027 (Premium/Ultimate)
• Request chưa xác thực chỉ còn 60/giờ/IP, kể cả từ tài khoản trả phí
• Hai cửa sổ preview 7/10 và 14/10 (15:00-19:00 UTC) để test trước
• HTTP 429 + Retry-After khi vượt limit — client biết tự backoff sẽ tự phục hồi
• Chỉ ảnh hưởng GitLab.com — Self-Managed/Dedicated không đổi

Việc siết rate limit theo subscription không phải chuyện riêng của GitLab. Đây là hướng chung khi các platform DevOps ngày càng phải gánh thêm workload từ agent và automation tự động gọi API liên tục, không còn chỉ là con người click chuột. Ai còn để integration chạy anonymous nên coi đây là lời nhắc: xác thực request không còn là optional.

---

Bài viết được hỗ trợ bởi AI (Amy 🌸). Nội dung đã được kiểm duyệt bởi tác giả.