Which fits your team: GitHub or self-hosted Gitea
GitHub fits best when your team wants a managed platform with no servers to run, and when Actions, the GitHub marketplace and existing tooling already sit at the center of your workflow. Self-hosted Gitea fits best when you need the code and metadata on your own servers, when a seat or Actions bill has become hard to justify, or when a residency or lock-in rule makes hosting control the deciding factor. Neither answer is permanent, because repositories move with a clone or mirror and the platform metadata moves through an importer.
Four factors should decide it. First, hosting control: if policy requires that source, issues and pull requests stay inside your own cloud account or data center, GitHub's hosted service is out, and you should compare GitHub Enterprise Server against Gitea directly. Second, operating capacity: Gitea runs on a single small server with MySQL, PostgreSQL, SQLite or MSSQL, but someone must own upgrades, backups, TLS, and restore tests. Third, Actions and integration needs: Gitea Actions is designed to be compatible with GitHub Actions, yet you must check each workflow, runner and third-party action your pipelines depend on, and re-create secrets, since they do not export. Fourth, commercial support: ask whether your auditors or internal policy expect a vendor contract. CommitGo offers commercial support and Gitea Enterprise adds features such as SAML 2.0 service provider support and audit logging; GitHub Enterprise carries its own support terms. Confirm current entitlements with each vendor.
Before you decide, run a short pilot. Migrate two or three representative repositories with their issues and pull requests, run your most important workflow on a Gitea Actions runner, and measure how long a restore takes from a backup. Ask each vendor for written terms covering support response, data location and license scope. If the answer depends on your environment, DeployOpen can plan and implement the self-hosted option in your own infrastructure under a fixed scope agreed in writing before work starts.
Which option fits which scenario
This table maps common buying scenarios to the platform that usually fits better and the condition that drives the choice. Read each row against your own constraints, since the reason depends on the condition stated in it. The main takeaway is that Gitea suits small, self-run forges well, while GitHub remains stronger where Marketplace breadth or a hosted vendor relationship matters most.
| Scenario | Better fit | Reason and condition |
|---|---|---|
| Small team on one server | Gitea | A single Gitea binary with a supported database such as SQLite or PostgreSQL can cover repositories, reviews, issues and packages on one modest host, provided your team can run backups and upgrades. |
| Regulated workload needing data on own servers | Gitea | Self-hosting keeps repositories, tokens and CI logs inside your own infrastructure, which matters when hosted regional options do not cover all data types. Confirm your assessor's evidence needs first. |
| Heavy reliance on GitHub Marketplace | GitHub | Gitea does not match the breadth of GitHub Marketplace actions and apps. If your pipelines depend on many third-party Marketplace integrations, check each one for compatibility before choosing Gitea. |
| Air-gapped network | Gitea | A self-hosted Gitea can run without reaching GitHub's hosted services, so the forge and its package registries live inside the isolated network. Plan how packages and updates reach the network. |
| Existing GitHub Actions workflows | Depends on workflow coverage | Gitea Actions is designed to be compatible with GitHub Actions, so simple workflows may run with little change. Workflows using Marketplace actions, GitHub-hosted runners or GitHub-specific features need testing. |
| Need a vendor support contract | GitHub | GitHub offers a hosted service and enterprise plans with vendor-backed support. Gitea offers commercial support through CommitGo, Inc. and a managed Gitea Cloud option, so compare the contracted terms of each before deciding. |
Where your code and metadata live under each model
Each option places repositories, issues, reviews and CI data in a different operator's hands, and that placement decides who can access them, where they are stored and which logs you can produce. The cards below set the GitHub hosted, residency, self-managed and Gitea options side by side so you can map each one to your own data residency and audit requirements.
GitHub.com hosted
Repositories, pull requests, issues and Actions run on GitHub's multi-tenant cloud, operated by Microsoft. You do not choose a storage region for the organization, and your data sits in GitHub's environment under GitHub's controls. Check which plan's audit log and SSO features you need, and confirm with GitHub where your data is stored before you sign off on residency. Your own evidence still has to show how access is granted and reviewed.
GitHub Enterprise Cloud with data residency
This option runs on GHE.com in the regions GitHub lists: EU, Australia, US and Japan. It narrows where data is stored, but the service is still operated by GitHub, so your team depends on GitHub's operational and access controls. Ask GitHub exactly which metadata, backups and Actions logs stay in the chosen region, and which support staff can reach them.
GitHub Enterprise Server on your infrastructure
GitHub Enterprise Server runs as a self-managed appliance in your own data center or cloud account, so repository data stays under your control. Your team then owns patching, backups, upgrades and the high availability design. Confirm which GitHub Enterprise Server release line you will run and how often you must move between releases, since that schedule sets your upgrade workload.
Self-hosted Gitea
Gitea installs on your own servers with MySQL, PostgreSQL, SQLite or MSSQL, so repositories, issues, packages and Gitea Actions logs remain in databases and storage you operate. You choose the network zone, backup targets and retention rules. Identity can be connected through the SAML 2.0 service provider support in Gitea Enterprise, and audit logging, IP allowlisting and mandatory two-factor authentication are also Enterprise features to confirm against your requirements.
Gitea Cloud as a managed option
Gitea Cloud is a managed service that keeps Gitea's software model but moves hosting and operations to the vendor. It suits teams that want Gitea's workflow without running servers, yet the data location, backup schedule and access staff become contract terms. Ask for the hosting region, encryption at rest, backup retention, and whether SAML, audit logs and IP allowlists are included in the offering you buy.
What Gitea's MIT license and Gitea Enterprise change
Gitea is released under the MIT license and written in Go, so the core forge can be installed, modified and run inside your own infrastructure without a per-seat subscription to Gitea itself. The license question for most buyers is therefore not whether the base product is free to use but who supports it and which controls sit behind a paid tier. CommitGo, Inc. provides leadership and commercial support for Gitea and sells Gitea Enterprise. Before you rely on either the MIT license or a support contract, ask CommitGo and your legal team to confirm the terms in writing, including what the license covers for your deployment model and how support is scoped and priced.
Gitea Enterprise adds controls that regulated teams often need to evidence. The main additions are SAML 2.0 service provider support for federated sign-in, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. SAML matters if your identity provider is the source of truth for access. Audit logging matters if you must show who changed permissions or repository settings. Organization-level branch protection inheritance matters when many repositories must share one set of merge rules. IP allowlisting and mandatory two-factor authentication matter for access restrictions in an assessment. Dependency scanning matters if you do not already run a separate scanner in CI. Check each item against the current Gitea Enterprise page and confirm which controls ship in the version you intend to run.
On the GitHub side, the comparison is between GitHub's Team and Enterprise plans, which are priced per user, and GitHub Enterprise Server, which is licensed per user and run as a self-managed appliance. Cost and entitlement terms differ by edition and change over time, so the reader should obtain current figures from GitHub's sales team rather than from third-party summaries. For Gitea, the recurring cost is the support contract, if you buy one, plus the servers, storage, backups and staff time you already carry for any self-hosted system. Ask CommitGo for a quote that states the support scope, response expectations, which Enterprise features are included, whether the license is perpetual or term-based, and what happens to the deployment if the subscription lapses.
What GitHub costs versus running Gitea yourself
GitHub cost is mostly a recurring subscription that scales with seats and usage, while Gitea cost is mostly infrastructure and people that you control. Each card below names one cost component, whether it is one-time or recurring, what moves it, and what to ask for before you compare totals.
GitHub seats and plan tier
Your GitHub bill starts with a per-user subscription for each plan tier your organization uses, and it recurs for as long as those seats are active. Cost rises with headcount, contractors who hold seats, and any move to a higher tier for features such as SAML single sign-on or audit logs. Ask GitHub for a written quote for your exact seat count and tier, and check which features your team needs before comparing. Gitea itself has no per-seat charge, so the same users cost nothing in licensing on the Gitea side.
GitHub Actions minutes and storage
Usage-based CI and artifact charges are the component most teams underestimate. Minutes, larger runner sizes, and stored artifacts or packages are billed beyond included allowances, so the total moves with build frequency, matrix size, and retention settings. On Gitea, the equivalent work runs on runners you host, so the cost becomes compute you already pay for. Pull the last three months of Actions usage from your GitHub billing report and use it as the baseline when you size runners.
GitHub Enterprise Server license
If your organization runs GitHub Enterprise Server on its own hardware, the license is a recurring charge on top of the infrastructure you operate. Ask whether the quote covers support, the number of users, and renewal terms. This line is what Gitea replaces in a self-managed move, but Gitea is not free of cost, so compare it against the infrastructure, support, and staff lines below rather than against zero.
Servers, storage and backups
Self-hosting moves compute, storage, and backup costs onto your budget, and they recur monthly or yearly depending on whether you run in your own data center or a cloud account. Repository size, LFS objects, package storage, and retention periods drive the total. Plan for a separate backup target, restore testing, and disk growth. Ask your infrastructure team to price the Gitea server, database, runners, and backup copies as separate lines so you can compare them with the hosted storage charges.
Upgrades, monitoring and support contract
Upgrades, security patching, uptime monitoring, and an optional commercial support contract recur over the life of the server. Gitea offers commercial support and an Enterprise edition from CommitGo, Inc., and the Enterprise features include SAML 2.0 service provider support, audit logging, and mandatory two-factor authentication. Decide whether you need a support contract with a response commitment, then ask CommitGo for a written quote that lists included features, support hours, and the term. If you skip the contract, budget internal time instead.
One-time migration and internal staff time
Migration costs are mostly one-time: moving repositories, importing issues and pull requests, recreating Actions secrets, converting workflows, and retraining users. Staff time for ongoing administration, on-call coverage, and capacity planning recurs. Staff time is the largest and least visible line, so estimate it in hours per month for your team and price it at your own loaded rates. Ask any migration partner for a fixed-scope written proposal that lists the deliverables and the cutover plan before you commit.
How a move from GitHub to Gitea runs
The sequence turns a GitHub organization into a self-hosted Gitea instance with repositories, issue and pull request history, and CI workflows in place, and leaves GitHub read-only or retired once every team has confirmed its work.
Inventory repositories, users, teams and workflows
Before touching any server, list every repository in scope, its size, its open issues and pull requests, its branch protection rules, its webhooks and integrations, and the Actions workflows that build, test or deploy it. Record which users and teams own each repository, because Gitea maps accounts and permissions separately from GitHub. Your team owns this list, and the output is a signed-off inventory that tells you which repositories move, which are archived, and which integrations need a new endpoint. Ask your engineering leads to confirm that the list matches what teams actually use.
Set up and harden the Gitea server
Install Gitea on infrastructure you control, choose a supported database from MySQL, PostgreSQL, SQLite or MSSQL, configure TLS, backups, SSO and mandatory two-factor authentication policies, and decide whether you need Gitea Enterprise features such as SAML 2.0 or audit logging. Your platform or security team performs the work, often with a partner under a written scope. The check that closes the step is a test instance that passes your hardening baseline, restores from a backup, and accepts a test login through your identity provider.
Migrate metadata with the built-in GitHub importer
Use Gitea's migration form to import each repository from GitHub with a GitHub token that has read access to the source. The importer carries issues, pull requests and other metadata that the platform supports, so run it on a test instance first and compare results. Confirm which items are not carried over in your version, such as attachments or certain review details, and record them as manual follow-ups. The step is done when a sample of issues and pull requests in Gitea matches their GitHub counterparts in title, state, author and comments.
Mirror or clone Git history
Git history is not carried by the metadata importer alone, so push full history with a mirror clone of each repository, including all branches and tags. Run this close to cutover for repositories that still receive commits, and repeat the mirror push for the final sync. Developers should not rely on local clones pointing at GitHub after this point. The check is that each repository's branch and tag list and latest commit hashes match between GitHub and Gitea.
Move Actions workflows and re-create secrets
Copy workflow files from each repository's .github/workflows directory into Gitea Actions, because Gitea Actions is designed to be compatible with GitHub Actions but not every action, runner label or context behaves the same way. Set up runners on your own hardware, then re-create every secret and variable by hand, since GitHub does not export Actions secrets. Ask the owners of each secret to supply the value through a secure channel and rotate credentials where the old value was exposed. The step is complete when a representative build and deploy run passes on a Gitea runner with the new secrets.
Validate repositories, permissions and integrations
Test each migrated repository against the inventory: permissions for each team, branch protection rules, required reviews, webhooks to chat or deployment tools, and package or container registries if you use them. Ask a sample of developers to run their normal flow of branch, commit, pull request, review and merge. Record defects in a tracker and fix them before cutover. The check is a signed sign-off from the repository owners that the workflows they depend on work end to end.
Cut over DNS and update integrations
Point the Gitea hostname at the production server, update clone URLs in documentation, IDE configurations, deployment scripts and external services, and switch webhooks and OAuth applications to the new endpoints. Freeze pushes to GitHub for each repository during its final mirror sync so no commits land in the old location. Your team performs the change under a documented rollback plan. The step is done when the final mirror sync is confirmed and all integrations report successful events from Gitea.
Retire GitHub access and keep an archive
Once teams have worked on Gitea for a period you agree in advance, make the GitHub repositories read-only or archived, revoke tokens and third-party app grants, and remove members who no longer need access. Keep a final export of the GitHub data your records or compliance obligations require, and store it under your own retention policy. Confirm with your legal and compliance leads how long archives must be kept. The output is a closed-out GitHub inventory with a dated record of what was archived and who approved it.
Where Gitea falls short of GitHub and what to verify
The gaps between Gitea and GitHub matter most in three places: the size of the ecosystem around the platform, how far Gitea Actions matches GitHub Actions for complex workflows, and the operating work of keeping the server upgraded and backed up. None of these is a reason to avoid Gitea by default, but each one changes cost and risk depending on how your teams work. GitHub's Marketplace has a far larger catalog of third-party actions, apps and integrations than Gitea has, so any integration your teams depend on needs an explicit check before you commit. Ask which of your current apps have Gitea equivalents, which need a webhook bridge, and which you will simply stop using.
Actions compatibility is designed in, but it is not a promise that every workflow runs unchanged. The gap matters most for workflows that depend on specific runner images, hosted-runner features, marketplace actions that call GitHub-only APIs, OIDC trust relationships with cloud providers, or reusable workflows and environment protection rules that your pipelines rely on. In your pilot repository, copy your most complicated workflow, register a self-hosted runner, and run it end to end. Compare job logs, cache behavior, artifact handling, secret injection and deployment approvals with what GitHub produces. Confirm the current Actions feature list in the Gitea documentation against the specific syntax and actions your workflows use.
The operating burden is the gap most often underestimated. With self-hosting, your team owns every upgrade, database backup, restore test, TLS renewal, storage capacity plan and runner fleet. Gitea releases move quickly, so plan a recurring upgrade window and confirm that your backup covers repositories, the database, attachments, LFS objects, package storage and configuration together. Test a full restore on a separate host in your pilot and time it against your recovery objective. Also decide who answers at 2 a.m. and whether you need commercial support from CommitGo, which is a recurring cost to ask about in any quote. Record the results so the pilot gives you numbers from your own environment rather than assumptions.
Questions buyers ask before switching from GitHub to Gitea
How much effort does a switch from GitHub to Gitea take?
The effort depends mostly on how much you need to move and how many systems depend on GitHub. Moving Git history is the simple part, because any clone or mirror carries commits, branches and tags. The harder work sits in the surrounding pieces: issues, pull requests and reviews need Gitea's migration importer, Actions workflows must be checked against Gitea's runner setup, and every webhook, deploy key, bot and integration that points at GitHub has to be found and repointed. Teams with many repositories, heavy use of GitHub Apps, or a long list of required status checks will spend more time than a team with a few repositories and simple pipelines. Start with an inventory of repositories, integrations and workflows, then size the switch from that list.
Can a team migrate to Gitea without outside help?
Yes, a team with Linux administration skills and someone who owns the CI pipelines can usually do the core work in-house. Gitea's built-in migration form can pull repositories with issues, pull requests and other metadata from GitHub using a token, and the Gitea documentation covers installation for the supported databases. What in-house teams tend to underestimate is the operational layer: backups, upgrades, TLS, SSO, monitoring and restore testing. Outside help is most useful when the migration is large, when compliance evidence must be produced, or when the team has no spare capacity to run a new service alongside its normal work. DeployOpen plans, implements, hardens, backs up and documents self-hosted platforms in your own infrastructure under a written, fixed scope.
How long does a migration take, and what sets the timeline?
No fixed duration applies to every migration, because the timeline depends on the inputs rather than on Gitea itself. The main drivers are the number of repositories and their size, how much metadata must be migrated and verified, how many CI pipelines must be rebuilt, the number of integrations that need repointing, and how much of the work your staff can do in parallel with their current duties. Approval for a new hosting environment, security review of the server and sign-off on backup and restore tests often take longer than the technical steps. Ask any provider, including DeployOpen, for a written plan with milestones and acceptance criteria before work starts.
What does the work need from our internal staff?
Plan for named people in four roles: an owner who decides the cutover order and accepts the result, a platform or systems administrator who runs the server and its database, a CI owner who rebuilds and tests workflows, and a security or compliance contact who reviews access controls and evidence. Developers are needed to confirm that their repositories, branches and merge rules behave as expected after the move. The time each role needs depends on the number of repositories, pipelines and integrations. Staff time is a recurring cost after go-live as well, since someone must apply upgrades, watch backups and handle user requests, so the owner should be named before the project starts.
Does Gitea Actions run my existing GitHub workflows?
Gitea Actions is designed to be compatible with GitHub Actions, so many workflows that use common syntax and widely used actions can run with little change. Compatibility is not complete, though. Check for GitHub-specific contexts, hosted runner images, OIDC token exchanges, reusable workflows from other repositories, and actions that call GitHub APIs directly. Workflows that depend on GitHub-hosted runners need self-hosted runners you operate. Run a sample of your heaviest pipelines on Gitea before cutover and treat any failures as a list of changes to make, not as a reason to skip testing. Confirm the current compatibility notes in the Gitea documentation for your installed version.
What happens to GitHub secrets, tokens and deploy keys?
Secrets rarely move cleanly. GitHub Actions secrets cannot be exported, so every value must be re-entered in Gitea or in a secrets manager you run, and each one should be rotated as part of the cutover. Personal access tokens and OAuth grants issued by GitHub stop being useful once you leave, and the migration token you use to import data should be revoked after the import. Deploy keys and webhook secrets must be recreated on the new server, and any external system that authenticates to GitHub needs its credentials changed. Keep a record of each credential, its owner and the system it serves, so nothing is left pointing at the old platform.
When is commercial support from CommitGo worth a contract?
Commercial support is worth pricing when your organization needs a vendor to answer for the product, not only your own team. CommitGo provides leadership and commercial support for Gitea 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. Those features matter most when your access control or audit requirements call for them, or when a single admin team cannot cover outages. Compare the Enterprise feature list against your requirements, ask CommitGo for its support terms in writing, and separately price the operations work you would still carry, since a support contract does not run backups or upgrades for you.
How DeployOpen helps evaluate and move to Gitea
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted Gitea inside your own cloud accounts, data centers or air-gapped networks. We start with the written scope that decides whether Gitea fits your GitHub usage, then carry the migration through to a handover your team can run.
How we scope
- Inventory repositories, pull requests, issues, Actions workflows, packages and secrets that must move off GitHub or GitHub Enterprise Server.
- Confirm which GitHub features your teams depend on and which Gitea equivalents you must verify in your own environment.
- Agree deliverables, timelines and responsibilities in writing before work starts, since most engagements are fixed-scope.
How we build
- Install and configure Gitea on your infrastructure, with the database choice (MySQL, PostgreSQL, SQLite or MSSQL) agreed in the scope.
- Run test migrations with Gitea's built-in GitHub importer and record which metadata carries over and what needs manual rework.
- Rebuild Gitea Actions workflows and secrets, then run security testing against the application, its APIs and the hosting environment.
How we hand over
- Document architecture, backup and restore procedures, upgrade steps and the migration runbook your team will reuse.
- Prepare controls and evidence for your compliance assessments, while independent auditors remain responsible for any audit report.
- Walk your administrators through operations and deliver the configuration as written in the agreed scope.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the handover, sized to your written scope.
- Plan Gitea version upgrades in your own change windows, with testing before each production move.
- Ask any support provider, including CommitGo for Gitea Enterprise, which commercial features and response terms they will contractually provide.
