Git is decentralized by design, yet most organizations have funneled their entire source of truth (repositories, CI triggers, access control, release tooling) onto one third-party platform that nobody on the team operates or can inspect. That concentration was a fair trade when self-hosting meant adding massive capex overhead, but with modern architectures and platforms, that's no longer the case.
As much as they probably deserve it lately, none of this is an argument against GitHub or any other provider directly. The major hosts are, historically, well-run. Plenty of teams are still in a position where SaaS based version control is the right choice.
What we are looking at today is the current form of the argument for keeping control over the one asset you can least afford to rent, your code, and the daily flow built on top of it. And a lot of this has to do with the fact that it's now possible to hold that control without the operational tax that used to come with it. That's the case for staying in-house, from a team that's been doing it for over a decade.
We don't hand our source code to a platform we can't audit
When you push to a SaaS host, your source code comes to rest inside a multi-tenant platform you cannot audit. Their security team is bigger than yours, and that still isn't the same as your code being safe by default.
Even world-class organizations get hit. GitHub has disclosed leaked OAuth tokens used to clone private repositories. The ecosystem absorbs dependency and supply-chain compromises that reach straight into CI. And in a single year, tens of millions of new secrets leaked into public repositories. Objectively, this is just the shape of the surface: provider employees and support tooling, every OAuth app in the marketplace, shared multi-tenant infrastructure, and public ingress that the whole internet can reach.
If a provider with a world-class security org still gets breached, "they're better at this than us" is not the same as "your code is safe by default."
Self-hosting moves the boundary inside your perimeter, behind your IdP and your segmentation, and you decide whether it faces the internet at all. For example, many orgs, ours included, that self -host only expose their source control over VPN.
Does your outage have options?
The Git host sits on the critical path of nearly everything: clone, fetch, push, pull requests, CI. When it stalls, most of engineering stalls with it.
Picture it mid-deploy, when the host's API starts throwing intermittent 500s. Runners can't fetch refs, the merge train stalls, and the release window slips. Nothing in your runbook covers it, because the broken part isn't yours. Every lever that would fix it sits behind someone else's support queue. There's no postmortem coming, just a status page you keep reloading.
Self-hosting won't make outages disappear. You'll have your own bad days: hardware fails, a network link flaps, a disk fills up mid-release. The difference is whether you can do anything but wait. Self-hosting exposes more control over uptime, latency, and capacity. Runners live on the same network as the endpoint and can be tuned to accommodate your own peak. When something breaks, you can actually dig in and fix it, instead of reloading a dashboard until someone else gets to it.
A word from our Head of Engineering
By self-hosting our own instance of GitLab, we're able to secure it behind our company networks, have more control over dependency management, and utilize powerful bare metal for all of our build systems. Together, this gives us real peace of mind that we're fully in control of our codebases and intellectual property. Paired with Cycle, the operational burden drops to almost nothing.
Is Sovereignty A Second Job?
Historically, the most reasonable objection to all this "self-hosting" is "who's going to do all the work?" And that just shows that it's always been operational, not philosophical.
However, the last few years have shown us that data sovereignty is starting to become more of a requirement.
- Tightening data-sovereignty rules in the EU
- More teams moving to private cloud
- The return to bare metal
Nonetheless, this layer of control also brings with it:
- servers to patch
- backups to verify
- storage to grow
- an upgrade treadmill that breaks integrations on its own schedule
- HA stories you design and test yourself
Those pieces can be real enough that handing the work to SaaS is absolutely the right choice for some organizations. But (and it's quite a big BUT) the combination of better software distribution (especially through containers), more mature documentation for leading self-hosted providers, and new PaaS offerings that reduce the workload on the DevOps side has changed that landscape dramatically.
Cycle is a great example here. Deploying something like Gitlab into infrastructure you already control becomes much simpler.
With a bring your own infrastructure approach, self-hosting can be on your cloud accounts or bare metal, and it runs upgrades, scheduled backups, scaling, and HA as platform behavior instead of runbooks you maintain by hand. Private networking can keep the Git endpoint off the public internet, and setting up VPN only access is straight forward.
So What about Cycle Itself?
Yes, Cycle is a hosted control plane.
But look at where the dependency actually sits. Your repositories live on your own servers and never touch our control plane. When you run GitLab on Cycle, we orchestrate it without ever sitting in the path of your code. If our control plane has a bad day, your Git keeps serving, because a server that can't reach the Cycle control plane just holds its last known good state. What you trade is the ability to make changes until we're back. Your uptime holds, and your code is never exposed.
We didn't eliminate the dependency. We shrank it to the one thing that can fail without taking you down. The best mental model is self-hosted instead of self-operated and you still own the data plane, while we operate the control plane.
If you're interested in a deeper dive into our methodology and intent, check out our official manifesto.
Get started
Git was built to be distributed. The only thing that ever forced it onto someone else's box was the operational tax, and that's the part that changed.
If you're interested in exploring more on this topic, you can get started with the following resources:
- The Self-Hosting GitLab on Cycle guide, step by step.
- The platform-agnostic Learn article on self-hosted GitLab.
- Bring your own self-hosted runners and run builds on bare metal next to your code.