3 self-hosted Bitbucket alternatives

Last reviewed Oct 11, 2026 · 601 words

For most teams leaving Bitbucket, the right self-hosted target is Forgejo or Gitea, not the Gogs or RhodeCode cards above: both are single Go binaries the directory rates Easy at an estimated 256 MB of RAM, both have built-in CI that runs GitHub Actions-style workflows, and moving the Git data itself is a two-command job. The one reason to choose GitLab CE instead is if you need your open pull requests and their review history carried over, because GitLab ships an importer for Bitbucket and the lightweight forges do not.

What you gain and what you give up

Gained: no per-user pricing or build-minute allowance, source code on hardware you control, and CI runners sitting next to your internal services. Given up: the Atlassian integration story (Jira issue links, smart commits, and Confluence embeds that work without configuration), Bitbucket Pipelines' hosted runners, and zero-maintenance operation. Teams still on Bitbucket Server should also know Atlassian ended support for its Server products in February 2024, so self-hosting Atlassian now means Data Center licensing; an open-source forge is the cheaper exit.

Which forge fits which team

Gitea and Forgejo are close relatives: Forgejo is the community-governed fork that split from Gitea in 2022, and the catalogue notes it has a smaller ecosystem in exchange. Gogs is the project both descend from; it is the lightest of all but develops more slowly, and lacks built-in CI. GitLab CE is a full DevOps platform with registries and security scanning, and the catalogue is blunt that it is resource hungry and complex to operate. RhodeCode only makes sense if you also keep Subversion or Mercurial repositories.

How the migration actually goes

Repositories are the easy part. For each one, clone with every branch and tag, then push the whole thing to the new server:

git clone --mirror https://bitbucket.org/acme/api.git
cd api.git
git push --mirror https://git.example.com/acme/api.git

Gitea and Forgejo can also do this from their web UI by migrating from a plain Git URL, optionally keeping the new repository as a pull mirror while you transition. Git LFS objects need fetching and pushing separately if you use them. Pull requests, comments, and Bitbucket issues are where the paths diverge: GitLab's Bitbucket importer brings pull requests across as merge requests, while on Gitea or Forgejo the practical approach is to merge or close open PRs before the cutover and keep Bitbucket read-only for history. bitbucket-pipelines.yml does not translate automatically. Each pipeline gets rewritten as an Actions workflow (Gitea or Forgejo) or a .gitlab-ci.yml, and deployment secrets get re-entered on the new side.

What I'd do

Run Forgejo with a Forgejo Runner on the same host, mirror every repository, rewrite your two or three most important pipelines first, and set Bitbucket to read-only once builds pass. Pick Gitea instead if you prefer its larger ecosystem, and the Forgejo vs Gitea comparison covers how far they have drifted apart. Choose GitLab CE only if importing open pull requests matters more to you than a 4 GB RAM floor and a heavier upgrade routine.