I've maintained a self-managed GitLab instance for about three years, mainly because our compliance team would not approve cloud hosting when we originally set it up. Recently, though, runner problems, upgrades, and compatibility issues have started consuming a noticeable part of every sprint. We're not a huge team, so even half a day here and there adds up quickly. How do you decide when the operational cost of self-hosting is higher than the cost of GitLab SaaS? Has anyone made the business case successfully, or found a hybrid setup that satisfied compliance?
4 Answers
Before proposing a migration, track the actual impact for at least a month or two. Record engineer-hours lost to upgrades, failed pipelines, runner outages, backups, troubleshooting, and routine administration, then multiply that by your loaded labor cost. Compare the result with SaaS licensing, migration effort, temporary overlap costs, and any remaining self-hosted runner infrastructure. A concrete statement like “we lost X hours and Y dollars over two sprints” is much easier for management and compliance to evaluate than a general feeling that the platform is painful.
Separate GitLab itself from the runners. SaaS can remove the maintenance burden for upgrades, backups, database care, authentication plumbing, and general platform administration. It probably will not eliminate runner problems if your runners need private network access, custom images, privileged containers, or special security controls. A SaaS control plane with self-hosted runners is often a good compromise: the source and platform move to the managed service while builds still run inside your network.
That distinction is useful. I had been treating self-hosted GitLab and self-hosted runners as one inseparable decision, but the runner requirements are really a separate compliance and infrastructure question.
Revisit the original compliance decision instead of assuming it still applies unchanged. Ask what the actual blocker is: data residency, audit evidence, access controls, retention, vendor risk, network connectivity, or source code leaving the company. Those requirements may allow a hybrid model, and the available SaaS compliance certifications and controls may be different from when the decision was made. If the concern is specifically sensitive build execution, keeping controlled runners on-prem while using SaaS for repository management may address it without maintaining the entire GitLab platform yourself.
Our main concerns are data residency and audit trails, not anything especially unusual. That makes a hybrid proposal seem much more realistic than I initially thought.
The version-bump failures sound more like a release-management problem than proof that self-hosting is wrong. SaaS removes the GitLab application upgrades, but dependency changes, CI configuration changes, and runner compatibility can still affect you. Pin runner and tool versions, upgrade incrementally, read the release notes, test changes before rollout, and use shared pipeline templates so teams aren’t maintaining dozens of slightly different configurations. Runner fleets should also be drained or paused before upgrades so active jobs are not abruptly terminated.
We’ve had good results with automated upgrade proposals and a regular cadence instead of letting several major versions accumulate. Smaller, frequent changes are much easier to troubleshoot than a large jump.
This is exactly what I was missing. I’ve been estimating based on memory instead of logging the outages and maintenance time, so I’m going to start tracking it properly.