When is GitLab Free enough, and when does a self-managed instance need Premium or Ultimate?
A self-managed GitLab Free instance is enough for a small team that does not need LDAP group sync, Geo disaster recovery or the Premium code review controls, and that is willing to run its own backups and upgrades. The Free tier includes source code management, CI/CD and static application security testing. The 5-user limit that applies to Free on GitLab.com does not apply to a self-managed Free instance, according to the GitLab pricing page FAQ, so user count alone is not the trigger to buy a subscription. The decision turns on features, not headcount. Before you commit to Free, confirm that your identity model works with local accounts or the authentication methods available in Free, and check the feature list for each control your audit or internal policy requires.
Move to Premium when you need LDAP group sync, Code Owners enforcement or Geo. GitLab's LDAP synchronization documentation marks group sync as requiring Premium or Ultimate on GitLab Self-Managed, so a directory-driven access model is the most common reason a self-managed team pays. Code Owners is listed for Premium and Ultimate on self-managed instances, which matters if you want required reviewers on protected paths. Premium at 29 US dollars per user per month billed annually, according to the GitLab pricing page, also adds advanced CI/CD, team project management and priority support. Ask GitLab for a quote that counts only the users who need those features, and confirm whether your billing model is annual.
Choose Ultimate only when dynamic application security testing, vulnerability management or compliance and governance features are part of your written control set. DAST is documented for Ultimate only, and the pricing page places software supply chain security, vulnerability management and compliance features there too. Ultimate is custom priced, so the quote should list the specific features, the number of seats and any guest users, since Ultimate includes unlimited guest users. Ask the vendor to confirm which features are included in the exact tier version you will run, and plan a pilot that tests scanners in your offline environment if you are air-gapped, because GitLab documents separate guidance for that case.
Which features sit in Free, Premium and Ultimate on self-managed GitLab?
This table maps the features most teams ask about to the three tiers available on self-managed GitLab. Where a placement is not covered by the sources we reviewed, the cell says so and names where to confirm it. Use it as a checklist against your own requirements before you request a quote.
| Capability | Free | Premium | Ultimate |
|---|---|---|---|
| Source code management and CI/CD | Included | Includes advanced CI/CD | Includes advanced CI/CD |
| Static application security testing (SAST) | Included | Confirm on the pricing page | Included |
| Team project management and SLA management | Not listed | Included | Included in the tier's feature set |
| Priority support | Not listed | Included | Confirm support level on the pricing page |
| Code Owners for review controls | Not listed | Included | Included |
| LDAP group sync on Self-Managed | Not listed | Included | Included |
| Custom admin role assigned to an LDAP group | Not listed | Not listed | Included |
| Dynamic application security testing (DAST) | Not listed | Not listed | Included |
| Vulnerability management, software supply chain security and compliance | Not listed | Not listed | Included |
Which tier fits which team profile?
A small engineering team that hosts its own code, runs pipelines and has no requirement for directory-driven access control or formal security reporting can often run on Free. The Free tier covers source code management and CI/CD, and it includes static application security testing, so the baseline pipeline checks are available without a subscription. Free is not limited to five users on a self-managed instance, because the five-user cap in GitLab's pricing FAQ applies only to GitLab.com's Free tier.
- Source code and CI/CD: Repositories, merge requests and pipelines are the core of Free, and they are sufficient when reviews are informal and access is managed by hand.
- Static analysis: SAST is included in Free, which covers the first layer of code scanning without an upgrade.
- No directory sync: LDAP group sync requires Premium or Ultimate on Self-Managed, so accounts are provisioned individually.
- Support model: Free has no priority support, so the team needs its own on-call capacity for upgrades and incidents.
- Upgrade cadence: Monthly minor releases and required upgrade stops still apply, and someone must own them.
Before staying on Free, confirm with GitLab's pricing page whether the features your reviews and audits depend on are included in the tier you select.
A regulated team often needs two things early: approval rules that prove the right people reviewed sensitive code, and group membership that comes from the corporate directory rather than manual admin work. Premium adds both. Code Owners is listed for Premium and Ultimate on Self-Managed, so ownership rules can require named approvers for protected paths. LDAP group sync is also gated to Premium or Ultimate on Self-Managed, which lets directory groups drive project access.
- Code Owners: Path-based approval rules let reviewers for a service or a regulated module be required before merge.
- LDAP group sync: Directory groups map to GitLab access, so joiners, movers and leavers are handled in one place.
- Priority support: Premium includes priority support, which matters when an outage or failed upgrade sits inside an audit window.
- Team project management and SLA management: These are listed for Premium and matter when delivery reporting must be shown to governance bodies.
- Cost driver: Premium is listed at 29 US dollars per user per month billed annually, so the bill scales with the number of licensed users, not with instance size.
Before committing, confirm which directory protocol and group model your identity team runs, and check that the approval rules you need are supported at the tier you buy.
A security-led organization usually needs evidence of runtime testing and a single place to triage findings across projects. Ultimate adds application security testing, software supply chain security, vulnerability management and compliance and governance features. DAST is documented as Ultimate-only on GitLab.com, Self-Managed and Dedicated, so a team that wants dynamic scans of deployed applications must buy Ultimate rather than rely on the Free SAST tooling. Ultimate pricing is custom, so the quote follows from the scope agreed.
- DAST: Dynamic scans against running applications are the trigger, and they matter when staging environments are reachable and testing is part of release approval.
- Vulnerability management: Findings are tracked across projects, which matters when many teams ship code and central security must report on open risk.
- Custom admin roles: Assigning a custom admin role to an LDAP group is limited to Ultimate, which matters for least-privilege separation of duties.
- Compliance and governance: These features support control evidence, but they prepare records and do not replace an independent assessment.
- Unlimited guest users: Ultimate includes unlimited guests, which matters for external testers or partners with read access.
Ask for a quote built from a written scope, and confirm which scanners and environments the quote covers before purchase.
A team that runs GitLab in an offline network has the same tier choices as anyone else, but the operating model changes. GitLab documents offline and air-gapped installs, with separate guidance for running its security scanners and GitLab Duo Self-Hosted offline. Tier choice then depends on whether the scanners and advisory data you need can be updated inside the enclave, because connected-only features lose value when signature and vulnerability data cannot refresh.
- Offline scanner guidance: Check GitLab's offline environments page for the scanners you plan to run, since their update path differs from connected installs.
- Premium features still need a license: Code Owners and LDAP group sync work offline only with an activated subscription, so the license key must be loaded on the instance.
- Update packages: Monthly releases and required upgrade stops must be staged into the enclave, which adds recurring effort regardless of tier.
- Ultimate scanning data: DAST and vulnerability tooling depend on feeds that must be mirrored, so the reader should confirm the update process before buying.
- Subscription lapse: Confirm what the instance does when a subscription ends, because that determines the exit plan for a closed network.
Before purchase, ask GitLab and your DeployOpen scope lead to confirm offline behavior for each feature you plan to use.
How licensing and support differ across the three editions
GitLab's self-managed tiers share one codebase split by license, so the edition choice is mostly a question of which files you run and whether you pay for features and support. The cards below cover the license split, the release maintenance window, and what a subscription changes.
Community Edition under MIT
The Community Edition is MIT licensed, so teams can read, modify and redistribute its code without a subscription. It covers the core Git hosting and project features, but it does not include the features gated behind the ee/ directory. Before committing, confirm which installed package your team actually runs, because the Community Edition is a separate download from the Enterprise Edition build.
Files in the ee/ directory
Content under the ee/ directory falls under the GitLab Enterprise Edition license and is proprietary. Features such as LDAP group sync and Code Owners on Premium depend on this code, so running it requires a paid subscription for those features. Ask your legal team to review the license terms for any internal modification or redistribution plans, since the MIT grant does not extend to this directory.
All three tiers on self-managed
Free, Premium and Ultimate are all available for self-managed installations, so the tier decision does not require moving to GitLab.com or GitLab Dedicated. The Free tier's five-user limit applies only to GitLab.com, so a self-managed Free instance is not capped at that number. Confirm with GitLab how seat counts and activation work for your deployment before you size a rollout.
Monthly releases and security backports
GitLab ships a minor release monthly on the third Thursday, and bug fixes reach only the current stable release. Security fixes are also backported to the previous two monthly releases, and 19.5, 19.4 and 19.3 are the maintained versions in the policy. Plan an upgrade cadence that keeps you within this window, because an instance on an unmaintained version may not receive security fixes.
Required upgrade stops
GitLab requires upgrades to pass through specific upgrade stops, which since GitLab 17.5 fall at versions x.2, x.5, x.8 and x.11. Free and paid instances follow the same path, so a subscription does not shorten the upgrade route. Budget test upgrades in a staging environment, since a skipped stop can block an in-place upgrade.
What a subscription changes
A paid subscription unlocks the Premium or Ultimate feature set and comes with priority support, which the Free tier does not include. Free relies on community resources and the documentation. Ask GitLab for the written support response commitments for each tier and confirm whether they cover your upgrade and incident scenarios before you rely on them.
What drives the total cost of a paid GitLab tier?
The subscription line is only one part of a paid GitLab tier. Premium is published at 29 US dollars per user per month billed annually, so the recurring license cost scales directly with the number of seats you assign. Ultimate is custom priced, which means the figure comes from your requirements and user count rather than a public list. Ask the vendor to quote both tiers against the same user count, state whether the price is annual or multi-year, and confirm how seats are counted for guest users, since the Ultimate pricing summary includes unlimited guest users. Confirm the exact seat rules and any renewal uplift in writing before comparing totals.
Some costs are one-time and tied to specific features. Enabling LDAP group sync on Premium or Ultimate requires directory configuration, testing of group mappings and an ownership decision on who maintains them. Geo for disaster recovery needs a second site, replication testing and a documented failover runbook. DAST, which is limited to Ultimate, needs target applications, authenticated scan configuration and a triage process for findings. These tasks are paid as implementation effort, either by your own engineers or by an implementation partner under a fixed-scope written agreement, and they recur whenever you change identity sources, add sites or upgrade GitLab.
Infrastructure is the cost that grows with users and is easiest to underestimate. GitLab's reference architectures run from 1,000 users at 20 API requests per second to 50,000 users at 1,000 requests per second, and the documentation generally recommends a high availability strategy at 3,000 or more users. That strategy involves Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul, all of which need servers, storage, backups and operating time. Check the GitLab reference architectures documentation against your expected user count, and ask your quote to separate license, implementation and infrastructure lines so the three can be compared across tiers.
Which cost components apply to each GitLab edition?
This table breaks down who gets paid for what under GitLab Free, Premium and Ultimate on a self-managed instance. Read each row as a separate cost line, since the license fee is only one part of what a self-managed tier costs to run.
| Cost component | Free | Premium | Ultimate |
|---|---|---|---|
| GitLab subscription fee | None. GitLab Free costs 0 US dollars and carries no subscription charge. | Published at 29 US dollars per user per month, billed annually, per the GitLab pricing page. | Custom priced. Confirm the quote with GitLab sales before budgeting. |
| Who is paid for the license | Nobody to GitLab. The Free tier is still a supported installation path for self-managed instances. | GitLab, through a per-user subscription recurring each billing year. | GitLab, through a custom-quoted subscription. Recurring unless the contract states otherwise. |
| Internal staff effort to run it | Recurring. Your administrators handle upgrades, backups, monitoring and security patching themselves. | Recurring. Same operating effort as Free, plus configuring LDAP group sync and code owner rules. | Recurring. Same operating effort, plus administering security scanning, vulnerability workflows and compliance features. |
| Infrastructure and hosting | Recurring. Servers, storage, backups and network in your own environment, sized to user count. | Recurring. Same hosting footprint, plus any Geo secondary site you choose to build for disaster recovery. | Recurring. Same hosting footprint, plus added capacity for scanning jobs and runners. |
| Implementation and upgrade services | One-time setup plus recurring upgrade work. Upgrades must pass through required upgrade stops. | One-time setup of LDAP, Geo and code review controls, plus recurring upgrades. Partner work is fixed-scope if you buy it. | One-time setup of security testing and compliance workflows, plus recurring upgrades and evidence collection. |
| What to ask for in a quote | Not applicable to the license. Ask for your own sizing and upgrade plan instead. | User count, billing term, which Premium features you rely on and the support level included. | User count, the exact Ultimate features in scope, guest user counts, support level and renewal terms in writing. |
How do you move from Free to Premium or Ultimate without an outage?
The sequence confirms your version and support window, applies the paid license to the Enterprise Edition build, moves through required upgrade stops, and validates the features you bought before users depend on them.
Confirm the installed version and maintenance window
Record the exact GitLab version your instance runs and compare it against the maintenance policy, which lists the currently maintained minor releases (19.5, 19.4 and 19.3 at the time of the supplied facts). Your platform or GitLab administrator owns this check. It is done when you have written down the current version, the target version and the support status of both, and you have confirmed with GitLab or your own change calendar which window the upgrade will use. Confirm the current list on the maintenance page before scheduling, since it changes with each monthly release.
Confirm the build and edition you run
Check that the instance runs the Enterprise Edition package. Community Edition cannot accept a Premium or Ultimate activation code, so an MIT-only install must be migrated to EE first. The administrator confirms this from the instance's version information and the installed package. It is done when the team has recorded the edition, and when the upgrade plan states whether a package change is needed as part of the move.
Apply the subscription or activation code
A license holder with the right to buy or manage the subscription applies the activation code to the EE instance through the admin interface. Pricing for Premium is a published per-user monthly figure billed annually, while Ultimate is custom priced, so the quote should state the seat count and billing terms in writing before activation. It is done when the admin area shows the purchased tier, the expiry date and the user count matches the quote. Ask the vendor how seat overage is handled and what happens at renewal.
Plan the upgrade path through required stops
GitLab requires upgrades to pass through required upgrade stops. Since 17.5 these fall at x.2, x.5, x.8 and x.11, and the documentation gives examples such as 18.5, 18.8, 19.5 and 19.8. Plan each hop in order, checking the upgrade paths page for your starting version. The administrator writes the sequence of stops and the rollback point for each. It is done when the plan lists every stop between the current and target versions and has been reviewed by the people who own the instance.
Take and test backups before any change
Take a full backup using the documented backup and restore procedure, and store it outside the instance host. Restore it into a staging environment built from the same version to confirm it works. If the instance uses external PostgreSQL, Redis or Gitaly, back up those components as the documentation describes. It is done when a restore test finishes, the restored instance loads projects and repositories, and the team signs off that the backup is usable for rollback.
Run each upgrade stop and verify health
Apply the upgrade to each required stop in the plan, one at a time, and run the health checks after each. Watch for failed background migrations and stopped services before moving on. The administrator owns the change, and an outage window is needed only if the environment cannot tolerate downtime during the stops. It is done when each stop reports healthy, the version matches the plan, and no migration remains in an error state.
Validate LDAP sync and Code Owners settings
Once the target version runs, enable and test the paid features you bought. For LDAP group sync, confirm the configuration sync runs against a test group and that group membership matches the directory. Only Premium or Ultimate supports LDAP group sync on Self-Managed, and assigning a custom admin role to an LDAP group is Ultimate only. For Code Owners, confirm that a protected branch rule triggers the expected approvals on a test merge request. It is done when a test user from each LDAP group has the expected access and a test merge request requires the right owner approval.
Record the change and confirm any downgrade limits
Document the final version, the edition, the subscription details and the validation results in your change record. Note that moving back down to Free removes paid features, and that rolling back a version may not restore the state of features used during the upgrade. Confirm the downgrade and data-retention behavior with GitLab in writing before you depend on it. It is done when the change record is filed and the team has a written answer on what a lapsed or cancelled subscription does to the instance.
What do buyers ask before hiring help with GitLab editions?
What does a Premium or Ultimate upgrade cost on a self-managed instance?
The subscription price is set by GitLab, and the figures you can rely on are the public list prices: Premium at 29 US dollars per user per month billed annually according to the GitLab pricing page, and Ultimate on custom pricing. The recurring cost scales with the number of licensed users, so user count and the tier you choose drive most of it. Separately, any implementation work is a one-time engagement priced from a written scope. Ask your reseller or GitLab for a quote that states the user count, billing term, and whether support level changes the price. DeployOpen does not publish prices, so its fee follows from the scope you agree in writing.
How long does enabling LDAP group sync or Geo take?
No duration is fixed by a supplied source, so treat any timeline as something to confirm for your environment. LDAP group sync depends on your directory structure, the group filters you need, and whether your identity team can give read access and test accounts. Geo depends on a second site, replication bandwidth, storage, and the reference architecture you run at each location. The GitLab documentation confirms that LDAP group sync requires Premium or Ultimate on self-managed instances, and that Geo is a separate build-out. Ask for the work to be broken into milestones with named dependencies so you can see where delays would come from.
Can our internal team handle the tier change without outside help?
Often yes, if you already run GitLab and have someone who has completed upgrades and backups. The tier change itself is mostly a license activation, but the surrounding work is not: you need to confirm the upgrade path, since GitLab requires stops at versions such as 18.5 or 19.5, plus LDAP filters, Code Owners rules, and an updated backup and restore test. Check whether your team has time for these checks alongside daily operations. An outside partner can take on defined deliverables, documentation and handover, which is useful when the internal team lacks spare capacity or prior experience with identity integration.
What does the work need from our side?
Plan for three kinds of input before work starts. Identity: read access to your identity provider or directory, a test group, and a service account with defined permissions. Infrastructure: access to the GitLab hosts or Kubernetes cluster, backup storage, and, for Geo, a second site. Named owners: one person who approves scope, one who owns the GitLab instance, and one who signs off on access and security settings. Name these owners in the written scope so decisions do not stall. Confirm the exact access model with your security team before any credentials are shared.
Can the Free tier be used for an air-gapped install?
Yes, the Free tier can run on a self-managed instance, and the GitLab offline environments documentation describes running self-managed instances in offline, air-gapped networks. The GitLab pricing FAQ also states that the 5-user limit applies only to GitLab.com Free, so a self-managed Free instance is not subject to it. Offline operation has its own tasks: you must mirror packages, container images and security scanner data into your network, and GitLab documents separate guidance for its security scanners and self-hosted Duo features. Confirm with GitLab which features your offline install will use, since paid features such as Code Owners or DAST have their own tier requirements.
Which tier features need a fixed scope before a quote?
Start with the features that decide the tier. Code Owners is listed for Premium and Ultimate on self-managed instances, DAST is Ultimate only, and custom admin roles assigned to LDAP groups are Ultimate only. Each feature you need should be written into the scope with the target version, the number of users, and the environment it runs in. A quote without a feature list tends to under- or over-scope the work. Ask the vendor to confirm each feature against the current GitLab documentation for your version before you sign.
What recurs after the change, and who is paid for what?
The subscription recurs, usually per user and per billing period, and it is paid to GitLab or its reseller. Upgrades recur as well, because GitLab ships monthly minor releases, maintains only the latest few versions, and requires upgrade stops. Those tasks are paid for internally or through an ongoing support retainer that DeployOpen offers, billed against an agreed scope. Ask for a written list of recurring tasks, the upgrade cadence you will follow, and who handles security patches within the maintained window.
How DeployOpen scopes an edition decision for your instance
DeployOpen plans, implements and supports self-managed GitLab inside your own infrastructure, whether that is your cloud accounts, your data centers or an air-gapped network. The edition decision is one of the first scoping questions because it determines which controls exist at all: code owner rules and LDAP group sync need Premium or Ultimate on a self-managed instance, while DAST and the other security testing and compliance features sit in Ultimate. Our role is to map those requirements against your identity provider, your review process and your evidence needs, so the edition you buy matches the controls you will configure and operate.
Most engagements are fixed-scope. Before any work starts, scope, deliverables and timelines are agreed in writing, and that document should list each tier-dependent feature in use, the environment it runs in, and who owns the administration afterward. DeployOpen does not publish a price list, so a quote follows from that written scope. Ask for the quote to separate one-time work (planning, installation, identity integration, hardening, documentation) from recurring items such as upgrades, backups and support, and ask which licensing costs are billed by GitLab rather than by DeployOpen. Subscription pricing for Premium is listed by GitLab, while Ultimate is custom priced, so confirm the subscription figure directly with GitLab before the quote is final.
DeployOpen is not a GitLab partner or reseller, and nothing in this section implies otherwise. Subscriptions are purchased from GitLab or its channel according to your procurement terms, and we will not act as a licensing intermediary unless a written agreement says so. Before scoping, confirm the current feature availability for each control you need in the GitLab pricing page and in the vendor documentation for your version, because tier placement can change between releases.
How DeployOpen delivers and supports either edition
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including GitLab. We start by fixing which tier your users, identity provider and compliance requirements actually need, then build the instance to match that decision.
How we scope
- We confirm the tier mapping from your user count, LDAP or SAML needs, code review rules and security testing requirements before any build work starts.
- The written scope lists which Premium or Ultimate features are in and which stay on Free, so procurement can check each line against the GitLab pricing page.
- We ask you to confirm current tier terms and per-user pricing with GitLab directly, since the scope document records them as of the quote date.
How we build
- We install the instance on the method your team chooses, such as the Linux package, Helm chart or Operator, inside your cloud accounts, data center or air-gapped network.
- We configure LDAP group sync, Code Owners rules and backup and restore procedures only where the chosen tier and your scope support them.
- We test the configured integrations, such as identity sync and security scanners, against the tier you bought, and record any feature that does not behave as the documentation describes.
How we hand over
- Handover includes runbooks for upgrades along GitLab's required upgrade stops, backup restores and tier-specific configuration, written for your own operators.
- We document the tier decisions, license activation steps and the features that would need a subscription change if your requirements grow.
- Deliverables are agreed in the written scope, so your team knows exactly which configuration, evidence and documentation it receives at close.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so the instance keeps pace with GitLab's monthly minor releases.
- A retainer can cover security testing of the instance and its pipelines, which helps you confirm that Ultimate scanners are configured as intended.
- Support scope, response expectations and upgrade windows are set in the retainer agreement, so ask for those terms in writing before you commit.
