Experiences Are Not Transferable
Unfortunately for DevOps Sales Decks
Experiences are not transferable between people. If they were, we’d have far fewer Medium posts and far more vacations. Still, we keep pretending that someone else’s tooling success story will magically become ours if we just copy the stack hard enough.
It’s been a long time since most of us kept source code locally. That era died somewhere between works on my machine and please don’t touch that folder. As soon as teamwork entered the room, version control became unavoidable. We started with Subversion, learned some lessons and eventually almost everyone landed on Git.
Git is solid. Git is boring. Git is the bone.
But bones don’t move by themselves. You need flesh, muscles, and unfortunately, a nervous system that doesn’t randomly decide to take a nap mid-sprint.
Over the years, the ecosystem around Git narrowed itself to a few dominant platforms—mainly GitHub and GitLab. When we founded cybros labs, we did what most teams do: we talked about it, argued about it, benchmarked feelings rather than facts, and chose GitHub. Not because it was perfect, but because it was the default. And defaults are powerful.
CI: Where Theory Goes to Die
Fast-forward a few months. Our setup grew teeth: extensive CI pipelines, self-hosted runners, aggressive caching, and enough YAML to qualify as a soft skill. The goal was simple—CI should be infrastructure, not a bottleneck.
That’s when things started to smell funny.
Over the last year, it became clear we were on the wrong platform. And no, we’re not unique snowflakes. Others noticed too—see Zig’s very polite but very clear migration story away from GitHub.
The Problem Isn’t That GitHub CI Is Bad
The problem is that it’s unpredictable.
Sometimes pipelines are fast. Sometimes they crawl. Sometimes they freeze entirely, stare into the void for hours, and then expire—accomplishing nothing except billing you for the privilege. That’s not cloud reliability. That’s a slot machine with YAML syntax.
And when I say random, I mean algorithmically mysterious. Like this recently-infamous safe_sleep.sh "algorithm"—which essentially boiled down to "wait and hope". It lived there for years. In production. On a paid platform. Cool.
It’s always comforting to know exactly what you’re paying for—especially when the answer is "we’re not entirely sure either."
Self-Hosted Runners: Congratulations, You’re the CDN Now
Self-hosted runners were supposed to fix things. In practice, they introduced a new hobby: watching massive caches get shipped back and forth between your infrastructure and GitHub’s servers. Over. And over. And over.
You pay for compute. You pay for bandwidth. You pay in time.
And sometimes you pay by re-running the same pipeline three times because this one feels luckier.
That’s not DevOps. That’s superstition.
The Exit
So yes—farewell GitHub.
Not dramatically. Not emotionally. Just pragmatically.
We moved to GitLab, an old friend that may not win popularity contests but at least behaves like it understands what CI is supposed to do: run, finish, and not surprise you.
GitLab isn’t perfect. But it’s predictable. And in infrastructure, predictability beats charm every time.
Final Thought
GitHub is still fine—for many people, many projects, many scales. But once CI becomes mission-critical, fine stops being good enough.