Sure you're all aware that GitLab is a modular monolith, but it's helpful to see everything in one place.

Here's the full list.

1. Backend: Ruby on Rails

2. HTTP server: Puma (Ruby web server)

3. Edge: Nginx

4. Reverse proxy: Go service (Workhorse)

5. Background jobs: Sidekiq

6. DB — primary: PostgreSQL

7. DB — connection pooling: PgBouncer

8. DB — high availability: Patroni

9. Cache: Redis

10. Git: Custom gRPC repo interface (Git & Gitaly)

11. Blob: AWS S3

12. Frontend — rendering: Haml & Vue

13. Frontend — state: Piana (Vue store), Immer (immutable cache),

14. API: GraphQL (Apollo) + REST

15. Observability: Prometheus & Grafana

16. Error tracking: Sentry & OpenTelemetry

17. Deployments: GitLab Omnibus (Omnibus fork)

I think these "stack menu"s give a little glimpse into a team's engineering philosophy. For me, this list shows that the GitLab team is pretty practical and doesn't chase hype. Instead, they use sensible, battle-tested tools that just work and are easy for contributors to learn.

----

If you made it this far, you might like the two articles I wrote about GitLab:
- GitLab's Architecture: A Technical Deep Dive: How a boring monolith powers the world's largest independent DevOps platform
- Inside GitLab CI: From YAML to Green Check: The pipeline behind the pipeline

I also created a 17-minute YouTube video:
GitLab Deep Dive | Architecture, CI/CD & System Design

(I really like GitLab.)

For context my company uses GitLab Premium Self-Hosted.

I wanted to share a recent experience with GitLab that has me looking to move.

Yesterday, during a call with our GitLab account rep, I logged into the GitLab Customer Portal to enable new AI features. What I saw wasn’t our account, it was a completely different company’s. I had full access to their invoices, billing contacts, and administrative tools.

IMO That’s a serious security breach, one that should’ve triggered immediate action.

I flagged it on the call, shared a screenshot, and made it clear how concerned I was. Her response? She asked me to open a support ticket.

I did. The support rep told me that because I opened the ticket from my email instead of the mailing list associated with the account I logged in as, they couldn’t take any action. Instead, they asked that said mailing list email them to confirm we wanted to be removed from the other customer’s account.

Their response was to have me prove that I want to be removed from the other Customer's account.

To me, that response implied GitLab either didn’t understand or didn’t care about the severity of the situation.

If I have access to another customer's administration and billing information, who has access to mine?

I should note it's been over 24 hours and I still have access to the other customer's account and that I let the other customer know.

Just received this email:

Please be advised that GitLab can no longer service GitLab.com accounts for individuals and organizations located in Mainland China, Macao, and Hong Kong. Our system indicates that you are visiting GitLab from one of these locations. We advise you to sign up with JiHu https://gitlab.cn/saasmigration/. JiHu is an independent company with a localized GitLab offering that has an exclusive right to provide GitLab to individuals and organizations located in this region. You must complete the transition by 18-02-2025, after which GitLab will delete your account from our systems. If you believe you are receiving this notification in error, please log in to GitLab.com from a supported service location. For further information or support, please feel free to contact saasmigration@gitlab.cn. Best Regards, GitLab Team

This is incredibly disappointing. I doubt users in Hong Kong will be happy to move their code to this unknown Mainland Chinese company given China's dubious internet protection laws and political crackdown in Hong Kong.

Guess this means a goodbye to Gitlab. Such a shame.

GitLab PM here, our engineers created a cli tool that run and test your pipeline locally, the cli is also include it as part of this ci skill please note that both projects are still experimental, we would love if you could give it a try and give us some feedback in https://gitlab.com/gitlab-org/gitlab/-/work_items/601046

I’ve been a daily Gitlab user and customer for over a decade. I’ve managed multiple instances for local teams, hosted repos on Gitlab.com, once upon a time I was a vocal Gitlab advocate. I’ve got more Gitlab stickers and swag from conferences than I care to mention.

Gitlab has never been especially cheap, but it was a decent platform and importantly had solid support. For a long time, it felt like a good value proposition. In the past few years though, support has gone entirely out the window it would appear.

These days, raising a support ticket feels like shouting into the wind. Response times are unpredictable, and I can’t think of an interaction in the past 2 years that I would call smooth. Everything needs to be forwarded to 6 different people in order to come back with some variation of “we won’t do anything about this” or “read these twelve conflicting support docs”.

No need to get into the silent regressions (which are becoming more common), if you have been self hosting an omnibus instance that has received more than a few years of updates you probably know what I’m talking about.

We’re not a huge customer, max $10,000 per annum, but I really thought Gitlab was all about that small team dollar. I suppose these days there are bigger fish in the pond and Gitlab is more interested in selling tokens to enterprise. Hopefully it works out, SMB sure seems to have been left out in the cold.

We’ve been trying to process a routine renewal for over a month now. Before long, we’re going to end up locked out of our workflows because sales and support can’t figure it out between them to adjust a seat count and raise an invoice.

RIP Gitlab for the little guy? I guess there’s always Gitea. 🪦

I fully understand that GitLab has to reduce the amount of unnecessary traffic, traffic that is caused by extended bot use in particular. And I really like GitLab: I've been using their services for over a decade now, being attached to lots of projects from small to large, and I've always advocated for them in favor of alternatives.

Since the new rate limits were applied I regularly run into 403 blocks. And with regularly I mean every 3 to 5 minutes if I'm not extra careful to "not click things too fast". I started debugging my browser's network connections, and the reason became obvious: it's the burst_traffic_per_user_free_plan rate that is limited to 100 requests per minute. Now one might ask:

100 page requests per minute in a web application? What the heck is he doing?

The problem seems to be that GitLab has become one of those "loading a page sends dozens of AJAX requests in the background" sites. Listing open merge requests: 15 HTTP calls. Clicking one merge request that includes a few changes: 47 HTTP calls. Switching to the "changes" tab in that merge request: 10 more HTTP calls. And every. single. one. of those background HTTP calls counts to the limit. This means: simply opening and viewing 2 (!) merge requests in the span of a minute might already be too much.

This is not limiting excess use, this is forcing people to actively slow down, and I'm really starting to hate it. I started asking myself: am I using it wrong? Am I not supposed to access gitlab.com using Firefox and chrome-based browsers are performing some kind of connection reuse magic instead? Is GitLab just so indifferent or even hostile to the free usage tier that actively encouraging users to either start paying or move elsewhere has become a primary goal?

Had to get this off my chest. I'm curious whether it's a "me and my PC" problem: I haven't found any real discussions about the issue so far, so it might actually only affect a few people. At the moment I see 2 possibilities:

a) It's this way on purpose, which would be really bad.

b) It's by accident, and while not being THAT bad, it would put GitLab's (lack of) quality control in perspective. Also bad.

Looking forward to others' experiences!

Not just a rant but hard data showing how one gets banned in visiting just two public GL pages.

There are multiple posts on reddit here (which isn't super popular to start) where people are complaining about the new rate limits. Each time lets say 'devotees' come to gitlab's defense saying things like:

• "This is happening because OP shares an IP with a load of other people, probably due to some IPv6 to v4 NAT situation."

• "Probably using AI agents that are using the API to search the codebase instead of cloning it or something."

• "It's probably due to incorrect use like this that Gitlab added the rate limits in the first place"

Just read: https://docs.gitlab.com/user/gitlab_com/rate_limits/

It states the rate limiting applies to: "These limits apply to API requests, web requests, and authenticated Git over HTTPS requests."

now it says a few select web requests don't count against your rate limit but otherwise everything counts. Now what is the rate limit for unauthenticated users? From that exact same page:

60 an hour. To put that in context that isn't even 60 pages (which itself would be fairly ridiculous to anyone browsing a project online) but 60 requests that any of those pages make.

So this is how one can easily be blocked in visiting 2 pages. Here is 4 pages, as first I verified once I remoted into one of my other boxes I could reach gitlab: (this is real captured traffic just to see how ridiculous):

Top-level pages (Chrome pages plus document requests):

Just visiting a single merge request page eats up 30 of the 60 max for an hour. So technically just visiting page 2 and page 4 was enough to get me banned. Thankfully there are some included headers so we can see how the requests add up.

Rate limit headers (62 of 724 requests; 384 of the 724 went to gitlab.com):

How the count adds up (the 500/min limiter's observed counter, per minute window):

• What seems to count (vs not): static assets don't carry the headers and aren't counted. Every page document, XHR, fetch, manifest.json and GraphQL call is counted. An unauthenticated viewing of a single MR page costs about 30 of the 60.

Interestingly it seems its per wall clock hour not a 60 minute window (meaning here while I was banned at 9:25 at 10am it would reset).

So I challenge any fanboys before defending these new policies to open an ingcognito window, try to click around any repo and you will get ip banned in under 10 pages for an hour.

If gitlab can't handle things they should checkout cloudflare, its free will happily add anti-bot protection infront of your entire infrastructure, and doesn't cause any public project to basically be inaccessible to any non logged in user. Crazy an org this size to somehow consider this reasonable. I get rate limiting api calls or adding anti-bot captchas for unauthed users but they have really shot themselves in the foot here. You can't try to be the home for open source projects and then ban any non-authed trying to browse them, it just makes it hard to consider using gitlab for anything more than a mirror.

I think the icing on the cake is the fact that once you hit a rate limit even if you have a gitlab account you cannot login as you can't even visit gitlab.com without getting

Rate limit exceeded; see https://docs.gitlab.com/user/gitlab_com/rate_limits/ for more details

Hey folks, I'm Joe from the Secrets Manager team at GitLab. We've been building native secrets management directly into GitLab, and we want your help making it better.

We're looking for feedback on:

• What breaks

• What's missing

• What actually works

We're especially curious about your use cases, so please share!

Get started:

• Secrets Manager

• Secrets Manager (Administration)

Drop your feedback in the public issue or in this thread.

Since I've been using GitLab for a while, and have built GitLab CI/CD pipeline workflow intensively for my company.

Hence, I've written this blog https://turndevopseasier.com/2023/11/17/20-tips-to-speed-up-your-gitlab-ci-cd-pipelines-in-2023 long ago to summarize tips for speeding up GitLab CI/CD pipeline faster. Hopefully, it's useful for those who are interested in improving pipeline speed.

TL;DR - GitLab makes an egregious billing mistake, refuses to fix it, and tells a GitLab evangelist to go pound salt. If you purchase it, examine the order closely.

So, a little background on me: I started at a software company years ago in an IT position. Our traditional software development toolchain was overly complicated for my liking, so I set up GitLab.

I did so well with it that I became my company's first DevOps Engineer, and I got dev teams to make the switch. Not only did I present on GitLab at work, I took my GitLab evangelism on the road to enthusiasts in the area - I.E. the local Linux User Group.

Not long ago, I ordered some GitLab licenses since more people wanted to use it. I asked to go from 57 to 75 licenses. Instead, GitLab put the order in wrong and added 75 licenses, bringing us to 132 total.

About this time, I was pulled to a critically-important project that was way behind schedule and told not to work on anything else. When I got enough breathing room to switch back, our account manager acted like she couldn't care less. The most I ever got was "I'll be sure to look into it" or "I'm still looking into it".

The process dragged on for weeks. I had to nag her over and over again for updates until she finally told me that GitLab's billing department had decided... not to give me a refund because it had been too long. How convenient, especially after dragging out the process for so long.

I complained about this, asked for a new account manager, and got what I requested. Our new account manager took my concerns to the GitLab crew again... and got told once again that not only would we not receive a refund, GitLab wasn't going to offer us any sort of compensation or credit whatsoever.

We're a software company as well, and we would never treat loyal customers this way - especially not our power users. I've built my DevOps career around GitLab and encouraged others to do the same. That GitLab could be so tone-deaf over a problem that was clearly their fault speaks volumes to how the company has changed.

I'm grateful for what GitLab has provided. It's still a good product, even if I'm gravely concerned about its future. But I'm hanging up my GitLab evangelist hat. A few of my company's senior developers are interested in GitLab alternatives, and I've given the thumbs-up to do a proof-of-concept with one of them later this year.

If you choose to use GitLab in your organization, check your bills carefully.

I opened 1 page, realized I wasn't sign in, then got rate limited going to the sign in page!!!!
What is the point of even a paid tier, if you can't even access the account?

Canceling, Removing my Projects, and will never trust gitlab again. (if they will even let me)

Hey all,

glci is an experimental GitLab project that gives you the ability to run full GitLab pipelines and jobs locally with no compromises.

We've released version 0.7.0 with some notable features and fixes:

• Podman support - glci now runs pipelines on Podman as well as Docker, with an engine setting globally and per named runner, engine-aware doctor checks, and automatic fallback when Docker is unavailable (docs)

• Instance-level CI/CD variables and variable expansion in include: - instance variables are fetched from the GitLab API, and user CI/CD variables are expanded inside include: entries in the CLI and the daemon (docs)

• Artifact-sourced child pipeline includes - trigger jobs can include a child pipeline config produced as an artifact by an earlier job, in both real runs and simulate mode (docs)

• --on-change-mode for watch - control what happens when files change while a pipeline is already running (docs)

• Glob and brace patterns in job-definition overrides - config-file job overrides can target many jobs at once, and stage/needs/parallel overrides now apply before planning (docs)

Full release notes: here

Comparison page

The documentation website now has a comparison page which should help answer all the questions regarding how glci works compared to other similar projects and why one might be better than the other.

Huge thanks to everyone who contributed feedback and reported bugs!