Bitbucket vs Gitea: which to choose

Bitbucket vs Gitea: when each fits and what the decision turns on

If Jira, Confluence and other Atlassian tooling are central to how your teams work, Bitbucket usually fits better in the short term, because its links to those products are built in. If the driver is a renewal, an end-of-sale decision or a residency requirement, and your teams can run a small forge themselves, Gitea is a lightweight self-hosted option to evaluate against the others. Atlassian has said Bitbucket Data Center continues beyond 2029 and that existing customers receive a Bitbucket Hybrid License, so a Data Center renewal is not forced by that date alone. Confirm the terms of your own agreement and the current Hybrid License rules with Atlassian before you decide.

Four drivers should settle the choice. First, measure how central Jira and Atlassian tooling are to your branch, build and release workflow, because losing those links is the largest functional change in a move. Second, be honest about operating capacity: a self-hosted Gitea instance needs someone to own upgrades, backups, TLS, database maintenance and access reviews, and that work recurs. Third, decide whether pull request and review history must move. Git history moves with a clone or mirror, but Gitea's migration code has no Bitbucket importer, so pull requests, comments and reviews need a separate export and rebuild plan. Fourth, decide whether you need a vendor to answer for the software. Gitea has commercial support from CommitGo, Inc., which sells Gitea Enterprise, and you should ask what that contract covers before you rely on it.

Write these answers into a one-page scope before requesting quotes. List the repositories, the pull request history you must keep, the CI workflows that must be replaced, and the people who will run the server. Ask each vendor and each implementation partner for a quote that separates one-time migration work from recurring hosting, upgrades, backups and support. Where you need an outside view of the scope, an implementation partner such as DeployOpen can write that scope in writing before any work starts. Keep your Bitbucket export running until the new forge has been tested with real pull requests and restores.

Which option fits which scenario

This table compares Bitbucket and Gitea across the situations that usually trigger a move, with the better fit and the supplied reason for each. Read each row against your own constraints, and treat Gitea as the better fit where its lightweight footprint and MIT license matter more than a bundled Jira or Pipelines replacement. The main takeaway is that Gitea suits teams that want a small, self-hosted forge, while teams with deep Jira or Pipelines dependencies need a longer migration plan.

Scenario	Better fit	Reason
Jira-centric teams that rely on Bitbucket and Jira links	Bitbucket, for now	Gitea has no Bitbucket importer and no built-in Jira integration, so links and history need a separate plan before any move.
Teams seeking a small self-hosted forge	Gitea	Gitea is a single binary under the MIT license and runs on Linux, macOS and Windows, including small systems such as a Raspberry Pi.
Regulated teams that must keep code in their own datacenter	Gitea or Bitbucket Data Center	Self-hosting Gitea keeps repositories in your own infrastructure, while Bitbucket Cloud is not among the Atlassian products with data residency.
Teams with Bitbucket Pipelines dependencies	Gitea, with a CI rebuild	Gitea Actions is designed to be compatible with GitHub Actions, so workflows may port with changes, but Pipelines variables cannot be read back and must be re-entered.
Teams facing a Data Center renewal	Bitbucket Data Center, short term	Existing Bitbucket Data Center customers are offered a Hybrid License covering Data Center and Cloud, which gives time to plan a move.
Teams that need commercial support with an MIT-licensed core	Gitea	CommitGo, Inc. provides commercial support and sells Gitea Enterprise, which adds SAML 2.0, audit logging and mandatory two-factor authentication.
Teams that want packages and containers alongside code	Gitea	Gitea supports more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts.
Teams that need a managed service rather than self-hosting	Gitea Cloud or Bitbucket Cloud	Gitea is also offered as Gitea Cloud, so confirm its regions and terms with the vendor before choosing it over Bitbucket Cloud.

Where Gitea covers Bitbucket pull requests and Pipelines

Gitea covers the core of what most teams use Bitbucket for: Git hosting, pull requests with code review, issues, Actions-based CI and a package registry. Gitea supports more than 20 package registry types, including npm, PyPI, Maven, container images and Helm charts, so many artifact workflows can move onto the same server. The point to settle first is which of these features your team actually relies on day to day, because that list sets the scope of the migration. Gitea Actions is designed to be compatible with GitHub Actions, so workflow files written in the GitHub Actions syntax are the starting point, not a finished pipeline. Expect to adapt runs-on labels to your own runners, replace any Bitbucket-specific steps, and test each job on the new platform before you retire the old one.

Bitbucket Pipelines does not map one to one onto Gitea Actions, and several items need a separate plan. Pipelines variables do not carry over automatically, and many are secrets that Bitbucket will not export in readable form, so each value must be recreated in Gitea from the owning team's records. Deployment integrations, such as cloud accounts, registries or environment-specific deploy keys, need new credentials and new approval paths on your side. Jira links, including smart commit references and issue panels, stop working once repositories leave Bitbucket, so decide whether the Jira connection is needed at all or whether it moves to another tool. Confirm each of these with the team that owns the pipeline, and confirm current Gitea Actions behavior against the Gitea documentation for the version you plan to run, since feature coverage changes between releases.

Capabilities, licensing and limits compared

This table compares Bitbucket with Gitea on licensing, vendor support, databases, platforms, packages, CI, limits and managed options. Read the Gitea column as a starting point to confirm in your own configuration, since several of its limits depend on how you deploy it. The main takeaway is that Gitea's licensing and deployment footprint are simpler, while its limits and support terms need checking before a decision.

Capability	Bitbucket	Gitea
License	Proprietary Atlassian product, sold as Bitbucket Cloud and Bitbucket Data Center	MIT licensed, written in Go
Governance and vendor support	Atlassian operates Bitbucket Cloud and sells Data Center under its commercial terms	CommitGo, Inc. provides leadership and commercial support and sells Gitea Enterprise
Databases	Managed by Atlassian in Cloud, customer-operated in Data Center (confirm supported versions with Atlassian)	MySQL, PostgreSQL, SQLite and MSSQL
Operating systems	Cloud service with no customer OS; Data Center runs on customer servers (confirm supported platforms with Atlassian)	Linux, macOS and Windows, including small systems such as a Raspberry Pi
Package registries	Not a general package registry; teams pair Bitbucket with separate artifact tools	More than 20 registry types, including npm, PyPI, Maven, container images and Helm charts
CI	Bitbucket Pipelines in Cloud; Data Center relies on separately hosted build tools (confirm current options)	Gitea Actions, designed to be compatible with GitHub Actions
Repository and file size limits	Bitbucket Cloud enforces a 4 GB repository limit and a 1 GB total storage limit on Free workspaces	Set by your server, reverse proxy and storage configuration; confirm limits for your deployment
API request limits	Bitbucket Cloud allows 1,000 requests per hour for most API resources	Limited by your own server configuration; confirm rate limiting settings before bulk exports
Managed options	Bitbucket Cloud is the hosted option; Data Center is self-managed	Gitea Cloud is a managed service, alongside self-hosted installs

How hosting location changes data control and compliance

Where your repositories, identities and audit records sit decides which controls you can prove and who operates them. The cards below cover the hosting models Bitbucket and Gitea offer, and the controls to confirm in each before you commit to a platform.

Data location and residency

Bitbucket Cloud is not among the Atlassian products with data residency, so EU or other regional storage requirements need a separate answer. Ask Atlassian directly which data regions apply to your contract and whether Data Center or the Hybrid License changes that position. With self-hosted Gitea, the storage location is the server and database you choose, including on-premises or in an air-gapped network. Confirm backups and mirrors stay in the same region.

Hosting models compared

Bitbucket Cloud is run by Atlassian, while Bitbucket Data Center under the Hybrid License runs on your infrastructure with Atlassian's cloud option alongside it. Self-hosted Gitea runs entirely in your environment, and Gitea Cloud is a managed service on Gitea's side. Each model shifts patching, backup and access responsibility differently. Map which team operates each layer before the choice is made.

Identity and SSO

Check how each platform authenticates your staff, since identity is often the first control an assessor reviews. Gitea Enterprise adds SAML 2.0 service provider support, so your identity provider can manage sign-in and deprovisioning. Confirm whether your Bitbucket plan supports the SSO and user lifecycle controls you need, and whether Gitea's community edition meets your requirements without the commercial add-on.

Audit logging

Audit logs record who changed branch protections, repository permissions and access tokens. Gitea Enterprise adds audit logging, so a self-hosted Gitea deployment without it needs another source for these events. Ask Atlassian what audit events Bitbucket retains, how long they are kept, and how you export them. Decide where logs are forwarded so that retention meets your policy.

Two-factor and access enforcement

Mandatory two-factor authentication and IP allowlisting limit who can reach source code and from where. Gitea Enterprise includes both, plus organization-level branch protection inheritance. For Bitbucket, confirm which enforcement settings apply to your plan and whether they cover API tokens and SSH keys. List each enforcement control you rely on and test it against an account that should be blocked.

Evidence and assessor responsibilities

DeployOpen prepares controls, configurations and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Before an assessment, agree in writing which controls the platform team will evidence and which the auditor will test. Keep configuration exports and access reviews in a location that you control.

Editions and support: what you buy from each side

Bitbucket Cloud is a hosted service that Atlassian operates. You buy a subscription for your workspace, and Atlassian runs the platform, its storage and its upgrades. Your team still controls users, access settings, branch rules and how repositories are organized, but it does not run servers or schedule maintenance windows for the forge itself.

Upgrades and patches: Atlassian applies platform changes on its own schedule, so accountability for the service infrastructure sits with the vendor.
Support: Support is governed by your Atlassian plan terms. Confirm response targets and severity definitions in writing, because they vary by plan.
Data location: Bitbucket Cloud is not among the Atlassian products with data residency. If in-region storage matters to you, confirm where repositories are stored before you sign.
Limits: Free workspaces have a 1 GB total storage limit, and most API resources allow 1,000 requests per hour, which shapes any bulk export plan.
Roadmap and pricing: Ask for notice periods on changes to plan tiers, pipeline minutes and seat rules.

Before renewal, confirm what happens to repositories, pull requests and user records when the subscription ends, and how much history an export can carry.

What each side charges for and what drives the bill

Bitbucket charges through seats, build minutes and runner fees, or through a Data Center or Hybrid License renewal. Self-hosted Gitea moves those charges onto servers, storage, backups, upgrades, runners and people, and some of them are one-time while others recur every year.

Bitbucket seats and build fees

On the hosted side, you pay per user or workspace seat and for pipeline minutes or runner slots, depending on the plan. Seat counts grow with contractors and service accounts, and CI volume grows with every pull request. Before you compare, export a current invoice and list which accounts and build hours it really covers, then ask Atlassian to confirm how renewal pricing changes once the contract ends.

Data Center and Hybrid License renewals

If you run Bitbucket Data Center, the recurring charge is a subscription renewal, and Atlassian's Data Center end of sale changes what you can buy next. Atlassian's journey-to-cloud guidance describes a Hybrid License for existing customers, so ask in writing which products, user tiers and support terms that license covers and for how long. This line item is the one most likely to move at renewal.

Servers, storage and backups

Self-hosting moves compute, disk and backup costs onto your cloud account or data center. Repository size matters here, because large binaries and LFS objects grow storage and backup windows. Model the hardware or instance size for your user count, plus replicated storage and off-site backups of repositories, the database and attachments. These costs recur monthly or yearly and rise with repository history.

Upgrades, runners and CI capacity

Gitea Actions is designed to be compatible with GitHub Actions, but you run its runners yourselves, so runner hosts, autoscaling and job isolation become your cost. Upgrades recur as well: plan staff time for each Gitea release line and for testing your backups after every upgrade. Ask what runner capacity your current Bitbucket Pipelines usage would need on your own hardware.

Support from CommitGo or a partner

Gitea is MIT licensed, so the software itself has no license fee. Commercial support comes from CommitGo, which sells Gitea Enterprise with features such as SAML 2.0 service provider support, audit logging and mandatory two-factor authentication. Ask CommitGo for a written quote covering the edition, the support hours and the number of instances, and compare it with an implementation partner's fixed-scope support retainer.

One-time migration and staff time

The one-time costs are the migration project, environment setup, hardening and the re-creation of branch permissions, because Gitea has no Bitbucket importer for pull requests and comments. Staff time is often the largest line, covering administration, on-call and security patching. Ask any vendor or partner for effort estimates in person-days, the assumptions behind them, and which items are fixed and which are time and materials.

What a move from Bitbucket to Gitea involves

The sequence turns Bitbucket repositories, history, review records and pipelines into a working Gitea instance, with a parallel period that proves the move before teams cut over. Each step produces a checked artifact the next step depends on.

Inventory repositories, LFS objects and branch permissions
List every repository in the Bitbucket Cloud workspace or Data Center instance, with its size, whether it uses Git LFS, its default and protected branches, its webhooks, and the users and groups that hold access. Mark which repositories are active, which are archived, and which can be retired. Your platform or IT team usually owns this inventory, with repository owners confirming their own projects. The step is done when you have a signed-off list that maps each active repository to a target owner and a target permission model. Bitbucket Cloud and Data Center expose repository and permission data through their APIs, and the time this takes depends on repository count and how much the permission model has drifted over the years. Confirm the export method against your Bitbucket edition before you start.
Mirror Git history and LFS objects into Gitea
Create the target repositories in Gitea and push full mirrors of each Git repository, including all branches and tags, using a Git mirror clone. Migrate LFS objects separately if the repositories use Git LFS, and check that Gitea is configured to store them at the size you need. Run a clone of the source and compare commit counts, branch lists and tag lists against the target for a sample of repositories, then for all of them in a dry run. The output is a set of Gitea repositories whose refs match Bitbucket and whose LFS pointers resolve. Confirm the LFS path and storage limits in the Gitea documentation for the version you deploy, since configuration keys vary by release.
Export pull requests, comments, issues and wiki separately
Gitea's migration code has no Bitbucket importer, so pull requests, review comments, inline discussions, issues and wiki pages do not move with the Git mirror. Plan a separate export through the Bitbucket REST API, storing the data as files your team can read and search. Bitbucket Cloud limits most API resources to 1,000 requests per hour, so schedule long exports and cache results. Decide which records must be re-created as Gitea issues, which are kept as read-only archives, and which are not carried over. The step is done when each source record has a stored copy or a recorded decision, and the team has agreed on how the archive is accessed after cut over.
Re-create permissions, teams and branch protection
Create the organizations, teams and user accounts in Gitea that match the inventory from the first step, and apply branch protection rules to the default and release branches. Connect identity through the authentication method your organization uses, and confirm how account provisioning and removal will work for people who join or leave. Compare effective access for a sample of users in Bitbucket and Gitea, since group inheritance does not map one to one. Gitea Enterprise adds SAML 2.0 support, mandatory two-factor authentication and organization-level branch protection inheritance, so confirm with CommitGo which of these your standards need before you design the model. The output is a permission matrix that the security team has reviewed.
Convert Pipelines to Gitea Actions or another CI
Inventory each Bitbucket Pipelines configuration, its variables, deployment environments, and the secrets it uses. Pipelines variables that are marked secured cannot be read back through the Bitbucket interface, so you must obtain those values from their owners and store them in Gitea's secret store or your chosen secrets manager. Translate each bitbucket-pipelines.yml into a Gitea Actions workflow, which is designed to be compatible with GitHub Actions, or choose another CI system if a pipeline does not fit. Run each converted workflow against a test branch and compare the artifacts and deploy results with the Pipelines run. Confirm runner capacity, since Gitea Actions needs runners that you operate. The step is done when every pipeline has a passing equivalent and a named owner.
Update Jira, webhooks and external integrations
List every webhook, commit status check, Jira connection, deployment integration and bot that touches Bitbucket. Bitbucket links commits and pull requests to Jira issues through Atlassian's integration, which does not carry over to Gitea, so decide how issue references will be kept, whether through a Jira connector, a link convention or a replacement tracker. Point webhooks at Gitea endpoints, update service accounts and tokens, and test each one with a sample event. The output is a register of integrations, each marked as migrated, replaced or retired, with the test evidence attached.
Run a parallel period with both systems
Keep Bitbucket read-write for a defined window while teams work in Gitea on a subset of repositories, or mirror changes from Bitbucket into Gitea until cut over. Track defects reported by developers, failed pipelines, missing webhook events and permission complaints in a single list. Set the length of the window with the platform owner and the affected teams, since it depends on repository count and how much your teams depend on Pipelines. The step closes when the defect list has no open blocking items and every team lead has confirmed their repositories work in Gitea.
Cut over and archive the Bitbucket source
Freeze pushes to each Bitbucket repository, run a final mirror and LFS sync into Gitea, confirm the refs match, then update clone URLs in developer tooling and documentation. Set each Bitbucket repository to read-only or archive it once the archive from the export step is verified. Keep the Bitbucket export and the migration logs under your records retention policy, and confirm with your compliance owner what evidence they must retain. The output is a Gitea instance serving all active repositories, a signed cut over record, and an archive that someone on the team can open and search.

Questions buyers ask before choosing Gitea over Bitbucket

What drives the cost of moving from Bitbucket to Gitea?

The cost depends on who pays for which part of the move. Bitbucket costs are recurring, covering seats, build minutes or runner fees, or a Data Center or Hybrid License renewal. Gitea itself is MIT licensed, so the main one-time and recurring costs sit in servers, storage, backups, upgrades, support and staff time. Repository volume, the number of pull requests and comments to carry over, the size of Git LFS content, and how many Pipelines workflows must be rewritten all push the effort up. Ask any quote to break out each of these components separately, including who performs the migration, what is one-time and what recurs, and what a support contract covers.

How long does a Bitbucket to Gitea migration take?

No duration is fixed by the product, so the timeline comes from the scope you agree. Git history can be mirrored quickly, but the time to move pull requests, comments, branch permissions and CI pipelines depends on how much history you keep, how many repositories are in scope and how many workflows need rewriting. Bitbucket Cloud API rate limits of 1,000 requests per hour for most resources, documented by Atlassian, can stretch bulk exports of pull request history. Ask for a written scope with phases, a repository inventory and a cutover plan before agreeing to any timeline.

What does our internal team need to provide during the move?

Your team needs to supply access, decisions and sign-off. Expect to name owners for each repository group, confirm which branch protection rules and reviewer requirements must carry over, and provide Bitbucket and Gitea administrator accounts. Engineering leads should decide what happens to open pull requests, and security staff should confirm how SSO, two-factor authentication and audit needs will be met. Gitea's own documentation describes the platform's admin and access settings, so ask your implementation partner to map each Bitbucket permission to a Gitea equivalent in writing.

Can our team migrate from Bitbucket to Gitea without outside help?

A small team with Git and Linux administration experience can mirror repositories and run a Gitea instance without outside help. The harder parts are pull request and comment history, permission mapping, CI conversion and backup and upgrade routines. Gitea's migration code has no Bitbucket importer, so those items need a custom export and import plan. Decide early whether your team has the capacity to own that plan for the duration of the move. A fixed-scope engagement with DeployOpen can cover planning, implementation, hardening, backups, documentation and handover, with the written scope setting what is included.

How do we move pull requests and comments without a Gitea importer?

Pull requests and comments do not transfer through Git, so they need a separate export and import path. Git history moves with a clone or mirror, but Gitea's migration code lists importers for GitHub, GitLab, Gitea, Gogs, OneDev, GitBucket, Codebase and AWS CodeCommit, and not Bitbucket. Common approaches include exporting pull request data from the Bitbucket API into a structured archive, then recreating key records as issues or documented review notes in Gitea, and keeping the original Bitbucket read-only for history. Decide which records are legally or operationally required before choosing a method, and test the approach on one repository first.

Do we need Gitea Enterprise or a partner for production support?

Gitea itself is free to self-host, but production support is a separate decision. CommitGo, Inc. 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. Confirm with CommitGo which features and support levels are included in any Enterprise quote. Separately, a services partner can plan, implement, back up, upgrade and document your instance under a written scope, and ongoing support and upgrades are available as retainers.

How do Bitbucket Pipelines convert to Gitea Actions?

Gitea Actions is designed to be compatible with GitHub Actions, so workflows written for that syntax are the most likely to port with limited change. Pipelines configurations do not convert automatically, so each bitbucket-pipelines.yml pipeline needs to be read, rewritten and tested. Pipelines variables and secrets cannot be read back from Bitbucket, so they must be re-entered in Gitea, and runners must be provisioned on your own infrastructure. Confirm compatibility for each action you use, and run each converted workflow against a test repository before cutover.

How does Gitea Cloud differ from self-hosting Gitea?

Gitea Cloud is a managed service offered alongside self-hosted installs, so the provider runs the platform and you rely on its operating model. Self-hosting keeps the server, storage, backups and upgrades under your control, which matters if data location or internal policy requires it. Ask Gitea which regions, backup terms, data handling commitments and support levels apply to Gitea Cloud, and compare them with the controls you would own in your own datacenter or cloud account, including the staffing needed to run them.

How DeployOpen helps you evaluate and move from Bitbucket to Gitea

DeployOpen plans and implements self-hosted Gitea inside your own infrastructure, so the decision to move from Bitbucket is tested against your repositories, pull requests and CI needs before any cutover. Work is agreed as a fixed scope with written deliverables, and ongoing support is available as a retainer.

How we scope

Inventory repositories, LFS usage, pull request history, wikis and branch permissions to define what must move.
Identify which pull request comments and review data need a separate export plan, since Gitea has no Bitbucket importer.
Document the Pipelines jobs, variables and Jira links that need a replacement, and agree the gaps in a written scope.

How we build

Deploy Gitea in your cloud account, data center or air-gapped network, with the database backend your standards require.
Mirror Git history and LFS objects, then rebuild branch protections, teams and access rules to match your current model.
Set up Gitea Actions workflows for the build and test jobs you move off Pipelines, and test them before cutover.

How we hand over

Provide runbooks for installation, backup, restore, upgrades and user onboarding inside your own environment.
Record which data was migrated, which was archived outside Gitea, and which items were deliberately left behind.
Walk your administrators through the deployed configuration so your team can operate the forge after handover.

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer after the initial handover.
Plan Gitea version upgrades against your own change windows and test each release on a staging copy first.
Confirm with CommitGo whether its commercial support or Gitea Enterprise features fit your requirements before you decide.

Bitbucket vs Gitea