GitLab cost of ownership and editions

What self-managed GitLab costs over its life

Total cost of ownership for self-managed GitLab has two parts. The subscription is the smaller and more visible one: according to the GitLab pricing page, Free costs 0 US dollars, Premium costs 29 US dollars per user per month billed annually, and Ultimate is custom priced. The larger part is operating cost, which runs whether you pay for a tier or not. It covers servers and storage sized to a reference architecture, runner compute, upgrades, backups, restore testing and the administrator time that keeps all of it current.

Organizations usually start modeling this cost for a specific reason: moving off a SaaS plan, consolidating several self-hosted developer tools, meeting a data residency or air-gap requirement, or facing a per-seat renewal that changes the math. Each trigger changes which costs matter most. A per-seat renewal makes the tier decision central, while a residency requirement makes infrastructure, storage and offline patching the main line items. Write down the trigger first, because it determines which assumptions your model needs to test.

Teams often build the first model in-house, using their user count, their chosen tier and the reference architecture that matches their size. Ask for these inputs to be explicit: the number of licensed users versus active users, which features require Premium or Ultimate, expected CI job volume for runners, backup retention and where backups are stored, and the number of upgrade windows per year. A partner is most useful for three outputs: a sizing review against the reference architecture, an edition mapping that separates features you need from features you only want, and a first upgrade plan that accounts for required upgrade stops.

This section covers cost and editions only. For the scope, the build sequence and how the cost drivers apply to a fixed-scope project, see the GitLab implementation plan and cost page. Confirm current tier prices and feature placement directly with GitLab before you finalize a budget, because the pricing page is the source of record.

What a cost of ownership review includes

A cost of ownership review produces a written model of the instance you plan to run. Each deliverable below is a input or output you can change as your user count, features and policies become clearer.

User and concurrency baseline

The model starts from the number of named users, active users per day and peak concurrent activity, split by teams and time zones. Ask how many users are licensed versus active, and which groups will push large repositories or heavy CI traffic. These numbers select the reference architecture and drive every later line item.

Edition mapping against required features

Each required capability, such as advanced CI/CD, SAML or SCIM provisioning, Geo replication, or application security and compliance features, is mapped to Free, Premium or Ultimate. Premium is listed at 29 US dollars per user per month billed annually, per the GitLab pricing page, while Ultimate is custom priced, so the per-user cost of the chosen tier should be confirmed in a written quote.

Reference architecture selection

The model names the reference architecture that matches your user count and API load, from the 1,000-user tier to the 50,000-user tier, and notes where high availability becomes the expected pattern at 3,000 or more users. It also records the layout choice between the Linux package, the Helm chart or Operator, and the Cloud Native Hybrid pattern, since stateful services stay on VMs or managed services.

One-time and recurring cost table

The table separates one-time costs, such as planning, implementation, migration and hardening services, from recurring costs, such as licenses, compute, storage, support and admin time. Each row names who pays for it: your organization, a cloud or data center provider, or a partner under a fixed-scope agreement. Ask the vendor and any implementation partner to price each row separately.

Runner capacity estimate

The estimate counts the CI/CD jobs you expect per day and at peak, their average duration and their resource needs, then sizes shell, Docker or autoscaling runners to match. Runner compute is often the largest recurring cost after licenses, so the model should show how autoscaling limits idle capacity. Keep Runner versions aligned with GitLab in the upgrade cost.

Backup and storage growth model

The model projects repository, artifact, container registry and PostgreSQL growth over the planned retention period, then sizes object storage and backup targets for it. It also budgets for separate saving of secrets and configuration files, and for regular restore tests that consume time and capacity. Ask how backups will be stored and whether Geo replication adds a second copy.

Upgrade calendar and required stops

The calendar combines the yearly major release, the monthly minor release on the third Thursday, and the twice-monthly patch releases with the required upgrade stops at x.2, x.5, x.8 and x.11. Security fixes reach the previous two monthly releases, while bug fixes reach only the current stable release, so the schedule should plan for patching at least as often as security backports require. Each stop adds test and change-window effort.

Open questions for the vendor

The final card is a written list of questions the model cannot answer on its own, such as Ultimate pricing for your user count, support terms, licensing for air-gapped installs, and whether specific features are available in your edition. Each question names the document or quote that will resolve it. The model is a working file you update as answers arrive, and a fixed-scope quote follows only from a written scope.

What drives the cost of ownership

This table lists the factors that change the running cost and effort of self-managed GitLab, why each one matters and how to keep it under control.

Driver	Why it matters	How to keep it under control
Active user count	GitLab's reference architectures run from 1,000 users (20 API requests per second) to 50,000 users (1,000 API requests per second), so server count, database capacity and storage grow with headcount.	Size the instance from your actual active users and request load, and confirm the reference architecture with GitLab's documentation before you buy hardware.
Tier choice	Free costs nothing, Premium is listed at 29 US dollars per user per month billed annually, and Ultimate is custom priced. Each step adds licensed seats and possibly features you rely on.	Map the features you need (advanced CI/CD, Geo, security scanning, compliance) to tiers before you commit. Ask for a written quote for the exact seat count.
High availability needs	The docs generally recommend a high availability strategy at 3,000 or more users, which adds Gitaly Cluster, PostgreSQL with Patroni, Redis Sentinel and Consul, each needing servers and operator time.	Decide early whether your uptime requirement justifies the extra nodes. Confirm the target architecture with your team before sizing infrastructure.
Geo for warm standby	Geo provides a continuously synchronized secondary site in another region, which means a second environment to run, network capacity to replicate data, and a Premium or Ultimate license.	Limit Geo to a disaster recovery requirement you have documented. Confirm the replication scope and failover steps before costing the second site.
Number and size of runners	Runner compute is often the largest recurring infrastructure cost, and it grows with pipeline volume, job duration and concurrency. Runners are separate from the GitLab server cost.	Use autoscaling on your cloud or hypervisor capacity, set tags and scopes so jobs land on the right runners, and review job durations regularly.
Repository and artifact growth	Repository, container registry, package and CI artifact storage grows over time, and backups and restore tests grow with it.	Set retention policies for artifacts and old pipelines, plan object storage capacity, and track growth each quarter so storage does not surprise you.
Number of upgrade windows	Required upgrade stops fall at x.2, x.5, x.8 and x.11 (for example 18.5, 18.8, 18.11 and 19.2), and each one needs a planned window, testing and a backup. Monthly minor releases add routine work.	Plan a fixed upgrade cadence that passes through each required stop, test in a staging environment first, and budget admin time for every window.
Air-gapped operation	Running offline requires transferring packages and images across the boundary, activating licenses offline, and patching without internet access. Scanners and GitLab Duo Self-Hosted need separate offline setup.	Confirm which features you need offline before design. Plan the transfer process and its approval steps as recurring work, not a one-time task.
Compliance evidence needs	Assessors often ask for configuration evidence, audit events, access reviews and documented patch cadence. Producing this evidence takes ongoing admin effort, and some controls may need Ultimate features.	Agree the evidence list with your auditor early, automate exports where possible, and confirm which controls depend on your chosen tier.
Number of identity sources	Each identity source (LDAP, SAML, OAuth 2.0 or OmniAuth providers, Kerberos, SCIM) adds configuration, group mapping and troubleshooting effort, and changes access reviews.	Keep identity sources to the minimum your organization needs, use a single primary identity provider where possible, and document group-to-role mappings.

How the cost model is built

The sequence turns user counts, API demand and growth measurements into a cost model that names every one-time and recurring cost and that the owner can update as their instance changes.

Baseline users and API demand
Count named users, active contributors, CI pipelines per day and expected API request rate, working with the platform owner and the teams that use GitLab today. The output is a sizing sheet with user counts split by activity and a peak API estimate, and the step is done when the owner has signed off on the numbers and their source.
Choose edition and reference architecture
Match the sizing sheet to a GitLab reference architecture, which runs from 1,000 users at 20 API requests per second to 50,000 users at 1,000 requests per second, and select Free, Premium or Ultimate based on the features your teams need. The output is a written edition decision and a reference architecture, with the per-user Premium price confirmed against the current GitLab pricing page and Ultimate pricing requested as a custom quote.
Model one-time and recurring costs
List the costs by who pays for them: your cloud or data center bill for compute, storage, load balancers and backup targets, GitLab subscription fees if you buy a paid tier, implementation services, and internal admin time. Separate one-time items such as build, migration and integration from recurring items such as subscriptions, infrastructure, backup storage and upgrade effort. The step closes when each line has a source, an owner and a driver that can be changed.
Measure runner and storage growth
Run a pilot or read the metrics from your existing instance to measure repository size, artifact and package storage, CI job minutes, runner concurrency and database growth over a representative period. Compare the measured growth against the reference architecture sizing and against the infrastructure lines in the model. The output is a growth table per resource, and the step is complete when the model uses measured values in place of guesses.
Set the upgrade and patch calendar
Build a calendar from the GitLab maintenance policy: a yearly major release, a minor release on the third Thursday of each month, patch releases twice a month, and the required upgrade stops at x.2, x.5, x.8 and x.11. Add staging test time, backup verification and runner version alignment for each cycle, and attach a labor estimate to each planned stop. The output is a dated calendar and the recurring labor it implies, and the step is done when the owner accepts who performs each upgrade.
Hand over the model and its assumptions
Deliver a spreadsheet or document that lists every input, its source, the assumed growth rate and the trigger that would change the model, such as a move to high availability at 3,000 or more users. Walk the platform owner through how to update each input, and record which figures came from a quote and which came from measurement. The step is complete when the owner can re-run the model without the implementation team.

Recurring and one-time cost lines

This table lists each recurring and one-time cost of self-managed GitLab, what it pays for and what to request in a quote, so you can compare your own team's effort with a partner's fixed-scope work.

Cost line	One-time or recurring	What it pays for	What to ask in a quote
Subscription tier	Recurring	Premium at 29 US dollars per user per month billed annually (GitLab pricing page) adds advanced CI/CD and priority support. Ultimate is custom priced and adds security and compliance features.	Confirm per-user rate, billing term and discount in writing. Illustrative 200-user total: 69,600 US dollars per year at list, before any negotiated discount.
Servers and storage	Recurring hosting, one-time sizing	Compute, memory and disk for the reference architecture that matches your user count, starting at 1,000 users (20 API requests per second).	Reference architecture size, monthly hosting cost, storage growth assumptions and who owns capacity reviews.
High availability components	Recurring hosting, one-time build	Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul, generally recommended from 3,000 users.	Node count, load balancing, failover test scope and who operates each stateful component.
Geo secondary site	Recurring hosting, one-time setup	A warm-standby site in another region, continuously synchronized for disaster recovery. Geo is available in Premium and Ultimate.	Whether Geo is in scope, replication scope, standby hardware, inter-region bandwidth and failover test steps.
Runner compute	Recurring	Capacity that runs CI/CD jobs, driven by pipeline volume, job duration and concurrency targets.	Runner count, executor type, autoscaling limits, and who patches and aligns runner versions with GitLab.
Backup storage and restore testing	Recurring storage, one-time test design	Object storage and database backups, plus scheduled restore tests that cover data and the secrets and configuration files.	Retention period, storage location, restore test frequency and who signs off on test results.
Upgrade effort	Recurring, with one-time effort at each required upgrade stop	Monthly minor releases on the third Thursday, patch releases twice a month and required stops at x.2, x.5, x.8 and x.11.	Who performs minor and stop upgrades, test environment scope and how upgrade hours are billed.
Security tooling and patch administration	Recurring	Scanner licensing, vulnerability tracking, OS patching of GitLab hosts and applying security backports to the previous two monthly releases.	Which scanners are included, who licenses them, and who triages findings and applies patches.
Internal admin and on-call time	Recurring staff time	Your administrators' hours for user management, backup checks, upgrades, monitoring and after-hours response.	Which admin tasks a partner covers and which stay with your staff, so you can budget internal hours.

How the cost picture changes by starting point

Teams moving from a SaaS GitLab or another code host usually face the largest one-time effort. Recurring costs shift from a vendor subscription to infrastructure you run.

Migration effort grows: the built-in importers cover GitHub, Bitbucket, Gitea and Jira issues, but each source needs user mapping, permission review and CI pipeline rework.
Subscription lines change: per-user SaaS fees may be replaced by a Free or Premium license, with Premium listed at 29 US dollars per user per month billed annually.
Compute grows: moving CI/CD brings runner capacity, build caches and artifact storage onto your own infrastructure.
Subversion adds work: it needs external conversion tools, which adds planning and verification time.

Confirm with GitLab which license terms apply to your seat count and which importer covers each source system.

Where cost models usually go wrong

Six assumptions cause GitLab cost models to drift after launch. Each one has a check to run before the budget is approved.

Editions chosen from feature lists

Teams often pick Free, Premium or Ultimate by scanning feature lists and assume each feature behaves the same on a self-managed install. Premium is listed at 29 US dollars per user per month billed annually, and Ultimate is custom priced, so the tier sets the cost per seat. Map each required feature to its tier, then confirm its license terms under the ee/ directory in writing before budgeting.

Sizing from user count alone

Reference architectures are published by load, from 1,000 users at 20 API requests per second to 50,000 users at 1,000 requests per second. Headcount understates demand when CI polling, bots, integrations and scripts drive most API traffic. Measure API demand on your instance first, then choose the architecture that matches it, since Gitaly, PostgreSQL and Redis sizing follow from that choice.

Runner compute left out

Runners execute CI/CD jobs on compute, storage and cache that you provide, so they are often missing from the GitLab model. Price runner hosts for peak pipeline concurrency, autoscaling capacity on your cloud or hypervisor, and the shell, Docker or Kubernetes executors your jobs need. Runner is MIT licensed, so the main costs are infrastructure and the staff time to operate it.

Upgrades assumed to be rare

GitLab ships minor releases on the third Thursday of each month and patch releases twice a month, so upgrade work recurs. Required upgrade stops fall at x.2, x.5, x.8 and x.11, for example 19.2, 19.5, 19.8 and 19.11, and a jump across them must pass through each stop. Budget recurring staff time, a staging environment and maintenance windows for this cadence.

Backups treated as free

Backup storage is easy to price, but the restore path is what costs time during an incident. Plan for the gitlab-backup tool, separate saves of secrets and configuration files, and object storage and PostgreSQL backups at larger scale. Budget regular restore tests on a separate environment, because a backup that has never been restored has unproven recovery value.

Admin time underestimated

Self-managed GitLab needs administrators for upgrades, backups, runners, identity sync, security patches and user requests, and that work rarely appears as a line item. Estimate it per role, separating one-time build work from recurring operations. Ask any partner to show the operations effort behind its quote, and confirm who on your team carries on-call duty.

What the client needs to provide

Before a cost model for self-managed GitLab can be built, the client needs to supply a set of operational inputs. The most important are active user counts broken down by group and location, along with peak and average demand on the instance. User count alone sets the reference architecture size and the tier question, but concurrent demand, measured as API request rates and Git activity during working hours, is what determines the sizing of the application and Gitaly nodes. Ask for both the licensed seat count and the number of users who actually sign in each month.

Collect the current state of code hosting and CI tooling with its annual costs: existing source control licenses, CI runner compute, artifact storage, and any paid add-ons. Add the identity sources the instance must integrate with, such as Active Directory, LDAP, or an existing SAML provider, because identity work is a separate cost line. Record compliance and data residency requirements, including where repositories and artifacts may be stored and whether air-gapped operation applies. Pipeline volume matters too: the number of jobs per day, typical job duration, and build frequency for each team determine runner capacity and autoscaling needs.

Ask for the backup retention expectations, the recovery point and recovery time targets the business has agreed, and whether a warm standby site is in scope. These drive storage, backup tooling and restore test effort. Then name an owner for each cost line, for example infrastructure, licensing, runner compute, or administrator time, so that every figure in the model has a person accountable for confirming it. Also identify the decision-maker for the edition choice, since Free, Premium and Ultimate differ in features that carry different prices and approval paths.

Missing inputs should be recorded as explicit assumptions in the model, with the owner who will confirm each one and the date by which they will do so. Do not guess a user count, pipeline volume or retention period and treat it as fact. An assumption that is written down can be changed later and its cost impact recalculated, while a guessed figure quietly becomes the basis for the budget. Review the assumptions list with the client before a quote is finalized, and confirm any licensing, pricing or vendor terms directly with GitLab, because published figures can change.

Questions buyers ask about GitLab costs

What does self-managed GitLab cost, and where does most of it go?

Self-managed GitLab has no single price. The total comes from several lines: the subscription tier, servers and storage sized to your user count, runner compute for CI/CD jobs, backup storage, upgrade and maintenance work, and the staff time to run the platform. GitLab Runner is MIT-licensed and can run on your own hardware or cloud capacity, so runner cost rises with pipeline volume, job length and autoscaling settings. Licence cost is only one line, so model each one separately. Ask any partner for a written breakdown of one-time and recurring costs.

Is GitLab Free enough, or what do Premium and Ultimate add?

GitLab Free costs 0 US dollars. According to the GitLab pricing page, Premium costs 29 US dollars per user per month billed annually and adds advanced CI/CD and priority support. Geo disaster recovery is available in Premium and Ultimate. Ultimate adds application security testing, software supply chain security, vulnerability management and compliance features, and it is custom priced, so it needs a quote based on your user count, features and support terms. Compare the feature lists with your actual requirements and confirm current prices on the pricing page.

How many servers does GitLab need for our user count?

Start from the reference architecture that matches your user count. GitLab's reference architectures range from 1,000 users at 20 API requests per second to 50,000 users at 1,000 API requests per second. The documentation generally recommends a high availability strategy for 3,000 or more users, which adds Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. Stateful components such as PostgreSQL and Redis are not supported inside Kubernetes, so the Cloud Native Hybrid layout keeps them on VMs or managed services. Confirm exact machine sizes in the documentation for your chosen version.

How often do GitLab upgrades happen and what do they involve?

GitLab ships a major release yearly, a minor release on the third Thursday of each month and patch releases twice a month. The maintenance policy currently maintains 19.3, 19.4 and 19.5. Required upgrade stops fall at x.2, x.5, x.8 and x.11, so you cannot skip them. Bug fixes go only to the current stable release, while security fixes also go to the previous two monthly releases. Effort depends on instance size, node count, background migrations and how many stops you cross. Plan a staging upgrade, tested backups and a rollback path for each cycle, and include that work in your annual cost.

Is a partner worth it compared with building the GitLab skills in-house?

It depends on your team's GitLab experience, available capacity and how much change the platform needs. In-house teams keep knowledge and control but must cover design, migration, upgrades and on-call support. A partner works to a fixed scope agreed in writing before work starts, which can suit a defined one-time implementation. Duration depends on the scope and your data, including user count, repositories, identity integration and migration volume. DeployOpen provides a written estimate once the scope is defined.

Does DeployOpen issue compliance attestations for our GitLab environment?

No. DeployOpen does not issue audit reports, attestations or certifications. It plans, implements and documents systems, and it prepares controls and evidence for compliance assessments. Independent auditors and certification bodies perform the assessment and issue any result. GitLab's hardening guidance references NIST SP 800-53, so configuration, access and logging evidence can be mapped to the controls your assessor uses. Confirm the required scope and evidence format with your assessor before implementation begins.

How DeployOpen scopes and hands over the cost model

DeployOpen turns GitLab cost of ownership and editions into a written, fixed-scope model that covers tier choice, infrastructure, runners, upgrades, backups and admin time in the environment you run. The model is handed over so your team can maintain it after the engagement ends.

How we scope

Confirm your user count, tier options and whether Premium or Ultimate features are required before any sizing begins.
Map GitLab reference architecture size, Linux package or Kubernetes layout and storage to your own infrastructure and cloud accounts.
Record runner compute, backup retention, upgrade cadence and admin hours as separate lines in the written scope.

How we build

Build the cost model as a worksheet that separates one-time setup costs from recurring licence, infrastructure and support costs.
Test sizing assumptions against your expected CI/CD job volume, repository growth and concurrent user load.
Check the model against your offline or air-gapped constraints, identity setup and any high availability needs you have confirmed.

How we hand over

Deliver the cost model, its assumptions and the sources behind each figure in a document your finance and platform teams can edit.
Walk through which inputs change costs up or down, such as user count, runner hours, storage growth and required upgrade stops.
Document the questions to confirm with GitLab and your reseller or procurement team before purchasing a tier.

How we support

Review the cost model when your user count, tier or infrastructure changes, using a retainer if you want ongoing support.
Update the model to reflect GitLab maintenance cadence, required upgrade stops and changes to the editions you license.
Keep the model aligned with backup, restore testing and runner version work covered in the written scope.