When is GitLab Community Edition enough, and when does the Enterprise Edition become necessary?
Community Edition is enough when your team needs the core GitLab platform and can meet its own security and compliance needs without a paid feature. CE is MIT licensed, and the GitLab LICENSE file places all code outside the ee/ directory under that license. Nothing needs an activation code. Enterprise Edition becomes necessary when a specific requirement depends on a feature that sits behind a Premium or Ultimate subscription. The practical test is to list the controls your auditors, security team or regulator expect, then check each one against the GitLab pricing page feature lists before you install anything.
Be careful about what a fresh Enterprise Edition install gives you. According to GitLab's license activation documentation, a new instance installed without a license enables only Free features, and an activation code is needed to unlock more. So installing EE does not by itself give you Premium or Ultimate capability. An infrastructure lead should confirm with GitLab which features each tier includes for self-managed instances, then decide whether the EE package is worth installing now or later. Because an instance running CE can be upgraded to EE, starting on CE does not close the door on paid features. Administrators can confirm the edition and version under Help > Help.
Before committing to a paid tier, ask your security lead what proof of controls you must produce and whether Free covers it. For many small and mid-sized teams running their own servers, CE with well-managed backups, access controls and patching is a defensible choice. Teams that need application security testing, vulnerability management, compliance features or LDAP group sync should price Premium or Ultimate against the written scope of their needs, and should get the quote in writing. Confirm which features your GitLab version supports in your own environment, because the feature set changes across releases.
Which features sit in the free edition and which need a paid subscription?
This table compares GitLab Community Edition, the Enterprise Edition Free tier, Premium and Ultimate on the documented feature split for self-managed installations. Read it as a starting point: the exact feature matrix changes by version, so confirm each row on the GitLab pricing page for the release you plan to install.
| Capability | Community Edition and EE Free | EE Premium | EE Ultimate |
|---|---|---|---|
| Licensing of the code | MIT for code outside the ee/ directory; no activation code needed | Requires an activation code that unlocks EE features | Requires an activation code that unlocks EE features |
| Self-managed availability | Available | Available for self-managed installations | Available for self-managed installations |
| Advanced CI/CD | Core pipelines only; confirm current limits on the pricing page | Documented as included | Included in the higher tier |
| Priority support | Community support only | Documented as included | Included in the higher tier |
| Application security testing | Not documented as a paid-tier feature here; confirm scanner availability for your version | Not listed as a Premium feature | Documented as included |
| Software supply chain security and vulnerability management | Not included | Not listed as a Premium feature | Documented as included |
| Compliance features | Not included | Not listed as a Premium feature | Documented as included |
| Cost basis for the paid tiers | Free of charge at list | Priced per user per month, billed annually (per the GitLab pricing page) | Custom priced; request a quote from GitLab |
What license, support and update terms apply to each edition?
GitLab's editions differ in license, in what a subscription unlocks and in what happens when a subscription ends. The release and backport policy applies to every edition, so it sets the upgrade workload no matter which package you install. Check each card against your own compliance and upgrade calendar before you commit.
Community Edition under MIT
GitLab Community Edition is built from code outside the ee/ directory, which the LICENSE file makes available under the MIT license. It runs without a subscription and has no activation step. The practical question is whether the Free feature set covers your needs, because CE has no paid key to restore features if your requirements grow. Confirm with GitLab which features your team depends on, and whether any of them sit behind a paid tier.
Enterprise Edition Free without a license
A new GitLab Enterprise Edition install without a license runs only Free features. The EE package is the same codebase with paid code under the ee/ directory, so it gives you the option to upgrade later without a reinstall. Administrators can confirm the edition and version under Help. Teams that expect to buy Premium or Ultimate later should decide whether to start on EE now or to convert from CE at that point.
Premium and Ultimate need an activation code
Premium and Ultimate are paid subscriptions. The 24-character activation code from the subscription email or the Customers Portal is pasted into Admin > Subscription to unlock the tier. Premium is listed at 29 US dollars per user per month billed annually, while Ultimate is custom priced, so ask for a written quote that names the tier, user count and billing term. Confirm which features each tier covers for self-managed instances before you buy.
What a lapsed subscription does
When a subscription is not renewed, the activation key stops working and GitLab Enterprise Edition is no longer functional, according to the pricing FAQ. Some functions lock when the license expires, and the instance can be downgraded to Community Edition, which is free to use. Plan for the lock-out path in your change process, test the downgrade in a non-production copy, and confirm with GitLab what data stays accessible before renewal dates arrive.
Monthly releases and security backports
GitLab ships a minor release on the third Thursday of each month and patch releases twice a month. Bug fixes go only to the current stable release, while security fixes also reach the previous two monthly releases. This policy applies to CE and EE alike, so the security window is the same for every edition. Schedule an upgrade cadence that stays inside the maintained versions and plan for required upgrade stops.
What happens to an EE instance when the subscription lapses?
An Enterprise Edition instance does not stop working all at once, but it does lose its paid functions, and the path back to Community Edition needs to be rehearsed before the renewal date arrives. The activation code is pasted into Admin > Subscription, and GitLab's license activation documentation says that when the license expires, some functionality is locked. GitLab's pricing FAQ goes further: if the subscription is not renewed, the key no longer works and Enterprise Edition is no longer functional, and the customer can then downgrade to GitLab Community Edition, which is free to use. Treat that as the baseline and confirm the exact behavior for your installed version with GitLab before you rely on it in a budget or audit plan.
Plan for three things. First, confirm that your team can still reach its repositories, issues and pipeline history after the lapse, and that backups taken under the same edition can be restored. Second, inventory every setting that depends on a paid tier, such as the SAML or LDAP group sync, security scanning, compliance controls and any Geo or high availability setup, and decide which of them your team can live without or replace. Third, schedule a downgrade test on a staging copy of the instance: take a backup, apply the downgrade, check the Help > Help page for the edition shown, and record which jobs, integrations and user roles behave differently. Run the same test before each renewal, not once at purchase.
Ask GitLab, in writing, what happens to features your version uses, how long any grace behavior lasts, and whether a downgrade requires an upgrade path step that your current release does not allow. Your own environment matters as much as the vendor's answer, so document the results and link them to your renewal calendar. If the answer shows that a lapse would halt engineering work, that is a signal to negotiate renewal terms earlier or to reassess the tier in the GitLab pricing comparison before the contract ends.
How the cost of CE and EE differs by team situation
A small team that installs GitLab Community Edition pays no license fee, because the Free tier runs on an EE build without a key and CE is MIT licensed. The GitLab pricing page lists Free at 0 US dollars, and the cost that remains is the infrastructure and people needed to keep the instance running. For a team on CE, that cost is mostly staff time for upgrades, backups and monitoring, plus the servers, storage and backup targets the instance needs.
- Hosting: Recurring compute, storage and network costs for the server or servers, which rise with user count and repository size.
- Staff time: Recurring effort for monthly minor releases and the required upgrade stops, which GitLab documents as a path through versions such as 18.2, 18.5 and 18.8.
- Backups: Recurring storage and tested restores, which GitLab's backup and restore documentation describes as a process the operator owns.
- Initial setup: One-time effort to install, configure authentication and migrate any existing repositories.
- Security tooling: Features that Free does not include, such as advanced security scanning, must be built or sourced separately, which adds effort and sometimes cost.
Before committing, ask your own platform team to estimate the monthly upgrade and backup hours, and confirm which features your workflow needs are on the Free tier.
A team that needs advanced CI/CD or priority support moves from the Free tier to Premium, which the GitLab pricing page lists at 29 US dollars per user per month billed annually. The license cost scales with the number of users who are billed, so the total is a recurring figure that grows with headcount rather than with server size. Hosting and staff costs continue alongside it, and a team often underestimates how much of the total is the subscription itself.
- Per-user license: Recurring, billed annually at the published rate, and paid for each user the subscription covers.
- Advanced CI/CD and support: The pricing page lists advanced CI/CD and priority support for Premium, so the team pays for those features as part of the seat.
- Hosting for CI: Runner capacity, which may be self-managed on your own hosts, adds recurring compute cost that scales with pipeline volume.
- Activation and renewal: The subscription is activated with a 24-character code, and renewal is a recurring administrative step with a cost if it lapses.
- Staff time: Recurring upgrade and backup work continues unchanged, so Premium does not reduce operating effort.
Confirm the billable user count with your licensing contact, and ask whether the annual billing rate applies to your region and any reseller terms.
A regulated team that evaluates Ultimate faces a custom price, since the GitLab pricing page lists Ultimate as custom priced and available for self-managed installations. The quote follows from the user count, the security and compliance features the team needs, and the support terms. The license is only one line of the total, and the cost of the controls, evidence and infrastructure around it can be larger.
- Custom quote: A one-off negotiation that produces a recurring annual price, so ask for the price in writing with the term and renewal conditions.
- Feature scope: The pricing page lists application security testing, software supply chain security, vulnerability management and compliance features for Ultimate, and the team pays for these as part of the tier.
- Hardening and assurance work: One-time and recurring effort for configuration hardening, evidence collection and assessment support, which GitLab's hardening guidance helps structure.
- High availability: For larger user counts, GitLab's documentation generally recommends a high availability strategy for 3,000 or more users, which adds PostgreSQL, Redis and Gitaly infrastructure costs.
- Lapse exposure: If the subscription lapses, the EE instance stops working as EE, so the team needs a continuity plan.
Ask for the quote to itemize the subscription, support and any services, and confirm the lapse behavior in the written terms.
What cost components apply to each edition?
This table lists the cost components that apply to GitLab CE, EE Free, Premium and Ultimate, showing who gets paid, what recurs and what drives each cost. Use it to build the question list for a quote, since only the Premium list price and the Free tier price are published in the supplied pricing facts.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Software license or subscription | GitLab, for EE Premium or Ultimate only. CE and EE Free carry no license fee | Recurring. Premium is listed at 29 US dollars per user per month, billed annually, on the GitLab pricing page. Ultimate is custom priced | Seat count and tier. Ask whether the quote bills active or licensed users and how seats are true-upped during the term |
| Required paid features | GitLab, through the tier that contains the feature | Recurring while the feature is needed | Which features you turn on. Premium adds advanced CI/CD and priority support. Ultimate adds application security testing, software supply chain security, vulnerability management and compliance features. Confirm which feature you need before choosing a tier |
| Infrastructure (compute, storage, network) | Your cloud account, data center or hardware vendor | Recurring for hosting, one-time for hardware if on-premises | User count and reference architecture size. GitLab's reference architectures range from 1,000 users to 50,000 users, and high availability is generally recommended from 3,000 users. Ask the vendor or your architect to size against the documented reference |
| Upgrade staff time | Your internal team, or a DeployOpen retainer if contracted | Recurring, roughly per minor release | Release cadence and required upgrade stops. GitLab ships a minor release monthly and requires stops such as 19.2, 19.5, 19.8 and 19.11. Each stop adds planning and testing work |
| Backups, monitoring and restore testing | Your internal team, or an implementation partner | Recurring for operation, one-time for initial setup | Instance size, database layout and whether high availability components such as PostgreSQL with Patroni are in use. Confirm backup and restore procedures against GitLab's backup and restore documentation |
| Implementation services | Implementation partner, such as DeployOpen, or internal staff | One-time for installation, integration and hardening. Support can be recurring | Installation method (Linux package, Helm chart or Operator), identity integration and air-gapped requirements. Most engagements are fixed-scope, so request the written scope, deliverables and timeline before work starts |
| Edition change and lapse risk | Your team, with a possible migration cost | One-time if you move editions, plus a possible recurring cost if you stay on a paid tier | If a subscription is not renewed, GitLab's pricing FAQ says the key stops working and EE is no longer functional, and the instance can be downgraded to CE. Ask how data, configuration and paid features are handled in that downgrade |
How to move from CE to EE and back again
This sequence takes a self-managed GitLab instance from Community Edition to Enterprise Edition with a verified subscription, and shows how the instance falls back to Community Edition if the subscription lapses. Each step closes with a check you can run before moving on.
Confirm the current edition and version
The administrator signs in, opens Help > Help and records the edition and version the instance reports. Confirm whether it is Community Edition or Enterprise Edition and note the exact version number. Write both down in the change record, because every later step depends on that starting point. The step is done when the recorded version matches what the instance reports on that page.
Plan the route through upgrade stops
Open the GitLab upgrade paths documentation and find the row for your starting version. GitLab requires upgrades to pass through required upgrade stops, and since GitLab 17.5 these fall at versions x.2, x.5, x.8 and x.11. Write the full list of stops between your version and your target, and ask your GitLab contact or DeployOpen to confirm the path if the instance is far behind. The step is done when you have a written, ordered list of versions to install.
Rehearse the upgrade in a non-production instance
Build a copy of the instance from a recent backup and run the planned upgrade path against it first. The administrator or the implementation team performs the rehearsal, and it covers the edition change, background migrations, integrations and any custom CI runners. Record how long each stop took and every error that appeared. The step is done when the copy reaches the target version and core projects, users and pipelines behave as expected.
Install or upgrade to Enterprise Edition
Take a fresh backup of the production instance, then install the Enterprise Edition package at each stop in the planned order, following the installation method your team uses. Upgrading an existing CE instance to EE is documented as a supported path. Check the service status after each stop before moving on. The step is done when the instance is running the target EE version and Help > Help shows Enterprise Edition.
Paste the activation code in Admin > Subscription
Copy the 24-character activation code from the subscription confirmation email or the Customers Portal. In the Admin area, open Subscription and paste the code, then confirm the activation. The code must come from the subscription for the tier you bought, so check the tier name against your order before you activate. The step is done when the subscription page shows an active plan with the expected tier and expiry date.
Verify the features your tier includes
Test each feature your subscription is meant to enable, such as the paid CI/CD, code review or security features listed for your tier on the pricing page. Confirm that users, groups and integrations you depend on still work. Keep the test results with the change record. The step is done when every feature in your purchase order is reachable and the test evidence is filed.
Plan the downgrade path if a subscription lapses
Agree in advance who owns renewal and what the team does if the subscription is not renewed. GitLab's pricing FAQ says the key stops working and Enterprise Edition features stop functioning, and the customer can then downgrade to Community Edition, which is free to use. Ask the vendor to confirm the exact behavior and any data or access effects for your contract. Store the renewal date and the downgrade runbook with the backup records. The step is done when a named owner and a tested runbook exist before the renewal date.
Downgrade to Community Edition after a lapse
After a lapse, the administrator follows the documented downgrade process to move the instance to Community Edition, using the same upgrade-stop discipline and a fresh backup. Rehearse this path in the non-production copy before you need it. Check Help > Help afterward and confirm the features that remain available under Community Edition. The step is done when the instance reports Community Edition and the team has signed off on what changed for users.
Questions teams ask before choosing an edition
Can we start on GitLab Community Edition and upgrade to Enterprise Edition later?
Yes. GitLab's license activation documentation says an instance running Community Edition can be upgraded to Enterprise Edition, so the decision does not lock you in on day one. The upgrade path is a change of package and activation, not a new installation, but you still need to confirm the exact steps for your version with GitLab before planning it. Check your current edition and version under Help > Help, then review the upgrade stops in GitLab's upgrade paths documentation, because a required stop has to be passed in order. Plan the change in a maintenance window and take a verified backup first.
What happens to our data and features if the GitLab subscription lapses?
Your data stays on your servers, but paid features stop working. GitLab's pricing FAQ says that if a subscription is not renewed, the key no longer works and Enterprise Edition will not be functional anymore, and the customer can then downgrade to Community Edition, which is free to use. The license activation docs add that some functionality is locked when the license expires. Confirm with GitLab exactly which features lock, how long any grace behavior lasts and what the downgrade involves for your version, and keep your backups and configuration under your own control so a lapse never becomes a restore problem.
How do license and operating costs grow as our user count increases?
The subscription component scales with users, while the infrastructure and operations components scale with load and availability needs. GitLab's pricing page lists Premium at 29 US dollars per user per month billed annually and Ultimate as custom priced, with all tiers available for self-managed installations. Infrastructure costs follow GitLab's reference architectures, which run from 1,000 users at 20 API requests per second to 50,000 users at 1,000 API requests per second. GitLab's docs generally recommend a high availability strategy at 3,000 or more users. Ask for a quote that separates subscription seats, server and storage sizing, and any external PostgreSQL, Redis and object storage.
What does our internal team need to run a self-managed GitLab instance?
Your team needs Linux administration, database and backup skills, and a plan for monthly upgrades. GitLab ships a minor release on the third Thursday of each month and backports security fixes to the current and previous two releases, so an instance has to be patched on a steady cadence. Upgrades must pass through required stops that fall at versions such as 18.2, 18.5 and 19.2, and the Linux package bundles PostgreSQL, Redis and Sidekiq for simpler operation. Larger deployments that use Patroni, Gitaly Cluster and Redis Sentinel need people who can operate those components. Confirm the staffing estimate against your own user count before committing.
Can our own staff perform the upgrades and license activation without an outside partner?
Often yes, if your team has the skills and time, and the steps are documented. Activation is a simple task: an administrator pastes the 24-character activation code from the subscription confirmation email or Customers Portal into Admin > Subscription. Upgrades follow GitLab's documented paths and maintenance policy. Outside help is most useful for planning the upgrade stops, rehearsing restores in a staging copy, and documenting the runbook. DeployOpen plans, implements, upgrades, documents and supports self-hosted platforms in your own infrastructure under a written, fixed scope, or on a retainer for ongoing support, so the choice between in-house and partner work depends on your staffing.
How long does a migration from Community Edition to Enterprise Edition take?
The duration depends on instance size, the number of required upgrade stops between your version and the target, and how much testing your environment needs. The activation step itself is quick once you have the code, but the surrounding work is not. Factors that extend the timeline include the backup and restore rehearsal, the number of integrations to re-verify, and any change in installation method. GitLab does not publish a fixed duration in the sources available here, so ask GitLab and your partner to confirm the steps for your version. A written scope with clear deliverables lets you compare timelines across quotes.
Does Community Edition cover air-gapped or offline installations?
Community Edition can be installed offline, but you should confirm which features your environment needs. GitLab documents running self-managed instances in offline, air-gapped environments, with separate guidance for its security scanners and for GitLab Duo Self-Hosted. The paid tiers add application security testing, vulnerability management and compliance features on Ultimate, and Premium adds advanced CI/CD and priority support. Because those features depend on what each tier includes, map your required controls to the tier list on GitLab's pricing page and confirm offline support for each one with GitLab before procurement.
Where to check the edition split and license terms
Before you commit to either package, confirm the edition split against the primary sources rather than a summary. The GitLab LICENSE file in the gitlab-org/gitlab repository is the place to start: it shows that content outside the ee/ directory is available under the MIT Expat license, while content under ee/ is licensed under the GitLab Enterprise Edition license. GitLab LICENSE file Ask your legal or procurement team to read it, because the boundary between the two licenses determines what you can modify and redistribute on your own servers.
The GitLab pricing page shows which features sit in Free, Premium and Ultimate for self-managed installations, and it is the document to compare against any feature you have been promised. The page lists Premium at 29 US dollars per user per month billed annually and gives Ultimate custom pricing. Its FAQ also states that an unrenewed key stops working and that the instance can then be downgraded to Community Edition. Confirm the current figures and the feature matrix in writing with GitLab or your reseller before budgeting, since list prices and tier contents change.
Use the GitLab docs on license activation to confirm the activation steps and the behavior of an expired subscription in the version you plan to run. The docs describe pasting the 24-character activation code into Admin > Subscription and note that some functionality is locked when a license expires. For release timing, the GitLab maintenance policy defines which minor releases receive fixes, which matters because an EE instance you cannot upgrade still needs security patches. Record the edition and version under Help > Help and check both against the policy before each upgrade window.
How DeployOpen scopes and delivers a GitLab edition rollout
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For GitLab Community Edition vs Enterprise Edition, that means we start from which package and features your teams need, then build and document the instance on your servers, cloud accounts or air-gapped network.
How we scope
- Engagements are fixed-scope, with the edition, features and deliverables agreed in writing before work starts
- The written scope records which GitLab package, subscription tier and activation process applies to your instance
- Scope also states who owns the activation code, renewal date and the fallback plan if a subscription lapses
- Ask for a quote built from that written scope, since DeployOpen does not publish a price list
How we build
- We install GitLab on your infrastructure and confirm the edition and version under Help > Help
- We configure authentication, backups and the upgrade path, including the required upgrade stops for your target version
- We document the activation steps in Admin > Subscription so your administrators can repeat them without us
- We test backup and restore on the instance before handover, using the restore steps GitLab documents
How we hand over
- You receive written runbooks covering installation, edition checks, activation, backup, restore and upgrade procedures
- We walk your administrators through license expiry behavior so the renewal calendar is owned by your team
- Hardening decisions, configuration and evidence are documented so your auditors or assessors can review them
- Handover ends with a written list of open items, owners and the settings you should confirm with GitLab
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover
- A retainer can cover monthly and security release review, upgrade planning and the required upgrade stops
- Support can extend to the offline or air-gapped procedures GitLab documents if your network requires them
- Confirm the retainer scope, response expectations and any SLA terms in the written agreement
