Where GitHub Enterprise Server costs more than self-hosted GitLab or Gitea, and why
GitHub Enterprise Server usually costs more on licensing, while self-hosted GitLab Free or Gitea can remove per-user fees, but the total depends on user count, data volume and whether you buy a paid subscription. If your renewal is driven by per-user Enterprise licenses, the comparison comes down to what replaces those seats: a self-managed GitLab tier, a Gitea deployment with or without Gitea Enterprise, or a Forgejo instance with community support. Self-hosting moves cost out of the license line and into infrastructure, people, migration and upgrades. The GitLab pricing page lists GitLab Free at 0 US dollars and GitLab Premium at 29 US dollars per user per month billed annually, with all three tiers available for self-managed installations. Ultimate is custom priced, and the supplied facts do not give public pricing for Gitea Enterprise, so ask both vendors for written quotes covering your exact user count.
GitHub Enterprise Server, GitLab and Gitea are all self-managed, so the saving is in the software and support model, not in where the servers sit. Every option still needs hardware or virtual machines, storage, backups, patching and staff time, and none of them removes those costs. Ask the vendor or your own environment to confirm the hardware sizing that applies to your license count, since GitHub Enterprise Server appliance sizing is tied to that count. Also check the expected Actions and CI workload, because self-hosted runners and build storage often become the largest recurring item after licenses.
The recurring costs to model are the per-seat fee, the paid subscription if you choose one, storage growth from repositories, packages and artifacts, and the upgrade effort for each release cycle. The one-time costs are migration of issues, pull requests and reviews, which needs a platform importer rather than a plain Git clone, plus integration work and staff training. Before comparing totals, confirm your data volume per repository, your API usage for bulk export and whether your team needs GitHub Actions compatibility, since Gitea Actions is designed to be compatible with GitHub Actions while Forgejo Actions is not.
Which cost components appear on each side and whether they recur
This table lists each cost component on the GitHub Enterprise Server side and the self-hosted GitLab or Gitea side, marks whether it is one-time or recurring, and names what drives it. Use it to build a quote request, since no prices are published here and every figure must come from your own vendor quotes, invoices and hardware estimates.
| Cost component | Who is paid or who pays | One-time or recurring | What drives it |
|---|---|---|---|
| GitHub Enterprise per-user licenses | GitHub (through Microsoft or a reseller), per named user | Recurring | Licensed user count, contract term and any true-up at renewal; request the order form and renewal invoice |
| GitHub Enterprise Server appliance hardware | Your infrastructure team or hardware vendor | One-time purchase or recurring if cloud-hosted | Sizing from license count plus the 25 percent headroom for Actions; confirm sizing with GitHub's documentation |
| Blob storage for artifacts and Actions data | Your storage provider | Recurring | Retention settings, artifact volume and growth; confirm the storage layout in your appliance setup |
| Appliance upgrades and downtime | Your internal staff or a services partner | Recurring | Frequency of feature releases and maintenance windows; GitHub Enterprise Server feature releases are supported for about a year |
| GitLab or Gitea infrastructure | Your cloud provider or data center | Recurring for compute and storage, one-time for setup | Reference architecture chosen, user count and high availability requirements; GitLab recommends high availability for 3,000 or more users |
| Optional vendor subscriptions | GitLab (Premium or Ultimate) or CommitGo (Gitea Enterprise) | Recurring, per user for GitLab Premium | Tier needed for SSO, audit logging, compliance or security scanning; request a written quote for the tier you need |
| Migration of repositories and metadata | Your internal staff or an implementation partner | One-time | Repository count, size, issues and pull request volume, and API rate limits on bulk exports; scope it in writing |
| Implementation and hardening | Your internal staff or an implementation partner | One-time, with optional recurring retainer | Integration with identity, CI runners, backups and compliance evidence; agree deliverables before work starts |
| Internal staff to operate the platform | Your payroll or contracted operators | Recurring | Number of instances, upgrade cadence, on-call expectations and support tier; ask for effort estimates from each vendor or partner |
What the license line buys on each side
The GitHub Enterprise Server line item is a per-user license bought through GitHub Enterprise, but the license is only one input to the total. The product runs as a virtual appliance on your own infrastructure, so the hardware, storage and upgrade work sit with your team even though the license is per user. Before you compare figures, confirm in writing with GitHub which license entitlements apply to your user count, whether Actions usage is covered, and which appliance sizing applies to your release line. The GitHub Enterprise Server releases page is the starting point for checking which feature releases are current.
GitLab splits its offer into a free core and two paid tiers, and the license boundary follows the code. Content outside the ee/ directory is MIT licensed, so the core forge carries no license fee. The GitLab pricing page lists Premium at 29 US dollars per user per month billed annually, with advanced CI/CD and priority support. The Ultimate tier is custom priced and adds application security testing, software supply chain security, vulnerability management and compliance features. Map the features your teams use against these tiers before you assume that a paid subscription is needed for everyone, and confirm whether the ee/ features you depend on are included in Premium.
Gitea is MIT licensed, so the core platform has no license fee. CommitGo, Inc. sells Gitea Enterprise, which adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. Forgejo is GPL-3.0-or-later from v9.0 and MIT for earlier versions. The supplied facts do not list a paid Forgejo edition, so confirm with the project and any third-party support providers what commercial support exists. For any subscription, get in writing the covered versions, response commitments, whether upgrades and security patches are included, and what is excluded.
What moves the GitHub Enterprise Server comparison up or down
Most of the difference between GitHub Enterprise Server and a self-hosted forge comes down to a handful of sizing inputs. Each card below names one driver, the direction it pushes cost, and what to confirm before comparing quotes or hardware plans.
User count sets license and sizing
Per-user Enterprise licenses scale directly with headcount, so every added seat adds recurring license spend on the GitHub side. On the GitLab side, user count sets the reference architecture size, which runs from 1,000 users at 20 API requests per second up to 50,000 users at 1,000 API requests per second. Ask the vendor for the license count you would buy, then map that same count to a GitLab reference architecture and its hardware or VM footprint.
High availability at 3,000 users
GitLab's documentation generally recommends a high availability strategy once an instance reaches 3,000 or more users. That strategy uses Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul, so it adds more nodes, more monitoring and more operator time. Above this threshold, the infrastructure line grows faster than the user count. Confirm your uptime target and whether your team can run these components before you size the cluster.
Repository and data volume
GitHub recommends keeping a repository's .git folder under 10 GB, so large monorepos and binary-heavy histories push storage and backup needs up on any self-managed forge. Repository growth also raises the time for backups, restores and migrations. Before estimating storage, measure your largest repositories and the total size of Git LFS or attachment data, then price disk, backup copies and retention against that measured figure.
Regional data residency requirements
If your regulator or contracts require data to stay in a specific country or region, hosted options may not cover every plan and region. GitHub Enterprise Cloud with data residency offers selected regions, and Azure DevOps keeps tokens and SSH keys in a US datacenter. Self-hosting in your own data center or cloud account removes this dependency, but it moves storage, encryption and backup costs onto your team. Confirm the required regions with legal before comparing hosted and self-managed prices.
Edition and feature tier choice
Costs change sharply with the edition you choose. GitLab Free and Premium are priced per user, while Ultimate is custom priced, and Gitea Enterprise and Forgejo support come from different vendors or governance models. Advanced CI/CD, security scanning, SAML and audit logging may sit in paid tiers on some platforms but not others. List the features you actually use today, then request quotes only for the tier that covers them.
Internal platform skills and upgrade capacity
The cost of a self-hosted forge depends on who operates it. Someone must patch the platform, plan upgrade stops, run backups and restores, and handle CI runners, which is ongoing labor that a per-user license otherwise covers. GitLab requires passing through defined upgrade stops, and GitLab maintains only a few recent minor lines. Count the engineering hours your team can commit each month, and ask any implementation partner to quote the operations work separately from the initial build.
How to build the cost model with your own numbers
This sequence turns your current GitHub Enterprise Server spend into a comparable model against self-hosted GitLab, Gitea or Forgejo. Each step names the inputs, the owner and the check that shows the input is ready. The output is a three to five year cost view that finance and platform leads can review together.
Count named and active users
Pull the named user count and the active user count from your identity provider and from the license usage your GitHub Enterprise Server instance reports. Platform and security leads should do this together, because license terms and active use can differ. Export the figures by month across your current license term so peaks and leavers are visible. The step is done when you have one table of named users, active users and contractors, with the source of each number written beside it.
Export current license and invoices
Collect the current GitHub Enterprise license agreement, the order form for each renewal, and the invoices for the appliance hosts, storage and backup systems that run the instance. Ask your account team for the license count and the terms on how seats are counted, including any Actions or add-on charges. Finance and procurement should own this, with a platform engineer confirming which hardware lines belong to the appliance. The step closes when every recurring line has a date, a currency and a quantity you can reconcile to the license count.
Size hardware with the Actions allowance
Start from the appliance's current CPU, memory, storage and host count, then apply the 25 percent Actions allowance in the current sizing model. Compare the result with the hardware you already own, so you price only the gap. Platform engineering does this and records the sizing basis in writing. The step is done when you have a host specification, an owned or purchase flag for each line and a total hardware figure you can carry into the model.
Price blob storage and backups
Work from your repository and artifact data volume, including Git history, LFS objects, packages and Actions logs, and estimate growth from your most recent export. Price the blob storage that holds those objects and the backup copies needed to restore them, in the same currency as your licenses. Infrastructure teams usually own storage and backup, and they should confirm retention rules and replication. The step is done when storage and backup appear as two separate lines, each with a unit cost from a quote and a stated retention assumption.
Model GitLab Premium per-user subscriptions
Build a subscription scenario for GitLab Premium using the public list price of 29 US dollars per user per month, billed annually, from the GitLab pricing page as a reference point only. Multiply that figure by the named user count from step one. Add a second line for the top tier, which is custom priced, and leave a placeholder for your quote. Also note which groups could stay on Free, which costs zero dollars. The step is done when each scenario shows an annual subscription total with its assumptions stated.
Add migration and staff time
Add one-time lines for migration work, such as importer runs, CI pipeline rewrites, runner setup, identity integration and user training. Add recurring lines for operating staff, support, upgrades and backup checks. For GitLab, include time to plan the required upgrade stops listed in its upgrade paths documentation. For Gitea or Forgejo, include upgrade time and any commercial support you choose. Engineering managers, with finance, should agree the internal cost per hour. The step is done when one-time and recurring totals are separated and each line has an owner.
Run a three to five year view
Place the one-time and recurring lines across a three to five year horizon and show each option side by side: the GitHub Enterprise Server appliance with its renewals, against GitLab subscriptions plus hosting, or Gitea or Forgejo plus any support you select. Hold assumptions constant across options, then vary user count and storage growth to see which inputs move the totals most. Finance should review the sensitivity table with platform leads. The step is done when the model shows a cumulative cost per year for each option and names the two inputs that change the answer most.
Replace placeholders with written quotes
Replace every placeholder with a figure from a written quote or invoice before the model informs a decision. Ask GitHub, GitLab, any Gitea or Forgejo support provider and your hardware and storage vendors for itemized quotes that state scope, term, currency and inclusions. Mark each line as quoted, invoiced or estimated so reviewers can see which figures are firm. DeployOpen does not publish prices, so any implementation or migration line should come from a written scope. The step is done when no line depends on an assumption that is not labeled.
Three self-hosted cost shapes: free software, paid subscription or managed service
GitLab Community Edition is MIT licensed for the code outside the proprietary ee/ directory, and the GitLab pricing page lists the Free tier at 0 US dollars per user per month, with self-managed installations available on all three tiers. The software license is therefore not the main cost. You pay for the servers, storage, network, staff time and any third-party tooling you add, and you carry the full operating burden.
- Infrastructure: You provision the hosts, storage and load balancing, using the Linux package, Helm chart, Operator, Docker or source installation methods described in GitLab's installation documentation.
- Upgrades: You follow the yearly major and monthly minor cadence and the required upgrade stops, so upgrade planning is a recurring internal task.
- Security fixes: Only the current stable release gets bug fixes, while security fixes are backported to the previous two monthly releases, so you need a rhythm for staying current.
- Backups and high availability: You design and test backup and restore, and for larger user counts you run the high availability components yourself.
- Runners and feature gaps: Advanced CI/CD and the security and compliance features sit in paid tiers, so you need to decide which capabilities you build or buy elsewhere.
Ask your team to estimate operating hours for upgrades, backup testing and on-call coverage, because these recur every year even when the license cost is zero.
A GitLab subscription keeps the same self-managed deployment model but adds a recurring license fee per user. The GitLab pricing page lists Premium at 29 US dollars per user per month billed annually and Ultimate as custom priced. Premium adds advanced CI/CD and priority support, while Ultimate adds application security testing, software supply chain security, vulnerability management and compliance features. You still run the infrastructure, so the subscription changes what you pay for, not who operates the servers.
- License fee: Premium is billed per user, so the annual amount scales with seat count; Ultimate requires a quote from GitLab.
- Support: Priority support is part of Premium, so response expectations and escalation paths should be written into your agreement.
- Security features: Scanning and compliance features in Ultimate may replace separate tools you already license, which should be compared line by line.
- Still self-run: Upgrades, backups, runners and high availability remain your responsibility under either tier.
- Ask for: A written quote covering seat count, billing term, support level, renewal uplift and what happens to the subscription if you reduce seats.
Confirm current per-user pricing and any volume terms directly with GitLab, because the page may change and enterprise agreements can differ from list prices.
Gitea and Forgejo are both self-hosted forges that you can run without a license fee. Gitea is MIT licensed and sold with commercial support from CommitGo, which offers Gitea Enterprise with SAML 2.0 support, audit logging, IP allowlisting and mandatory two-factor authentication. Forgejo is GPL-3.0-or-later from v9.0 and has no equivalent paid edition described in the sources, so its cost is software-free and infrastructure-driven. Gitea is also offered as Gitea Cloud, a managed service, so you can move the operating burden to the vendor if you accept hosted data.
- Free software: Installing Gitea or Forgejo costs nothing in license terms, leaving servers, storage and staff as the main costs.
- Optional subscription: Gitea Enterprise adds a per-organization or contract cost that you must quote with CommitGo, and it covers the features listed above rather than the whole platform.
- Managed option: Gitea Cloud shifts hosting and maintenance to the vendor, with a service fee and a different data location, so check where repositories and backups reside.
- Still yours: Unless you choose the managed option, you own upgrades, backups, runners and database operations on your chosen database.
- Ask for: Written scope for Gitea Enterprise features, support response terms, and which data locations and backup responsibilities apply under Gitea Cloud.
Confirm current Gitea Enterprise and Gitea Cloud terms directly with the vendor before comparing them to your appliance renewal.
What a migration costs in effort before the savings start
Moving source hosting is two different jobs: moving Git history and moving the collaboration data around it. Git history moves between any two forges with a clone or mirror, so the repositories themselves are the easy part. Issues, pull requests, reviews and wikis do not travel that way and need a platform importer. GitLab can import projects from GitHub, and its import documentation also covers Gitea and other GitLab instances, so a GitHub source has a direct path. Gitea's migration code includes a GitHub importer as well. Forgejo's dump-repo and restore-repo commands export and load issues, pull requests, releases, labels, milestones, comments and wikis. Before you commit to a target, run a trial import of a representative repository and compare what arrived with what you exported. Check reviewer assignments, attachments and links between issues and commits, since these are the items that most often fail to map cleanly.
Pipelines are usually the largest rework item, and they are not covered by an importer. GitHub Actions workflows need to be rewritten for GitLab CI/CD, where the syntax, runners and variables differ. Gitea Actions is designed to be compatible with GitHub Actions, so existing workflows have the best chance of running with limited changes, though you should still test each workflow and its third-party actions. Forgejo Actions is familiar to GitHub Actions users but is not compatible, so its workflows also need edits. Inventory every workflow, the reusable actions it calls and the self-hosted runners it depends on before choosing a target, because that inventory sets the size of the rework.
Plan the export itself around API limits. GitHub allows 5,000 REST requests per hour for personal access tokens, so a bulk export of a large organization can take many hours of waiting if it runs under one token. Spread the work across tokens or service accounts that your organization is permitted to use, and schedule large exports outside working hours. Confirm the current limits in GitHub's documentation for your account type before you estimate the window. Staff time for mapping users, reconciling authors and checking results is the cost that recurs in the migration plan, and it grows with the number of repositories and the amount of review history you keep.
Questions buyers ask before comparing costs or hiring help
How much does moving from GitHub Enterprise Server to GitLab or Gitea cost?
The cost is the sum of several components, and only some of them are paid to a vendor. Expect one-time costs for planning, migration, integration with your identity provider and CI runners, and hardening, plus recurring costs for infrastructure, staff time and any optional subscription. Gitea and GitLab Community Edition software is free to download, so the license line is often the smallest item. Costs rise with user count, repository volume, the number of CI integrations, and how much history and metadata must move. Ask any quote to list each component separately: software and subscription, infrastructure, migration labor, testing, cutover support and ongoing operations. The GitLab pricing page lists Premium at 29 US dollars per user per month billed annually, which you can use as a reference point when you compare subscription tiers.
Can our own team migrate from GitHub Enterprise Server without outside help?
Yes, many teams can, provided they have engineers who have run Linux servers, databases and backup tooling in production. The work includes standing up the platform, configuring authentication, moving repositories and metadata, rebuilding CI, and testing restores. Git history moves with a clone or mirror, but issues, pull requests and reviews need a platform importer. GitLab can import from GitHub directly, and Gitea's migration code includes a GitHub importer. The harder parts are usually the workflows, self-hosted runners, webhooks and integrations that depend on GitHub-specific behavior. Outside help makes sense when the team lacks capacity, when the cutover window is short, or when you need an independent review of the design. DeployOpen plans, implements and hardens these systems under a written, fixed-scope agreement, so the scope and deliverables are known before work starts.
How long does a GitHub Enterprise Server migration take?
Duration depends on drivers you can measure in your own environment, and no general figure is supplied here. The main drivers are the number of repositories and users, total repository size, the volume of issues, pull requests and wiki content, the number of Actions workflows to rebuild, how many integrations depend on GitHub APIs, and the number of approvals your change process requires. API rate limits also matter for bulk export: GitHub allows 5,000 REST requests per hour for personal access tokens, so large exports need planning or a GitHub App-based approach. Run a pilot on a representative set of repositories to measure real throughput, then ask any proposal to tie its timeline to the pilot results and to named milestones.
What skills does our team need to run GitLab compared with Gitea or Forgejo?
Gitea and Forgejo are lighter to operate, while GitLab has a broader component footprint. For Gitea or Forgejo, your team needs Linux administration, a supported database such as PostgreSQL, reverse proxy and TLS configuration, backup and restore practice, and CI runner management for Gitea Actions or Forgejo Actions. For GitLab, add experience with PostgreSQL, Redis, Gitaly and object storage, and understanding of the reference architectures. GitLab documents that stateful components such as PostgreSQL and Redis are not supported inside Kubernetes in the Cloud Native Hybrid pattern, so plan VM or managed-service hosting for them. Confirm the staffing model you need with your vendor or implementation partner, and check that someone owns each upgrade cadence.
Do we have to buy a paid subscription to run GitLab, Gitea or Forgejo?
No. GitLab Community Edition is MIT licensed, with code under its ee/ directory licensed separately, and Gitea and Forgejo are open source with no required subscription. A paid tier is optional. GitLab Premium and Ultimate add features and vendor support, and Gitea Enterprise, sold by CommitGo, adds SAML 2.0 support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. Forgejo has no paid edition from its project. Decide which features you need first, then check whether a free tier covers them. Confirm current tier contents on each vendor's pricing or product page, because feature placement changes over time.
What recurring work comes after the migration is complete?
Recurring work usually includes upgrades, security patching, backups and restore tests, monitoring, runner maintenance and user administration. GitLab ships a major release yearly, a minor release monthly on the third Thursday, and patch releases twice a month, and it requires upgrades to pass through required upgrade stops at versions such as 18.2, 18.5 and 18.8. Bug fixes are backported only to the current stable release, while security fixes also reach the previous two monthly releases, so plan upgrades to stay current. Forgejo stable releases get three months of full support, and its LTS releases get one year and three months of critical fixes. Ask any quote to state who performs each recurring task and how often.
How do we get a fixed-scope quote for this migration?
Start by writing down the scope: the number of users, repositories, total repository size, organizations, Actions workflows, integrations, identity provider, compliance obligations, and whether the environment is air-gapped. Share the current GitHub Enterprise Server version and your appliance sizing. Then ask for a written scope listing deliverables, assumptions, exclusions, acceptance criteria and a timeline tied to milestones. DeployOpen does not publish a price list. A quote follows from the written scope, and most engagements are fixed-scope, agreed in writing before work begins. Ongoing support, upgrades and continuous testing are available as separate retainers, so ask for those to be priced apart from the migration.
Which items should we confirm with the vendor before we decide?
Confirm the items that change cost or risk and that the public documentation may not settle for your case. Check whether the features you rely on, such as SAML, audit logging, merge controls, package registries or Actions compatibility, are in the free edition or a paid tier. Confirm the supported upgrade path from your current GitHub Enterprise Server release, the database and storage requirements for your user count, and the air-gapped installation method if you need it. For Forgejo, confirm the upgrade path from your Gitea version, since Forgejo documents a transparent upgrade from Gitea up to v1.22 in two steps. For GitLab, confirm reference architecture sizing with the vendor before you buy hardware, because high availability is generally recommended from 3,000 users.
How DeployOpen scopes a fixed-price GitLab or Gitea move
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source forges inside your own cloud accounts, data centers or air-gapped networks. For GitHub Enterprise Server cost vs self-hosted GitLab and Gitea, we start by agreeing in writing what the move covers, then build and hand over the platform so your team can run it.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We inventory repositories, pull requests, reviews, issues, wikis and CI pipelines that must move to the target forge.
- We confirm which GitHub Enterprise Server integrations, runners and single sign-on settings need replacements.
- A quote follows from the written scope, so ask for each cost component to be listed separately.
How we build
- We install and size the chosen platform in your environment, including database, storage and runner components.
- We test migrations of sample repositories and their history, then verify issues, reviews and labels arrive intact.
- We configure authentication, branch protection, backups and access controls to match your existing policies.
- We check air-gapped or restricted-network requirements when those apply to your environment.
How we hand over
- We document the installation, configuration, upgrade path and backup and restore procedures for your own staff.
- We deliver a cutover plan covering repository freeze windows, redirects for links and developer onboarding steps.
- We prepare evidence of configuration and controls that your auditors can review, without issuing any attestation ourselves.
- Your team receives a run book covering routine maintenance and the upgrade stops that the chosen platform requires.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainer scope, response expectations and upgrade work are agreed in writing, so you know what recurs each year.
- Security testing of the new forge and its CI integrations can be scoped as a separate fixed-scope engagement.
- Ask us to confirm which upgrade work and support tasks sit inside the retainer and which are billed separately.
