Who Owns Your Uptime? GitLab.com vs. Self-Managed

Availability gets discussed as if it were a property of the vendor. It’s usually a question of who holds the levers when something breaks, and the answer changes completely depending on how you deploy GitLab.

On GitLab.com, availability is someone else’s job

That is mostly good news. GitLab runs a dedicated infrastructure team, publishes its incident history openly, and operates at a scale most internal platform teams will never match. You get that expertise without hiring for it.

The tradeoff is that you have no levers. During an incident, your options are refreshing the status page and telling your team to wait. You can’t roll back a deployment, fail over to another region, or prioritize what gets fixed first. For most organizations that tradeoff is worth it because the alternative is worse. It should, however, be a decision rather than a default.

Self-managed GitLab inverts the equation

Run GitLab yourself and uptime becomes a function of your architecture. A well-designed deployment with redundancy at every layer can exceed what any multi-tenant SaaS will commit to, but you also have to put the work in to build and maintain that architechture.

This is where teams run into trouble. A true high-availability deployment is more than a single-node GitLab instance on one VM with nightly backups. That is a single point of failure with a recovery time measured in hours, and it is almost certainly less reliable than GitLab.com. Plenty of organizations run exactly that though and describe it as self-managed for control. They may have the control, but they don’t have the availability.

What actually separates the two:

• Gitaly Cluster for fault-tolerant Git storage with configurable replication
• A PostgreSQL high-availability setup, typically Patroni, so a database failure doesn’t take the instance down
• Multiple Sidekiq nodes so background job processing survives the loss of a host
• GitLab Geo for disaster recovery and regional failover
• Monitoring that alerts before users notice, and a restore process someone has actually tested this year

It’s worth noting that several of these are tier-gated. Fault-tolerant PostgreSQL, disaster recovery, and 24/7 uptime support sit in paid tiers, which means your architecture and license are related decisions instead of separate ones.

GitLab Dedicated sits in the middle

GitLab Dedicated is single-tenant SaaS operated by GitLab. You get data isolation and some deployment control without owning the infrastructure or staffing the on-call rotation. It is often the right answer for regulated organizations that need residency guarantees but don’t want to build an HA deployment from scratch.

The question to actually ask

Ask what your recovery time objective is, whether anyone has tested a restore in the last six months, and who gets paged at 2am when Git operations start failing. Most availability problems are answered by those three questions rather than by the deployment model.

If you want help sizing an HA architecture, reviewing a deployment you already run, or working out which model fits your requirements, reach out to us. We do this across commercial and federal environments.