Azure DevOps vs Gitea: which fits your Git hosting and CI needs
Azure DevOps fits when you need the integrated suite, and Gitea fits when you mainly need Git hosting, pull requests, packages and CI on your own server. Most readers arrive here because of a renewal, a licensing change, a data residency rule or a concern about lock-in, and the question is which parts of the suite they truly depend on. Azure DevOps remains the stronger choice when Azure Boards work items, Test Plans and the single sign-on and permission model across Repos, Pipelines and Artifacts are central to how teams deliver. Teams that keep their planning elsewhere, rely on Git, pull requests and CI pipelines, and want code and packages on hardware they operate often find Gitea covers that core. Gitea is MIT licensed, combines Git hosting, code review, package management and CI/CD in one self-hosted service, and offers Gitea Actions, which is designed to be compatible with GitHub Actions. Its package support spans more than 20 registry types, including npm, PyPI, Maven, container images and Helm charts.
The fit is decided by how much of the suite you use today. Start with an inventory of Azure Repos features in use, including branch policies, required reviewers and pull request build validation, and check each against Gitea's pull request and Actions behavior in a test instance. Then list every Azure Boards and Test Plans dependency, such as linked work items, sprint reporting and manual test runs, because Gitea does not replace them. If those dependencies have no home in your plan, the cost of a split toolchain can outweigh the savings from a lighter forge. Confirm your Azure DevOps licensing structure and whether it is Azure DevOps Services or Azure DevOps Server, since that changes the renewal conversation. Ask Gitea's commercial supporter, CommitGo, Inc., which Enterprise features you need, such as SAML 2.0 support, audit logging or mandatory two-factor authentication, and whether they are required for your controls.
Which option fits which team scenario
This table matches common Azure DevOps team profiles with whether Gitea is a good fit and why. Read each row against your own mix of Repos, Pipelines, Boards, Test Plans and Artifacts, because Gitea covers the source and CI side of the suite but not work tracking or test management.
| Team scenario | Better fit | Why |
|---|---|---|
| Team mainly using Repos and pipelines | Gitea | Gitea combines Git hosting, code review and CI/CD, and Gitea Actions is designed to be compatible with GitHub Actions, so many workflow concepts carry over. Confirm how your azure-pipelines.yml jobs translate before committing. |
| Team heavily using Boards and Test Plans | Azure DevOps or a separate tool | Gitea has no equivalent to Azure Boards work items or Test Plans. Plan a separate work tracker and test management tool, or keep Boards in place while moving code. |
| Team needing on-premises data control | Gitea | Gitea is self-hosted and runs on MySQL, PostgreSQL, SQLite or MSSQL, so repositories, pull requests and packages stay on servers you operate. Confirm where backups and CI runner logs are stored. |
| Team with a small platform staff | Gitea, with a support plan to consider | Gitea is a single service to install, back up and upgrade. CommitGo provides commercial support and Gitea Enterprise is available, so compare that cost against the staff time you would otherwise spend on patching and incidents. |
| Team with many package feeds | Gitea, after a feed-by-feed check | Gitea supports more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts. Confirm that every NuGet, Universal Packages and upstream source your feeds use is covered before moving. |
What Gitea covers and what it leaves out
Gitea is an all-in-one forge. Its own documentation describes it as a self-hosted service that combines Git hosting, code review, team collaboration, package management and CI/CD, and it is released under the MIT license. For a team that mainly uses Azure Repos and Pipelines, that covers the core of the day-to-day work: repositories, pull requests with reviews, branch protection, a package registry for many formats, and Gitea Actions, which is designed to be compatible with GitHub Actions. The practical question is not whether Gitea has these areas, but whether the specific settings your teams depend on, such as branch policies, required reviewers and pipeline permissions, map to Gitea's equivalents. Check those against the current Gitea documentation rather than assuming a one-to-one match.
The main gap is planning. Gitea has no direct equivalent of Azure Boards work items, backlogs, sprints or Test Plans. If your organization tracks epics, features and test cases in Boards, plan for a separate planning or test tool and decide how work items will link to commits and pull requests. Record the answer before the cut-over, because it determines what data you export and where the traceability links live. Test management usually needs the same decision: either keep Test Plans in Azure DevOps during a transition period, or choose a dedicated test tool and migrate its records as their own project. Ask each team which Boards and Test Plans features they use every week, since that list, not the product comparison, sets the scope.
Gitea is available as self-hosted software that you run in your own infrastructure, and also as Gitea Cloud, a managed service. The choice between them is mostly a question of who operates the server, where the data sits and who you contact when something fails. Gitea Cloud can suit a team that wants the same feature set without running the platform, but it changes your data location and support model, so confirm its hosting region and terms in writing if residency matters to you. Whichever option you choose, confirm the features you rely on in the version you will deploy, because Gitea releases change frequently and feature detail is best read from the current documentation.
Where your data lives and who controls it
Azure DevOps and Gitea differ less in features than in who operates the service, where data sits and who holds the keys. The four options below range from a Microsoft-run cloud service to a managed Gitea offering and a server you run yourself, so the right choice depends on your residency rules, identity model and audit obligations.
Azure DevOps Services data location
Azure DevOps Services stores customer data in the geography chosen for the organization, which helps with residency for most content. Tokens and SSH keys, however, are kept in a US datacenter, so a strict EU or in-country requirement cannot be assumed to cover every credential. Ask Microsoft to confirm the current data location documentation for your geography, and map which identities, personal access tokens and service connections your pipelines depend on before you sign a residency commitment.
Azure DevOps Server on premises
Azure DevOps Server runs in your own data center, so repository data and credentials stay under your control, but you take on patching, database operations and backups. Microsoft's Modern Lifecycle Policy requires staying on current releases to receive continuous support, which turns upgrades into a recurring operating task. Confirm with Microsoft which release is current for your deployment and how its licensing applies to your user count before comparing it with Gitea.
Self-hosted Gitea in your cloud account
Running Gitea in your own cloud account or data center places repositories, database, package storage and backups under your identity controls and network boundaries. You choose the region, the database engine (MySQL, PostgreSQL, SQLite or MSSQL) and who can reach the server, including whether it sits behind SSO. The cost is that your team owns uptime, TLS, backups, restore testing and upgrades. Document where each data class lives and who holds administrator access before the cut-over.
Gitea Cloud as a managed option
Gitea Cloud is a managed service run by the Gitea project's commercial provider, which removes server operations from your team. Data location, subprocessors, backup and access logging then become contract terms rather than settings you control directly. Ask for the hosting regions, where tokens and secrets are stored, how administrators access your tenant and what audit evidence is provided. Gitea Enterprise adds SAML 2.0 support, audit logging and mandatory two-factor authentication for either deployment model.
Licensing and editions: MIT Gitea and Gitea Enterprise
The first decision for a team comparing Azure DevOps with Gitea is which Gitea you are actually adopting. Gitea is MIT licensed, so the community edition can be installed, modified and run on your own servers without a per-seat license fee from the project. Commercial support comes from CommitGo, Inc., which provides leadership and support for Gitea and sells Gitea Enterprise. Gitea is also offered as Gitea Cloud, a managed service, so the self-hosted and managed options are separate purchasing decisions that should be evaluated against the same written requirements.
Gitea Enterprise adds controls that matter to regulated teams: 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. Confirm each of these against the current Enterprise page and a test instance before you rely on it in a control narrative, because feature availability can change between releases. Ask CommitGo whether the subscription covers installation help, upgrade assistance and response times, and what it excludes. Check how the Enterprise features interact with your identity provider and your branch protection design.
Licensing is a software and support model choice, not only a question of where the code runs. Azure DevOps Server is also a self-managed edition that runs on customer infrastructure, so comparing it with a self-hosted Gitea means comparing two self-managed products with different licenses, support contracts and upgrade paths. Build the comparison around the support you need, the controls you must evidence and the people who will operate the platform, then request written Enterprise pricing from CommitGo and your Microsoft contact so that both quotes cover the same scope.
What each option costs to run, by component
Azure DevOps bills most of its cost as recurring seats, parallel jobs and storage, while a self-hosted Gitea moves the cost onto servers, backups, upgrades and the people who run them. Each card below is one component, with whether it recurs, what drives it, and what to request in a written quote before comparing totals.
Azure DevOps seats and parallel jobs
Azure DevOps charges recurring per-user access and parallel pipeline jobs, and these lines are set by Microsoft's pricing pages rather than by the team. Confirm the current per-user rate, the number of Microsoft-hosted and self-hosted parallel jobs included, and which seats need Basic or Basic plus Test Plans access. Your cost moves with headcount and with how many builds run at the same time, so model peak concurrency, not average. Ask your Microsoft partner or reseller to show each line item on the quote.
Azure Artifacts storage
Artifacts storage is a recurring charge above the free tier, billed on the amount of package data kept in feeds. Storage grows with retained package versions, so a retention policy that removes old builds is the main lever. Ask the vendor for the current free allowance, the per-GiB rate and whether upstream package sources count toward storage. On Gitea, the equivalent cost is disk and backup space on your own storage, which you size and control.
Azure DevOps Server licensing and upgrades
Azure DevOps Server is an on-premises product licensed through server and client access licenses, with recurring Software Assurance or subscription terms depending on your agreement. Microsoft's October 7, 2025 announcement moved the server to the Modern Lifecycle Policy, which asks customers to stay current to keep receiving continuous support. Budget the upgrade cycle as a recurring effort item, and ask whether your agreement includes the license cost of each new release.
Gitea server and storage
A self-hosted Gitea install is a one-time hardware or cloud instance decision plus recurring compute, disk and network charges. Gitea runs on Linux, macOS and Windows and supports MySQL, PostgreSQL, SQLite and MSSQL, so the database and host choices change the sizing. Repository size, LFS objects, package registries and CI runner count drive capacity. Ask your infrastructure team to price a production and a staging instance, plus CI runners, as separate lines.
Backups, upgrades and staff time
Backups, restore testing and upgrades are recurring operational work that the subscription model hides when you run Gitea yourself. Plan for regular backups of repositories, the database and attachments, a tested restore procedure, and a scheduled upgrade window for each Gitea release. Staff time is usually the largest cost, so estimate the hours per month for administration on-call coverage, and compare that against the seats you would otherwise pay Microsoft for.
Gitea support subscription, if chosen
Gitea is MIT licensed, so the software itself has no license fee, but CommitGo sells commercial support and Gitea Enterprise, which adds SAML 2.0, audit logging, IP allowlisting and mandatory two-factor authentication. Support is optional and recurring, and its price is set by CommitGo. Ask for a written quote that lists the included support hours, response expectations and whether the Enterprise features you need are in the tier. Compare it with the Azure DevOps features you would otherwise pay for.
How a move from Azure Repos to Gitea is structured
The sequence moves Git history, pull request records, branch rules, pipelines and packages in separate tracks so that each one has an owner and a check before the cut-over. Each step closes with an output the team can confirm before the next one starts.
Inventory repositories, pipelines and feeds
The team lists every Azure Repos Git repository, its default and protected branches, its branch policies, the pipelines that build it, the Artifacts feeds it reads from and the Boards items linked to its commits. Engineering leads and the Azure DevOps administrator own this list, and the platform team checks it against the Azure DevOps organization settings. The step is done when each repository has a named owner and a disposition: move, archive or retire. Boards data is marked for a separate decision because Gitea does not replace it.
Mirror Git history into Gitea
For each repository in scope, the platform team creates a mirror clone from Azure Repos and pushes all branches and tags to a Gitea repository on the organization's own server. Git history transfers this way, but issues, pull requests and review comments do not, because Gitea has no Azure DevOps importer. The check is a comparison of branch and tag lists and the latest commit hashes on both sides for every repository.
Plan the pull request and review archive separately
Pull requests, reviewers, comments and votes stay in Azure DevOps and need their own plan. The team decides whether to export them through the Azure DevOps REST API into a read-only archive, whether to keep Azure DevOps in read-only mode for a period, or whether to accept that open pull requests are re-opened as new ones in Gitea. Compliance and audit owners sign off on the choice, since it determines what history survives. The output is a written decision per repository.
Convert or retire TFVC history
Where a project still uses Team Foundation Version Control, the team decides whether to convert that history to Git, which is a separate exercise from mirroring, or to keep it as an archive outside Gitea. Teams confirm the conversion approach against current Microsoft guidance before running it on a copy. The step is done when each TFVC path has a recorded decision and, if converted, the converted Git history has been checked against a sample of known changes.
Re-create branch protection as Gitea settings
Azure DevOps branch policies, such as required reviewers, build validation and merge types, are re-entered as Gitea branch protection rules and, where needed, organization-level settings. Gitea Enterprise adds organization-level branch protection inheritance, which the team should confirm is needed before buying. The check is a side-by-side table of each policy in Azure DevOps and its Gitea equivalent, reviewed by the security owner for each protected branch.
Rebuild pipelines as Gitea Actions and test them
Azure Pipelines definitions, whether YAML or classic, are rewritten as Gitea Actions workflows, which Gitea designs to be compatible with GitHub Actions. Secret variables cannot be read back from Azure DevOps, so each secret is re-entered in Gitea from its original source and rotated where appropriate. Workflows run first on a non-production repository and then on a copy of a real project. The step is done when each workflow produces the same artifacts and test results as its Azure Pipelines predecessor.
Move package feeds
Artifacts feeds for NuGet, npm, Maven, Python and Universal Packages are mapped to Gitea package registries or to another self-hosted repository manager, depending on the formats in use. Upstream sources and feed permissions are recreated, and build scripts are pointed at the new endpoints in a test environment first. The output is a successful build of each dependent project that resolves all packages from the new registry, with the old feeds kept read-only until the cut-over is complete.
Cut over and keep a rollback path
The team freezes pushes to Azure Repos for each repository, runs a final mirror sync, switches developers and pipelines to the Gitea remotes, and confirms that builds and deployments succeed. Azure DevOps stays read-only and its repositories and feeds are retained, so the team can point builds back if a blocking defect appears. The cut-over is complete when every repository in scope has passed its build checks, the rollback owner has signed off, and the retirement date for Azure DevOps access is recorded in writing.
Questions buyers ask before choosing Gitea over Azure DevOps
What does moving from Azure DevOps to Gitea cost in effort, and what drives it?
The effort depends mostly on how much of the Azure DevOps suite you are replacing. Moving Git repositories is the smallest part. The larger costs are pull requests, which Gitea has no Azure DevOps importer for, branch policies that must be re-created, YAML pipelines that must be rewritten for Gitea Actions, and any Boards or Artifacts data that goes to other tools. Costs recur through servers, storage, upgrades, backups and staff time to run the platform. Ask any implementation partner for a quote built from a written scope that lists each component separately, and compare it with your current per-user and per-job licensing.
How long does a migration to Gitea take, and what sets the duration?
No general duration can be stated responsibly, because it depends on your environment. The main drivers are the number of repositories and their history size, how many pull requests and work items must be preserved, how many pipelines use YAML or classic definitions, how many packages feed Artifacts, and how many integrations depend on Azure DevOps service hooks or REST calls. Teams that run a parallel period, where both systems stay live while builds are switched over, usually need more time than teams that cut over in one step. Ask for a timeline that is tied to a written inventory of your organization.
What does the work need from our own team?
Your team needs to own the decisions that only you can make: which repositories move, who approves access and branch rules, which pipelines are retired, and how identities map from Microsoft Entra ID or your directory into Gitea accounts. Engineers must review and test migrated pipelines and confirm that deployments still work. Someone must also own the server, including patching, backups and monitoring after handover. Plan for these people to be available during the cut-over window, not only at the start.
Can our team migrate to Gitea without outside help?
Yes, a team with Git and CI experience can mirror repositories and set up a Gitea instance without outside help. Repository history moves with a clone or mirror, and Gitea's documentation covers installation and configuration. The harder parts are pull request history, which needs custom scripting against the Azure DevOps REST API within its rate limits, and the rewrite of pipelines and policies. Teams that lack a staff member with this experience, or that operate under audit requirements, often choose a fixed-scope engagement so that the work and evidence are documented in advance.
Can Gitea replace Azure Boards and Test Plans?
No, Gitea does not provide Azure Boards work items, backlogs, sprint planning or Test Plans. Gitea offers issues, milestones, labels and projects for light tracking, and its wider scope includes code review and CI. If you rely on Boards or Test Plans, plan a separate self-hosted tool for those functions, such as OpenProject, Plane or Redmine for work items, and confirm that any test management tool you choose meets your traceability needs. Link work items to commits and pull requests by convention, and export Boards data before you decommission the service.
How does Gitea Enterprise support differ from running Gitea ourselves?
Gitea itself is MIT licensed and free to run, so the cost difference is in the support model, not the software. According to the Gitea Enterprise page, 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, along with commercial support. Self-hosting alone leaves those features and incident response to your team or your implementation partner. Check the current feature list and support terms with CommitGo before deciding, because they can change.
What do API rate limits mean for bulk exports from Azure DevOps?
Azure DevOps delays users who exceed 200 throughput units in a five-minute window, according to Microsoft's rate and usage limits documentation. For an export, this means that pulling thousands of work items or pull requests in one burst will slow down and take longer than the raw data volume suggests. Plan exports in batches, schedule them outside peak hours, and use a service identity with enough headroom. Confirm the current limits in Microsoft's documentation before the export starts, since they can change.
When staying on Azure DevOps is the better choice
Staying on Azure DevOps is often the right call when Boards, Repos, Pipelines and Test Plans work as one system for your teams. Work items link to commits, pull requests and builds without integration glue, and traceability reports, sprint views and test results sit in the same place. Replacing Gitea removes Git hosting and CI, but Gitea has no Boards or Test Plans equivalent, so you would need a separate work tracker, a test management tool and integrations between them. Before deciding, list which Boards features your auditors, release managers or product owners depend on each week, then confirm which of them you could rebuild elsewhere and what that rebuilding would cost in time.
Microsoft-centric environments also carry real weight. If your identity runs on Microsoft Entra ID, your Azure subscriptions and Microsoft 365 licensing are already managed by one team, and your developers work in Visual Studio and Azure-hosted environments, Azure DevOps fits existing access reviews, conditional access and group management without a second identity layer. Check which of these your current setup already covers, because moving Git hosting to Gitea means building single sign-on, role mapping and offboarding for a new system.
The strongest argument for staying is operational capacity. A self-hosted forge needs someone to patch the server, manage database backups, rotate runner credentials, and plan upgrades. Azure DevOps Server also carries a lifecycle obligation: Microsoft announced on October 7, 2025 that it moves to the Modern Lifecycle Policy, under which customers who stay current receive continuous support, so an on-premises server that falls behind is no longer a stable option. Decide whether you would rather upgrade Azure DevOps Server, move to Azure DevOps Services, or run Gitea, and ask each option's provider for its current support terms in writing before you commit.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For Azure DevOps vs Gitea, we start with which parts of the suite you actually need on your own server, then build and hand over only that scope.
How we scope
- Inventory which Azure Repos, Pipelines and Artifacts features your teams use, and which Boards or Test Plans workflows Gitea would not cover
- Confirm the Gitea version, database (MySQL, PostgreSQL, SQLite or MSSQL), and hosting location before any installation work begins
- Agree deliverables, timelines and exclusions in writing, since most engagements are fixed-scope and no price is published
How we build
- Install and configure Gitea with your identity, backup and network policies, and set up Gitea Actions runners for your existing pipeline logic
- Mirror Git repositories and recreate branch protection and review rules, then test them against sample pull requests
- Document each migrated pipeline, package feed and access rule so that gaps from missing importers are visible before cut-over
How we hand over
- Deliver runbooks for upgrades, backups, restores and runner maintenance, written for your platform and security teams
- Walk through the list of Azure DevOps items that stay behind, such as pull request history and work items, with named owners for each
- Provide evidence of configuration and access controls that your internal or external auditors can review, without us issuing any attestation
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover, scoped separately in writing
- Plan Gitea version upgrades against your own change windows and test them in a staging copy before production
- Confirm with your vendor or your own environment any commercial support needs, such as CommitGo's Gitea Enterprise features, before you rely on them
