What is GitLab?
GitLab is a development platform built around a git repository. The repository is the part everyone recognizes, but it is the smaller half: GitLab also carries issue tracking and planning, merge requests and code review, a CI/CD engine, a container registry, security scanning, and release and deployment tooling, in one application with one permission model.
GitLab calls this a DevSecOps platform. The phrase is the vendor's own and explains little on its own, but it is worth recognizing, because it is how GitLab's documentation and sales material describe the thing you are evaluating.
That single-application design is the point of the product. The alternative most organizations are coming from is a repository in one tool, a pipeline runner in a second, a registry in a third and a planning board in a fourth, with four sets of accounts and four places where access has to be revoked when someone leaves.
The AI layer
GitLab's AI features are branded GitLab Duo. Code Suggestions is the part most people meet first, completing code as you type. Around it sits chat, and the Duo Agent Platform, which GitLab describes as agentic AI for the entire software lifecycle rather than assistance inside the editor alone.
Two things about it are worth knowing before it appears on a quote.
It is billed by usage, not by seat. Duo Agent Platform capabilities are charged against GitLab Credits, based on actual usage rather than seat assignments. That is the opposite of how the rest of the license works, and it means the cost is genuinely hard to predict before you have run it for a month.
Self-managed has version floors. Duo Agent Platform needs GitLab 18.8 or later on a self-managed instance, and 18.9 to trial it with credits. If your instance is older, the answer to "can we have the AI features" is an upgrade project first.
The question a self-managed buyer should ask, and it is the one this page cannot answer for you: where the inference runs, and what leaves your network to get there. An organization that chose self-managed so its source code stays in one jurisdiction has the same question about the AI reading that code. Ask it explicitly, in writing, before enabling anything.
The choice that actually matters: SaaS or self-managed
GitLab is available two ways, and this decision has more consequences than which tier you pick.
GitLab.com is the vendor's hosted service. You sign up and use it. GitLab operates the infrastructure and decides when it is upgraded, and your repositories live on their infrastructure under their jurisdiction.
Self-managed is the same application installed on infrastructure you choose: your cloud account, your data center, or a provider you appoint. You decide where it runs, when it is upgraded and who can reach it. You are also responsible for all of that happening.
The commercial tiers (a free tier, and paid tiers adding security, compliance and portfolio capabilities) apply to both, and GitLab has been reworking how the self-managed tiers are packaged, so the current lineup is worth checking against their pricing page rather than any third-party summary, including this one.
When self-managed is the right answer
When the jurisdiction is a requirement, not a preference. Source code is often the most sensitive asset a software organization has, and for regulated Swiss customers "where does it physically sit, and whose law governs the contract" is a question with a required answer rather than a nice-to-have one.
When you need the network boundary. An instance that is only reachable from your own network is achievable with self-managed and not with a shared SaaS tenancy.
When upgrade timing is yours. Self-managed means you choose the window. That is a real advantage for teams with change-freeze periods, and it is also an obligation, which is the next section.
When it is not
A small team with no compliance driver is usually better served by GitLab.com. The hosted service has no server to run, and the effort you would spend operating an instance buys nothing a small team can feel.
"We want to save money" needs the actual numbers. It is sometimes true and often assumed. The GitLab license is a per-user line item either way, quoted separately from whatever you pay to run the instance, so self-managed does not make the per-seat part go away. What changes is the operations side: a flat monthly cost instead of one bundled into a per-seat price.
That flips the arithmetic in one specific case, and it is worth knowing which: a lot of users who each use it lightly. Per-seat pricing charges the same for the person who opens a merge request twice a year as for the one who lives in it, while a flat operations fee does not. The effect is far stronger against per-seat products that bundle everything into the seat, GitHub among them, than against GitLab.com, where the license sits on both sides of the comparison.
So it is a calculation, not a rule: seats, tier, and how much each seat is worth to you, against infrastructure plus the engineering time to run it.
What operating a self-managed instance involves
This is the part that is consistently underestimated, and it is why this site exists.
- Upgrades, on GitLab's cadence and not yours. Releases are frequent, security releases arrive with little notice, and version skips have their own upgrade paths. Falling behind is easy and getting current again is harder than staying current.
- Backups that have been restored. A backup of a GitLab instance covers the database, the repositories, the registry, artifacts and uploads. Whether it works is a question only a restore answers, and the time to find out is not during an incident.
- CI runners. The pipeline capacity is separate infrastructure with its own scaling, isolation and cost behavior. Shared runners are the usual first bottleneck.
- Availability. Every developer stops when the instance stops. Whatever the team's tolerance for that is, it implies a monitoring and on-call arrangement.
- Someone awake for zero-days. Security releases are announced publicly, which means the window between the announcement and the patch is a known window.
The usual failure mode is not a dramatic one. It is a team that installs GitLab in an afternoon, runs it well for six months, and then finds itself four minor versions behind with a backup nobody has tested and no clear owner for either.
Where VSHN fits
VSHN operates dedicated self-managed GitLab instances for Swiss organizations, on Cloudscale, Exoscale or infrastructure you already have, including the upgrades, backups, runners and 24/7 incident response described above. Pricing starts at CHF 360 per month, and our sovereignty assessment covers the jurisdiction question in detail.
If you are still choosing between the hosted service and running your own, the honest comparison is not subscription against server cost. It is subscription against server cost plus the engineering time, and that is worth putting numbers to before deciding.