GitHub cost vs self-hosted Gitea, Forgejo and GitLab

GitHub cost is a per-seat and usage bill plus the hosting you may not see. Self-hosted Gitea, Forgejo or GitLab moves those costs onto your servers, backups, upgrades and staff time, so the answer depends on your user count and data.

On this page

Does self-hosting GitHub cost less? Start with your seat count and the components you pay for

Self-hosting usually moves cost out of per-seat and usage fees and into servers, storage, backups, upgrades and staff time, so the outcome depends on three numbers you can pull from your own records: how many users need write access, how many CI minutes and storage your pipelines consume, and how much repository and attachment data you hold. Start with your current GitHub invoice and separate the lines for seats (Team or Enterprise), Actions minutes and storage, and any GitHub Enterprise Server license. Those are the figures a self-hosted option has to beat, and only your own invoice can give them to you, because GitHub prices depend on plan, contract terms and usage. Ask your account team to confirm what your contract covers before you compare anything.

Gitea and Forgejo carry no per-user license fee in the sources reviewed for this page, so their recurring cost is infrastructure, backups, upgrades and the people who run them. GitLab is different: GitLab Free costs 0 dollars, while GitLab Premium costs 29 US dollars per user per month billed annually, according to the GitLab pricing page. For a 100-seat team (illustrative), that Premium list price alone would be 2,900 US dollars per month before infrastructure and staffing, so GitLab Free and Premium belong in separate rows of your model. Confirm with GitLab which features your team needs from Premium, such as advanced CI/CD and priority support, and whether you need a support contract for Gitea or Forgejo, because those are optional costs rather than license fees.

Model the one-time and recurring costs separately. One-time work includes migration, pipeline rewrites and integration with your identity provider. Recurring work includes compute, storage growth, backup testing, monthly or yearly upgrade cycles and on-call time. Ask any quote to itemize who is paid for each item, whether the migration is fixed-scope, and what happens to the estimate if your user count or CI usage grows. Write these answers into a single worksheet so the comparison stays honest when the next renewal arrives.

Which cost components move when you leave GitHub

This table maps each cost component of GitHub (seats, Actions, storage, Enterprise Server licensing) against the matching cost on a self-hosted Gitea, Forgejo or GitLab deployment, and marks whether each item is one-time or recurring. Take GitHub figures from your own invoice and the self-hosted figures from your own quotes, then compare line by line. The main takeaway is that licence fees are only one part of the total, and staff time and support often decide the result.

Cost componentGitHub sideSelf-hosted sideOne-time or recurring
Seats or licencePer-user GitHub Team or Enterprise seats, or a GitHub Enterprise Server licence, as shown on your invoiceGitea and Forgejo carry no per-user licence fee. GitLab Free is free, and GitLab Premium is priced per user, as listed on the GitLab pricing pageRecurring
Actions minutes and storageBilled Actions minutes and stored artifacts and packages, per your plan and usageRunner compute and storage you host; Gitea Actions and Forgejo Actions run on runners you operate, GitLab CI/CD on GitLab RunnerRecurring
Servers and hostingLargely absent for GitHub.com; present for GitHub Enterprise Server as virtual appliance hostingVirtual machines or Kubernetes capacity, sized by users, repository size and CI load, plus any load balancerRecurring
Storage and repository growthIncluded in plan limits; check repository and file size limits in GitHub's documentationDisk for Git data, LFS objects, package registries and attachments, which grows with history and binary filesRecurring
Backups and restore testingHandled by GitHub for the hosted service; your own export copies are a separate taskBackup storage, offsite copies and periodic restore tests for the database, Git data and attachments, which you ownRecurring
Upgrades and maintenanceHandled by GitHub for hosted use; GitHub Enterprise Server upgrades are scheduled by youUpgrade planning, staging tests and required upgrade stops for GitLab, plus Forgejo or Gitea version movesRecurring
Support contractIncluded in plan tier or enterprise agreement, as stated in your contractOptional vendor support: GitLab subscriptions, Gitea Enterprise from CommitGo, or a partner retainer; ask for scope in writingRecurring
Migration projectExport effort for Git history, metadata and Actions secrets, which do not exportImporters, mirroring, workflow rewrites, secret re-creation and user mapping; a fixed-scope projectOne-time
Internal staff timeAdministration of GitHub organizations, policies and billingOperating, patching, monitoring and on-call for the forge and its runners, which usually becomes the largest recurring itemRecurring

What moves the comparison most

Six drivers decide whether a self-hosted forge costs less than GitHub for your organization. Most of them are scale and risk factors that change the staff, hardware and support lines far more than the license line. Check each one against your own numbers before comparing quotes.

Number of users and GitLab tier

GitLab Free has no per-user license fee, but Premium is priced per user per month and is needed for advanced CI/CD and priority support. Count active users, not seats, and decide which features your teams actually require. Ask each vendor which features sit in each tier before assuming Free covers your workflow. Gitea and Forgejo carry no per-user license fee, so their cost depends on servers and support instead.

Repository and file size limits

GitHub recommends keeping a repository's .git folder under 10 GB and enforces a 100 MB file limit. Repositories that carry large binaries, model files or media assets will hit these limits on a hosted service and may push teams toward Git LFS or artifact stores. Self-hosting removes the hosted limits but adds storage growth, backup size and replication cost to plan for. Measure your largest repositories before sizing disks.

CI build volume and runners

Hosted CI is billed by minutes and storage, so heavy build volume is often the largest recurring line on a GitHub bill. Self-hosted CI shifts that cost to runner hosts, compute capacity and the staff who maintain them. Estimate peak concurrent jobs, average build duration and artifact retention before comparing. Gitea Actions and Forgejo Actions use runners you operate, and GitLab uses GitLab Runner, so runner sizing belongs in the quote.

Availability requirements

A single server is simple, but it is also a single point of failure for every team that pushes code. GitLab's reference architectures recommend a high availability strategy for 3,000 or more users, using Gitaly Cluster with Praefect, PostgreSQL with Patroni, Redis Sentinel and Consul. That layer adds several servers, monitoring and failover testing. Define recovery time and recovery point targets with your leadership before choosing an architecture.

Edition and support model

Gitea is MIT licensed with commercial support from CommitGo, and Gitea Enterprise adds SAML, audit logging and IP allowlisting for a fee. Forgejo is GPL-3.0-or-later from v9.0 and is community supported. GitLab Premium includes vendor support. Decide whether you need a contract with a named vendor, a partner such as DeployOpen, or in-house expertise, because that decision sets the recurring support line. Ask each vendor what its support covers and how long it commits to releases.

Existing team skills

Teams that already run GitHub Actions workflows, Linux servers and PostgreSQL can absorb a forge with less retraining. Teams without that experience will spend staff time on upgrades, backups and access control, which is often the largest hidden cost. GitLab upgrades require stops at defined versions, so an upgrade calendar and a tested rollback path belong in the plan. Inventory the skills you have before deciding how much you can run in house.

How to build the cost model with your own numbers

This sequence turns your current GitHub invoices and repository inventory into a like-for-like, fixed-period comparison against a self-hosted Gitea, Forgejo or GitLab edition. The result is a cost model you can defend in a renewal or budget discussion.

  1. Export current seat, Actions and storage invoices

    Finance and the GitHub organization owner pull the last twelve months of billing statements, covering seats by plan, Actions minutes consumed and any paid storage or package charges. Record each line item as a monthly figure so that one-time charges and recurring charges stay separate. The step is done when every line on the invoices maps to a row in a spreadsheet and the total matches the amount paid. Ask GitHub for the plan name and any enterprise agreement terms, since these change what is actually billed.

  2. Count active users and repositories

    The platform owner counts people who have committed, reviewed or pushed within a recent window, separately from paid seats that may sit idle. Count active repositories too, and flag archived, forked or stale ones that may not need migrating. Record which users need a platform account, because GitLab Premium pricing is quoted per user and the same headcount drives Gitea and Forgejo support decisions. The step is done when you have one active user figure and one migrating repository list that you can reuse in every candidate calculation.

  3. Size repositories, attachments and metadata

    Measure the size of each repository, including large files, Git LFS objects, release assets, package storage and the wiki. Note GitHub's documented limits, including the recommended 10 GB .git folder size and the 100 MB file limit, because repositories near those thresholds usually need extra handling during migration. Estimate the volume of issues, pull requests, comments and attachments per repository, since these are what a metadata export carries. The step is done when you have a total storage figure for Git data and a separate figure for attachments and metadata, which drives both server disk and backup sizing.

  4. Choose the candidate platform and edition

    Decide which forges to compare, for example Gitea, Forgejo, and GitLab Free or Premium, and whether each will run with a commercial support contract or without one. Check each candidate's license and support model in its documentation, including the GitLab tier features you actually need such as advanced CI/CD and priority support. Record the edition name and support tier for every candidate, because each one becomes a separate column in the model. The step is done when every candidate has a named edition, a licensing position and a support decision.

  5. Price infrastructure and backups from your rates

    Infrastructure leads and finance price servers or virtual machines, storage, load balancing, backups and any high availability layout using your own cloud or data center rates. GitLab's reference architectures scale by user count, so a larger headcount may require a different sizing tier and additional components. Include off-site backup copies and restore testing time, since backups are a recurring cost. The step is done when each candidate has a monthly infrastructure and backup line built from your internal rate card, with no vendor list price substituted.

  6. Add migration, upgrade and staff effort

    Platform engineers estimate the one-time migration work, including importer runs, verification of issue and pull request history, re-creating Actions secrets and rewriting workflows. Add recurring upgrade effort, including GitLab's required upgrade stops and Forgejo's upgrade path from Gitea, and the time to run security patches and backups. Plan the bulk export around API rate limits, such as GitHub's 5,000 REST requests per hour for personal access tokens, because mirror and metadata steps can take longer than their nominal effort suggests. The step is done when one-time and recurring staff hours are recorded separately for each candidate, using your own staff rates.

  7. Compare totals over a fixed period

    Finance and the platform owner set one fixed comparison period and total the GitHub spend against each candidate's one-time costs plus recurring costs across that same period. Run a sensitivity pass on user growth, storage growth and support tier, so the model shows which assumptions move the answer. Document every assumption next to its source, so a reviewer can trace each number back to an invoice, a rate card or a staff estimate. The step is done when you have a single comparison table, a list of open assumptions and a written quote request for any support contract, scoped to the same user count and repositories.

Where the self-hosted option is not a like-for-like saving

The first thing to check is whether the CI workflows you run on GitHub will run unchanged on the target forge, because that determines how much of the migration is configuration and how much is rewriting. Gitea Actions is designed to be compatible with GitHub Actions, according to the Gitea documentation, so teams with existing workflows should test them on a Gitea instance before costing the move. Forgejo Actions is not compatible with GitHub Actions, according to the Forgejo documentation, even though it is designed to feel familiar. Plan for workflow rewrites, runner changes and re-created secrets in the Forgejo case, and confirm each action your pipelines call against the target runtime rather than assuming parity.

GitLab's price points carry feature boundaries that the cost model must reflect. GitLab Free costs 0 dollars, while the GitLab pricing page lists advanced CI/CD and priority support under Premium at 29 US dollars per user per month billed annually, and application security testing, supply chain security, vulnerability management and compliance features under Ultimate, which is custom priced. Self-managed installations can use all three tiers, so the question is which controls your security and compliance team needs. Map each control your auditors or internal policies expect to a tier before comparing totals, and ask GitLab in writing which features are included in each tier for your deployment.

Two of the open-source options are not fully free to run at enterprise scope. Gitea Enterprise, sold by CommitGo, adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning, according to the Gitea Enterprise page. GitLab's source is open core, so code under the ee/ directory needs a paid subscription. Confirm which of your current GitHub controls depend on those features, and budget for them as recurring license cost rather than assuming Community or base editions cover them.

Costs teams forget on each side

Licence fees are the easy line to compare. The costs that surprise teams after a move sit in upgrades, backups, CI capacity, secrets and on-call time, and they land on both sides of the comparison. Use these cards as a checklist when you ask for a quote and build a three-year model.

GitLab required upgrade stops

GitLab requires upgrades to pass through defined stops rather than jumping between any two versions. Since GitLab 17.5 these fall at x.2, x.5, x.8 and x.11, for example 18.2, 18.5, 18.8, 18.11, 19.2, 19.5, 19.8 and 19.11. Each stop is a planned change window with testing, backup and rollback steps, so budget staff time for every stop, not only for the occasional major upgrade. Confirm with your implementation partner how many stops fall in your planning horizon.

Monthly minor releases and backports

GitLab ships a minor release on the third Thursday of each month and patch releases twice a month. Security fixes are backported to the previous two monthly releases, while bug fixes go only to the current stable release. Someone must read each release, schedule the upgrade and test it, or the instance drifts behind the supported line. Ask who owns that cadence and whether it is in your support retainer or your own staff time.

Backup and restore testing

A backup is only a cost saving if a restore has been rehearsed. GitLab's backup and restore documentation covers repositories, the database and other data, and a restore must be tested on separate hardware with the same version. Budget for storage that retains backups beyond the repository data itself, for a restore environment, and for a recurring test. For Gitea and Forgejo, include database dumps and repository data in the same test.

Runner capacity for CI

Hosted CI bills by minutes and storage, while self-hosted CI bills by the machines and the people who keep them running. GitLab Runner, Gitea Actions and Forgejo Actions each run jobs on runners you operate, so peak build hours set your server count, and cached dependencies and artifacts consume disk. Model your current GitHub Actions minutes against runner hours, and include the cost of build isolation and patching the runner hosts.

Re-creating Actions secrets

Secrets stored in GitHub Actions do not export with repositories or the organization migration archive. Each one must be re-entered on the new platform by someone who holds the original value, which means coordinating with the owners of cloud accounts, registries and deploy keys. Rotating credentials during the move is safer, but it adds work and can break deployments that still use old values. Inventory every secret and its consumer before cutover.

Commercial support from CommitGo

Gitea is MIT licensed, so the software itself has no licence fee, but production use often needs a support contract. CommitGo, Inc. provides leadership and commercial support for Gitea and sells Gitea Enterprise, which adds SAML 2.0, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. Ask whether those features are needed, price them against your GitHub Enterprise seats, and confirm the response terms in writing.

Staff on-call time

The largest recurring cost on any self-hosted forge is often people, not servers. Someone must answer when a runner queue backs up, a disk fills, a database fails over or a security patch lands. Name the team that carries the pager, decide whether a retainer covers after-hours response, and count that time against the GitHub seats and Actions spend you are replacing. Scale this effort with the number of users and the number of CI jobs.

Questions buyers ask about GitHub replacement cost

How much effort does moving from GitHub to a self-hosted forge take?

Effort depends mainly on how much metadata you must carry, how many repositories and workflows exist, and how many teams must change their habits. Git history moves with a clone or mirror, but issues, pull requests, reviews and wikis need a platform importer. Gitea's migration code includes a GitHub importer, GitLab can import from GitHub, and Forgejo's dump-repo and restore-repo commands carry issues, pull requests, releases, labels, milestones, comments and wikis. The larger items are usually Actions workflows, re-created secrets, webhooks, branch protection rules and access groups. Ask any implementation partner for a written scope that lists each of these categories before agreeing a price or timeline.

Can our own team migrate without outside help, and what skills do they need?

A small team with Linux administration, reverse proxy and TLS experience, PostgreSQL or MySQL operations, and CI runner experience can often run a pilot on its own. Gitea and Forgejo are lighter to install than GitLab, and Gitea runs on small systems. Plan for skills in backup and restore testing, identity integration, and mapping GitHub Actions to Gitea Actions or Forgejo Actions, which differ in compatibility. Production cutover, security hardening and compliance evidence usually need more experience than the install itself. If your team lacks these skills, ask a partner to name who performs each task and whether knowledge transfer is part of the written scope.

How does ongoing upkeep differ between Gitea, Forgejo and GitLab?

All three need regular patching, backup testing, database maintenance and runner management, but the cadence differs. GitLab ships a minor release monthly, a major release yearly, and requires upgrades to pass through required upgrade stops at versions such as 18.2, 18.5, 18.8 and 18.11, so upgrade planning is a recurring task. Forgejo stable releases receive full support for three months plus a two-week window, while LTS releases receive one year and three months of critical and security support, so choosing an LTS line affects how often you must upgrade. Gitea releases follow its own line, and Forgejo documents upgrades from Gitea up to v1.22. Ask each vendor or partner for the upgrade calendar you will follow.

When does a paid support contract make sense?

A paid support contract makes sense when an outage or security issue would cost more than the contract, when no internal staff can cover on-call duty, or when auditors or procurement require a named support path. Gitea offers commercial support and Gitea Enterprise through CommitGo, which adds SAML 2.0, audit logging, IP allowlisting and mandatory two-factor authentication. GitLab Premium includes priority support, and Ultimate adds security and compliance features. Forgejo is community governed and has no vendor support tier in the sources reviewed, so confirm any third-party support options directly. Compare these contracts with the cost of your own on-call rota before deciding.

How long does it take to build a sound cost model?

A sound cost model usually takes longer to build than the software takes to install, because it needs an inventory of your current seats, Actions minutes, storage, API use and integrations. Gather one to two weeks of GitHub usage data, your current license terms, and a list of who will operate the platform. The model must then price each component: infrastructure, storage, backups, upgrades, support and staff time. Treat any duration you see from a vendor or partner as a starting point and ask for it to be tied to a written scope, since your repository count and workflow complexity will drive the result.

What drives the cost of self-hosting a forge up or down?

The main drivers are the number of users, the total repository and artifact storage, how often CI jobs run and how many runners you operate, and how many high availability components you require. GitLab's reference architectures scale from 1,000 users at 20 API requests per second to 50,000 users at 1,000 requests per second, and the documentation recommends a high availability strategy for 3,000 or more users, which adds Gitaly Cluster, PostgreSQL with Patroni, Redis Sentinel and Consul. Gitea and Forgejo can run on much smaller footprints, so the same user count often costs less to host. Also consider whether you need EU or other regional hosting, and whether GitLab Premium seats are required for your features. Confirm each driver with your own usage data before comparing totals.

Does a self-hosted forge cost less than GitHub Enterprise Server?

It depends on the features you need, the people who operate it and the seats you would otherwise pay for. GitHub Enterprise Server is licensed per user and run as a virtual appliance, so the license is one recurring line item. Open-source forges remove the per-seat license but add server, storage, backup, upgrade and staff costs, plus any support contract you choose. GitLab Free costs 0 dollars and Premium costs 29 US dollars per user per month billed annually, according to the GitLab pricing page, so GitLab cost depends heavily on which tier you need. Build the comparison from the same user count, the same storage and the same staff hours, and ask GitHub and any partner for written quotes.

How Gitea, Forgejo and GitLab Free and Premium differ on cost

Gitea is MIT licensed, so the core forge carries no software license fee. Your cost is the server, storage, backups, the people who patch and upgrade it, and any support contract you choose. CommitGo, Inc. provides leadership and commercial support and 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. Gitea is also offered as Gitea Cloud, a managed service alongside self-hosted installs.

  • Core software: MIT licensed, so per-seat fees do not apply to the forge itself.
  • Gitea Enterprise: a paid tier from CommitGo, Inc. Ask CommitGo for the price in writing, with the specific features your controls require.
  • Gitea Cloud: a managed option that moves hosting and operations into a service fee. Confirm where data is stored before you choose it.
  • Self-hosted running costs: a small server can serve a modest team, but backups, TLS certificates, monitoring and upgrades recur every year and need named owners.

Before you compare quotes, list the audit logging, identity and branch protection controls your auditors expect, since those decide whether the Enterprise tier appears as a line item.

What the migration effort adds to the first-year cost

The one-time migration effort is the cost most often missing from a first-year comparison, and it is driven by how the data moves. Git history transfers with a clone or mirror of each repository, but issues, pull requests, reviews and wikis need a platform importer. Gitea's migration code includes an importer for GitHub, and GitLab can import projects from GitHub directly, so the question for your team is which importer carries which metadata into your target, and what gets left for manual handling.

Forgejo takes a different route. Its dump-repo command exports a repository from GitHub with issues, pull requests, releases, labels, milestones, comments and wiki, and restore-repo loads it into Forgejo. Ask your engineers to run a trial export on a few representative repositories and record what arrives intact. Those trial results, not vendor feature lists, are the basis for estimating effort. Expect the bulk of the work in several places: the number of repositories, the volume of issues and review comments per repository, conversion of GitHub Actions workflows into the target's CI, and re-creating secrets, which do not export.

Each of these drivers scales with your inventory. Count repositories by owner and activity, then sort them into migrate-as-is, archive and retire groups. Measure metadata volume for the active set, and list every workflow and every secret that a pipeline depends on. Ask any internal or external party quoting the work to price each driver separately, state which importer or command they will use, and name the items they will handle by hand. Treat these as one-time costs in the first-year total, and keep a separate line for the parallel running period while both platforms are live.

How DeployOpen scopes a fixed-scope cost and migration engagement

DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own infrastructure. For a GitHub cost review, we start from a written scope that sets out which platform, which environment and which deliverables are in play before any work begins.

How we scope

  • Inventory the current GitHub seats, Actions minutes, storage and any GitHub Enterprise Server license so the cost baseline is documented.
  • Agree in writing whether the target is Gitea, Forgejo or GitLab Free or Premium, and which features each team actually depends on.
  • Define the migration boundary, including repositories, issues, pull requests, wikis, Actions workflows and secrets that must be re-created.

How we build

  • Size the self-hosted servers, database, storage and backup targets for your user count and repository volume inside your own cloud or data center.
  • Configure authentication, branch protection, CI runners and package registries to match the access rules your teams use today.
  • Test repository imports, dump and restore runs and rate-limited bulk exports against a staging copy before any production cutover.

How we hand over

  • Deliver installation, configuration and operating runbooks that your platform team can follow without DeployOpen present.
  • Document backup, restore and upgrade procedures, including required upgrade stops for GitLab or the Forgejo upgrade path from Gitea where it applies.
  • Provide a cost model that lists one-time and recurring components, so your finance and procurement teams can check the quote against it.

How we support

  • Ongoing support, upgrades and continuous security testing are available as a retainer after handover, scoped separately in writing.
  • Security testing of the new forge, its runners and its APIs can be scoped to confirm hardening before teams rely on it.
  • Ask any vendor or DeployOpen quote to show which items are fixed, which depend on usage and which recur each year.

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.