The decision between GitLab.com and a self-hosted GitLab is usually framed as convenience against control. For a growing team it is also a spreadsheet, because the two options bill in completely different units: one per seat and per compute minute, the other per hour of infrastructure. This post walks through that spreadsheet with a CTO who ran it for a 40-developer team on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.
The company is a fintech we will call Meridian Ledger, with 40 developers, two large monorepos, roughly 900 pipeline runs a week and a regulator who has started asking where the source code of its payment engine is stored. The alternative under evaluation is the DevOps Lab - GitLab Server package: GitLab CE with a container registry and auto-scaling runners on a European PaaS region.
What GitLab.com charges for
GitLab.com's paid tiers are priced per user per month, billed annually, and the features Meridian needs, merge request approvals rules, protected environments and code owners, sit in the Premium tier. Every developer, and every non-developer who needs to comment on an issue, is a seat. On top of seats, the hosted runners are metered in compute minutes with a monthly quota per tier and paid packs beyond it, and the container registry and artifact storage have a quota per namespace with paid extra storage.
The CTO's honest reading of a year of usage: 40 developer seats plus 8 product and QA seats; around 30,000 compute minutes a month on the hosted runners once the monorepo's test suite is counted; and a registry that accumulated several hundred gigabytes of per-commit images because nobody had set an expiry policy. None of these numbers is unusual for a team this size.
What the self-hosted option charges for
GitLab Community Edition has no licence fee and no seat count. The cost is the infrastructure: one server node that runs GitLab CE, its bundled PostgreSQL and Redis and the registry, and a runner layer that scales out during working hours and back to one node overnight. On MassiveGRID PaaS both are billed in cloudlet-hours (a cloudlet is 128 MiB of RAM and 400 MHz of CPU), with vertical scaling allocating what each container actually uses each hour.
| Component | Sizing | Monthly average | Cost before discounts |
|---|---|---|---|
| GitLab CE server node | Limit 64 cloudlets (8 GiB) | About 44 cloudlets/hour | About $108 |
| Runner layer (1 to 6 nodes) | 16 cloudlets each | About 30 cloudlets/hour across the day | About $74 |
| Registry and repository disk | 400 GB with weekly garbage collection | Disk charge | Per GB, small relative to compute |
| Public IP for the custom domain | 1 IPv4, hourly | Fixed | Small fixed line |
Using the published rate of $0.003372 per cloudlet-hour, the compute totals under $200 a month before the account's automatic volume discounts. There is no seat count in the table, which is the structural difference: adding the ninth QA engineer, or the contractor who joins for a quarter, costs nothing.
The features question, answered honestly
Self-hosting CE does not give you Premium features for free. Merge request approval rules beyond the basic form, code owners enforcement and protected environments are paid features on self-managed GitLab too, licensed per user. Meridian's CTO priced that as well: a self-managed Premium licence for 48 users costs the same per seat as GitLab.com Premium, minus the hosted compute minutes and storage, plus the infrastructure above. If the team truly needs those features, the saving from self-hosting is the metered compute and storage and the ability to run the free CE for everyone who only reads and comments.
In Meridian's case the team decided that CE's built-in approvals, protected branches and merge request settings covered its actual workflow, and that the approval-rule granularity it was paying for had been used twice. Your answer may differ, and the exercise is worth doing feature by feature.
The residency question, which has no price
The regulator's question was where the payment engine's source lives and who can reach it. On GitLab.com the answer is a hosted service with its own data-location commitments. On the PaaS the answer is a specific region, Frankfurt or London in Meridian's shortlist, an environment on an account the company controls, a container firewall that exposes only 443 and the SSH port GitLab needs, and an ISO 9001-certified provider under GDPR. The CTO could also put the GitLab environment in an isolated environment group, so no other environment on the account, including staging clones, can reach it over the internal network.
Two platform features made the compliance annex short. Environment export produces a portable copy of the whole environment's topology and data, which answered the exit-strategy question. And the platform's statistics and billing history per environment gave the finance team a monthly cost per system without a spreadsheet.
The operational cost nobody puts in the spreadsheet
Self-hosting has a labour cost, and pretending otherwise is how these decisions go wrong. Meridian's CTO budgeted it as follows: one monthly upgrade using the package's Update GitLab Server add-on, rehearsed on a cloned environment the day before; a weekly registry cleanup job; and a backup routine that runs GitLab's own backup task nightly to a backup storage node. The platform removes the parts that usually eat the time, because containers redeploy in place with data preserved, the runner layer needs no hands at all, and load alerts arrive by email before anything is slow. The CTO's estimate was two to four hours a month of a senior engineer's time, and after six months the actual figure was closer to two.
The decision
Meridian moved to self-hosted GitLab CE on the Frankfurt region, kept a GitLab.com free namespace for its two open-source libraries, and reassessed the Premium question after a quarter. The direct saving was the seat and compute-minute bill against under $200 a month of infrastructure. The larger gain was an answer to the regulator that fits on one page.
Frequently Asked Questions
Can I migrate my GitLab.com projects to the self-hosted server with history?
Yes. GitLab's direct transfer migration moves groups and projects between instances, including issues, merge requests and pipeline history, and repository import by URL works for the Git data alone. Run the migration into a cloned test environment first to check the mapping of users.
Does the self-hosted server support GitLab Pages, the container registry and the package registry?
The package installs GitLab CE with the container registry enabled. GitLab Pages and the package registry are features of GitLab CE and can be enabled in the server's configuration; Pages needs a wildcard DNS record and its own certificate handling.
What if the team grows to 200 developers?
GitLab's reference architectures scale the omnibus server vertically well past that size, and on the platform that means raising the node's cloudlet limit. The runner layer's maximum node count is raised in the scaling trigger. When a single-node GitLab is no longer appropriate, GitLab's own guidance on separating PostgreSQL, Redis and Gitaly applies, and each can be a separate node in the same environment.
Know where your source code lives
Deploy GitLab CE with a container registry and auto-scaling runners in Frankfurt, London, New York or Singapore on MassiveGRID PaaS. No seats, no metered minutes, pay per cloudlet-hour. Free 14-day trial, no credit card.
GitLab Server on MassiveGRID PaaS