Which fits: GitHub Enterprise Server or self-hosted Gitea for source code hosting
If your renewal is driven by per-user pricing and you want to keep the GitHub workflow your developers already know, GitHub Enterprise Server stays the lower-change option. If the pressure is licensing cost, a data residency rule that requires the forge to run in a specific facility, or a wish to stop depending on one vendor's appliance roadmap, self-hosted Gitea is the stronger candidate, provided your team can run it. The decision turns on five questions: how much of your pipeline depends on GitHub Actions workflows, which SAML and audit logging controls you must have, how much you rely on package registries, what skills your operators already have, and who will carry upgrades and support after go-live.
Start with Actions. Gitea Actions is designed to be compatible with GitHub Actions, but compatibility is not the same as identical behavior. Inventory every workflow, reusable action, self-hosted runner label and secret your pipelines use, then run a representative subset on a Gitea test instance before you commit. For SAML and audit logging, confirm which tier you need. Gitea Enterprise, sold by CommitGo, adds SAML 2.0 service provider support and audit logging, among other controls. Ask your compliance lead which evidence the assessor expects, then confirm with CommitGo that the features map to those requirements. Also check your package needs: Gitea supports more than 20 registry types, but confirm that every format and access rule your build chain uses is covered before you retire an existing repository manager.
Support and upgrades decide the long-term cost. GitHub Enterprise Server is supported by GitHub through its release cycle, and you schedule its appliance upgrades. With Gitea, you choose between a self-managed install, Gitea Cloud, or a Gitea Enterprise support contract, and each choice moves the upgrade and on-call burden to a different party. Write down who patches the host, who applies Gitea releases, who answers a failed runner at 2 a.m., and who signs off on a restore test. If that list has gaps, that gap is the real reason to pick one option over the other.
Which scenarios favor each option
This table matches common situations to the option that fits better and the condition that makes it so. Read each row against your own estate, since the answer usually depends on one or two requirements rather than on overall preference. Confirm any vendor capability in writing before you rely on it.
| Scenario | Better fit | Condition that decides it |
|---|---|---|
| Large GitHub Actions estate | GitHub Enterprise Server | Many workflows and third-party actions depend on GitHub-hosted behavior. Gitea Actions is designed to be compatible, so test your heaviest workflows before deciding. |
| Small team on modest hardware | Gitea | Gitea runs on Linux, macOS and Windows, including small systems such as a Raspberry Pi. GitHub Enterprise Server runs as a virtual appliance sized to the license count and Actions load. |
| Strict SAML and audit logging needs | Gitea Enterprise, if the features are confirmed | Gitea Enterprise adds SAML 2.0 service provider support and audit logging. Confirm they meet your assessor's evidence needs. Choose GitHub Enterprise Server if your identity and logging controls are already built around its native features. |
| Vendor-backed support with a named supplier | GitHub Enterprise Server | GitHub is a single vendor for the product and its updates. Gitea support comes from CommitGo, Inc. through Gitea Enterprise, so compare support terms and response commitments in writing. |
| Air-gapped environment | Either, after testing | Both can run without internet access once installed. Plan how updates, Actions runners and package registries reach the network through approved transfer channels, and confirm the offline update path with each vendor. |
| Package registries across many formats | Gitea | Gitea supports more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts. Confirm that each format meets your scanning and retention requirements. |
| Need for an upgrade path from an existing Gitea install | Gitea | Forgejo documents transparent upgrades from Gitea up to v1.22, so Gitea users should confirm their version before choosing a fork. Gitea's own release line continues, so track which branch you intend to run. |
| Organization wants a single-vendor appliance upgrade path | GitHub Enterprise Server | The appliance model keeps upgrades on one vendor's schedule. Check the supported release line and the downtime each upgrade requires for your environment. |
Where the data lives and who controls the platform
GitHub Enterprise Server and Gitea both run in infrastructure the organization chooses, so data location and administrative control are decisions the organization makes, not vendor defaults. The cards below cover the places those decisions show up: hosting options, identity, audit trails, licensing and the compliance evidence the organization must assemble itself.
Hosted residency is not self-managed control
GitHub Enterprise Cloud with data residency on GHE.com offers EU, Australia, US and Japan regions, which is a hosted option with regional storage. Running GitHub Enterprise Server or Gitea yourself places repositories, databases and backups in the data centers or cloud accounts you name. Before comparing, confirm with each vendor which data classes stay in-region, including backups, logs and search indexes, and who operates the underlying service.
Identity federation and SAML 2.0
Gitea Enterprise adds SAML 2.0 service provider support, so sign-in can route through your existing identity provider. Confirm whether your GitHub Enterprise Server edition, plan and identity provider configuration cover the same flows, including provisioning, deprovisioning and group mapping. Test how a revoked employee loses access to repositories and tokens, because that path is where most identity gaps appear.
Audit logging and retention
Gitea Enterprise includes audit logging, which records administrative and security-relevant events. Ask each side which events are logged, where the log is stored, how long it is retained by default and whether it can be exported to your SIEM without a custom parser. Decide who may read or alter audit records, since an audit trail controlled by the same administrators it monitors carries limited weight.
MIT licensing and the commercial edition
Gitea is MIT licensed, so the community code can be inspected, modified and run without a per-user fee. The features in Gitea Enterprise, such as SAML 2.0, audit logging, IP allowlisting and mandatory two-factor authentication, come from a commercial agreement with CommitGo. Map each control your policy requires to either the open-source build or the paid edition before you commit, and record which version of the licence applies to your deployment.
Compliance evidence you must produce
Hosting in your own infrastructure does not transfer compliance. Your team must produce access reviews, change records, backup restore tests, vulnerability management records and configuration baselines for the forge, whichever product you choose. Independent auditors and certification bodies issue any attestations, so ask them which evidence they will sample from the forge and the identity provider before the assessment begins.
Who operates the platform
With GitHub Enterprise Server, GitHub supplies the appliance and its upgrade path, while your team runs the virtual machine, storage and maintenance windows. With self-hosted Gitea, your team or a contracted partner owns the release process, database and backups, and commercial support from CommitGo is optional. Write down who patches, who approves a version change and who answers when a runner or database fails at night.
How the licensing and editions differ
GitHub Enterprise Server is sold as a self-managed edition of GitHub under a per-user GitHub Enterprise license and runs as a virtual appliance on your own hardware. The license count, the appliance version you run and the support agreement all sit with GitHub, so a renewal decision is partly a decision about how many seats you still need and whether you want to keep paying for a managed appliance upgrade path. Gitea takes the opposite starting point. Its core is MIT licensed, so you can install, modify and run it without a per-user fee, and the cost question moves to infrastructure, staff time and any support you choose to buy. Confirm with GitHub which Enterprise Server terms, support tiers and per-user counting rules apply to your agreement before comparing totals.
The paid option on the Gitea side is Gitea Enterprise, sold by CommitGo, Inc., which provides leadership and commercial support for Gitea. According to the Gitea Enterprise page, the edition adds SAML 2.0 service provider support, audit logging, organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning. Map each of these against the controls your security and compliance teams already rely on in GitHub Enterprise Server, such as single sign-on enforcement, audit trails and branch protection rules, and check which ones your current setup depends on. Ask CommitGo whether these features are included in the edition you are quoted and what support response terms apply, because the free core and the commercial edition differ in what you can verify without a contract.
Because edition terms change, treat the feature list above as a starting point and not a final statement of what you will receive. Before a decision, request the current feature matrix and license terms from CommitGo and from GitHub in writing, and ask each vendor to confirm how they count users, whether they require a minimum term, and what happens to your data and entitlements at renewal. Record the answers alongside your inventory of GitHub Enterprise Server features in use, so the migration scope is based on confirmed terms rather than memory of an older contract.
What running each platform takes day to day
Running either platform is an ongoing job, not a one-time install. The cards below cover the hardware, database, upgrade, backup, CI capacity and staffing questions that decide whether GitHub Enterprise Server or Gitea fits your operations team.
Appliance hardware and upgrade windows
GitHub Enterprise Server runs as a virtual appliance that you size, patch and upgrade as one unit, so hardware planning and maintenance windows are set by GitHub's appliance model. Gitea is a single service that installs on general Linux, macOS or Windows hosts, which usually means a lighter footprint and more choice in how you schedule changes. Ask GitHub for current sizing guidance for your user count and Actions use, and confirm the upgrade downtime you should expect for each release path before comparing.
Supported hosts and operating systems
Gitea runs on Linux, macOS and Windows, including small systems such as a Raspberry Pi, which makes it practical to test or run a small instance on modest hardware. Your choice of host OS should follow your standard patching and monitoring tooling, not the forge. Confirm which operating system versions your security team supports, and whether a Windows-only estate needs a Linux host for production Gitea.
Database choice and its operating cost
Gitea supports MySQL, PostgreSQL, SQLite and MSSQL. SQLite suits small trials, while PostgreSQL or MySQL is the usual choice for multi-team production because it brings your existing backup, replication and patching practices. Confirm which database engines your DBA team already runs well, and whether MSSQL support meets your current version requirements before you commit.
Platform administration role
Someone must own the forge: user and organization administration, authentication settings, repository policies and version compatibility with the database and runners. For GitHub Enterprise Server, this role mostly works through the appliance administration console. For Gitea, it covers the configuration file, the service account, the reverse proxy and TLS. Assign a named owner and a backup owner before go-live.
Backup and restore ownership
Backups must capture both Git repositories and the database that holds issues, pull requests and settings, and a restore must be tested, not assumed. GitHub Enterprise Server includes its own backup tooling for the appliance, while Gitea backups depend on your chosen database and storage tools. Ask who runs restore tests, how often, and where the backup copies live.
CI runner capacity and upgrades
Actions workloads run on runners that you size and maintain separately from the forge, and Gitea Actions is designed to be compatible with GitHub Actions. Runner capacity, queue times and runner patching are recurring tasks whichever platform you pick. Plan for upgrades on a schedule your team can staff, and check the Gitea release notes for each minor version before applying them.
How a move from GitHub Enterprise Server to Gitea works
The sequence turns one appliance into a Gitea instance with repositories, issues, pull requests, workflows, packages and sign-in moved across in an order that lets each stage be tested before the appliance is switched off.
Inventory repositories, workflows and integrations
List every organization, repository, team, branch protection rule, webhook, GitHub App, Actions workflow, self-hosted runner and package registry on the appliance. Record which repositories are actively used and which are archives. Your platform team and the owners of critical pipelines do this together, because workflows often depend on secrets, runner labels and third-party integrations that the inventory must capture. The step is done when the team has a signed-off list with an owner for each item and a decision to migrate, archive or drop it.
Mirror Git history into Gitea
Create a Gitea instance in your own infrastructure with the database and storage chosen for your scale. Then mirror each repository with a bare clone from the appliance and push it to Gitea, including all branches and tags. Git history moves with a clone or mirror, so this step does not depend on any platform importer. The check is a comparison of commit counts, branch lists and tag lists between source and target for a sample of repositories, plus a spot check that large or LFS-tracked repositories are complete.
Run the platform importer for issues and reviews
Use Gitea's migration feature, which includes an importer for GitHub, to bring over issues, pull requests, reviews, comments, labels, milestones and wikis. Bulk runs can be limited by GitHub API rate limits, so plan batches, run them off-hours and expect retries. The GitHub REST limit for personal access tokens is 5,000 requests per hour, according to GitHub's documentation, and your token type and any GitHub App installation may have different limits that you should confirm. The step is done when counts of issues and pull requests match and a sample of reviews reads correctly, with known gaps such as attachments or reactions logged.
Rewrite and test Actions workflows
Gitea Actions is designed to be compatible with GitHub Actions, but compatibility is not identical for every action, runner image or marketplace dependency. Copy workflows into a test repository, point them at Gitea runners, and fix steps that call GitHub-only APIs, expect GitHub-hosted images or rely on GitHub-specific secrets and context values. Run the pipelines against the same commits as production and compare test results and artifacts. The step is done when each critical pipeline passes on Gitea, and the team has a documented list of workflows that still need changes.
Migrate package registries and container images
Identify which packages, container images and Helm charts the organization publishes through GitHub, then recreate those registries in Gitea, which supports more than 20 package registry types, or in a dedicated registry if your standards require one. Update consuming build files, Dockerfiles and deployment manifests to the new endpoints, and keep the old endpoints readable until consumers have switched. The check is a pull and install from each registry by a consumer build, with versions and checksums matching the originals.
Cut over identity and access
Configure Gitea sign-in for your identity provider, using SAML or another supported method, and confirm group or team mapping matches the GitHub organization structure. Note that SAML 2.0 service provider support is part of Gitea Enterprise, so confirm whether your edition covers it before you design the flow. Test sign-in with a pilot group, verify that deprovisioned users lose access, and check that personal access tokens and SSH keys are reissued. The step is done when access reviews against the source list show the same people with the same rights.
Run test cutovers before the switch
Hold at least one rehearsal cutover in which repositories, issues, workflows, packages and sign-in are moved on a copy of the data, and the team works against the result for a defined period. Record every defect, owner and fix, then repeat the rehearsal until the open list is empty or accepted. Your change board should approve the final cutover date, the freeze window for pushes on GitHub, and the rollback plan. The step is done when the rehearsal produces no blocking defects.
Retire the GitHub Enterprise Server appliance
After the final sync, set the appliance to read-only, update remaining links, webhooks and documentation, and confirm nothing still depends on it. Keep a dated, encrypted backup of the appliance and its data for the retention period your legal and compliance teams set, then decommission the virtual machines and revoke licenses according to your contract terms. Confirm the end state with your licensing contact in writing. The step is done when the appliance is offline, backups are verified and the decommission record is filed.
Questions buyers ask before switching from GitHub Enterprise Server
What drives the cost and effort of moving from GitHub Enterprise Server to Gitea?
The cost is set by four components: the people who plan and run the migration, the hosting you run Gitea on, the migration itself, and the support model you choose. Your GitHub Enterprise licenses and appliance hardware stop recurring once you retire them, but you still need to pay for the infrastructure and staff that replace them. Gitea is MIT licensed, so the software carries no license fee, while CommitGo sells commercial support and Gitea Enterprise as optional subscriptions. The largest drivers are the number of repositories, the volume of issues, pull requests and wiki content to move, how many Actions workflows you must rebuild, and whether you need the Enterprise features. Ask any quote to separate one-time migration work from recurring operations and support.
How long does a migration from GitHub Enterprise Server to Gitea take?
No duration is fixed by the product, so the timeline depends on what you have to move and how much you have to rebuild. Git history moves with a clone or mirror, which is fast for most repositories, but issues, pull requests, reviews and wikis need a platform importer. Gitea's migration code includes an importer for GitHub, so those items can be carried across, though you should verify the result on a sample of repositories before a full run. Other timeline drivers are GitHub API rate limits on bulk exports, the number of repositories with large files, the count of Actions workflows and self-hosted runners to recreate, and the approval steps your change management requires. Ask for a timeline built from a written inventory of your repositories and workflows.
What does a move to Gitea require from our internal team?
Your team needs skills in Linux server administration, database operations, reverse proxy and TLS configuration, backup and restore, and Git administration. Someone must own the Gitea upgrade cycle, monitor the service, and manage user, team and access settings in your identity provider. Platform engineers should also review how Gitea Actions runners are provisioned, because workflows that depend on GitHub-hosted runner images or specific marketplace actions need checking. Gitea supports MySQL, PostgreSQL, SQLite and MSSQL, so the team should confirm which database matches its standards. Plan named owners for repository mapping, workflow conversion, user communication and cutover, and confirm the time these people can give the project.
Can our own engineers carry out the migration without outside help?
Many teams with an experienced Linux and Git administrator can complete a small pilot alone, but a full migration of a regulated estate usually needs more than one skill set. The questions to answer honestly are whether you have spare capacity, whether you have tested a restore of the new platform, and whether anyone has converted GitHub Actions workflows before. An implementation partner can take on a fixed-scope piece, such as building the hosting, moving data, converting workflows, hardening the platform or writing runbooks, while your team keeps ownership. Engagements are agreed in writing before work starts, so ask for the scope, deliverables and exit criteria in writing.
Is Gitea Enterprise required for SAML and audit logging?
Yes, according to Gitea's own product description, SAML 2.0 service provider support and audit logging are features of Gitea Enterprise, not of the MIT licensed community edition. The Enterprise edition also adds organization-level branch protection inheritance, IP allowlisting, mandatory two-factor authentication and dependency scanning, all sold by CommitGo, Inc. You should confirm the current feature set and terms directly with CommitGo before you rely on them, since editions change over time. If your compliance program needs SAML or audit trails, put those requirements into the quote and check whether an open-source option or your own logging pipeline can meet them. Your auditors decide whether a control is sufficient.
Do GitHub Actions workflows run unchanged on Gitea?
Not automatically, but many simple workflows need little change. Gitea Actions is designed to be compatible with GitHub Actions, so familiar workflow syntax is the starting point. Differences tend to appear in runner labels, secrets and variables, the actions your workflows pull from the marketplace, and any dependency on GitHub-hosted services or runner images. Build an inventory of every workflow, mark those that call third-party actions, and run a representative sample on a test instance before cutover. Confirm each compatibility claim against the Gitea documentation for the version you deploy, because compatibility depends on the release you choose.
Which Gitea version should we plan to deploy?
Choose a version that your team can keep current, and confirm the latest release before you commit. Gitea v28.0.0 was released on September 29, 2026 and v28.1.0 on October 6, 2026, following the v1.27 line, whose v1.27.3 shipped on August 29, 2026, according to Gitea's GitHub releases page. Check that your chosen release supports the database and operating system you have standardized on, and read the upgrade notes before each update. Plan a regular upgrade window and a tested restore from backup, since staying on an old release increases the work of the next upgrade. Ask your implementation partner or vendor to document the upgrade path in the scope.
How DeployOpen helps evaluate and migrate to Gitea
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Gitea evaluation, that work starts with a written scope covering the parts of GitHub Enterprise Server you actually depend on: organization and team structure, branch protection rules, GitHub Actions workflows that must run under Gitea Actions, SAML or other single sign-on settings, audit log retention, and the package registries your builds pull from. DeployOpen is not a Gitea or CommitGo partner, and it does not issue certifications or audit reports. Its role is to prepare the platform, controls and evidence that your own assessors will review.
Engagements are fixed-scope. Before work begins, the deliverables, timelines and responsibilities are agreed in writing, and a quote follows from that written scope. A typical evaluation covers a workflow compatibility check, a migration plan for repositories and issues using the importers in Gitea, a sizing and hosting design, and a security test of the resulting instance. Ask any partner, DeployOpen included, to state which deliverables are included and which are excluded, who performs the importer runs, and what happens if a workflow needs rework. Ongoing support, upgrades and continuous security testing are available as a retainer, which suits teams that will run Gitea after the migration without a dedicated platform group. Confirm the Gitea Enterprise features you need, such as SAML 2.0 and audit logging, directly with CommitGo before you decide which edition to scope.
