Bitbucket vs Forgejo

Server and storage are mostly recurring cost, paid as cloud instances, data center capacity or hardware depreciation, and they scale with the number of users, repository size and how much history and LFS content you keep. Repository growth is the main driver: hosted services set their own limits, such as GitHub's guidance to keep a repository's .git folder under 10 GB, so plan for storage headroom and for the disk and bandwidth that clones and CI artifacts consume. Ask the provider or your infrastructure team for the instance sizes, storage tiers, redundancy level and egress terms behind any estimate, and confirm whether your data center already provides this capacity.

Backups are recurring, and they cover both the repository data and the database, attachments and configuration. Costs rise with retention period, backup frequency, the number of copies you keep off site and the time you need to restore. Confirm your backup target, retention policy and restore test schedule, and include the storage and staff time those tests take. Forgejo's command-line tools can export individual repositories, but a full backup plan is still your responsibility, so budget for it as an ongoing operation rather than a one-time setup.

Upgrades are recurring work that you schedule against Forgejo's release cadence. Stable releases get three months of full support plus a two-week window, and LTS releases receive critical bugfixes and security support for one year and three months, so the interval you choose determines how often you touch production. If you migrate from Gitea, the Forgejo upgrade guide describes a two-step path for installations up to Gitea v1.22, which is a one-time project. Ask for the upgrade test environment, the rollback plan and the expected staff hours per upgrade cycle.

Runner capacity is recurring and is the Forgejo equivalent of Bitbucket Pipelines build minutes or runner slot fees, except that you pay for the machines rather than for minutes. Forgejo Actions hands workflows to separate runners, so cost depends on how many concurrent jobs you need, the CPU, memory and disk per job, and whether runners are always on or scale up on demand. Heavy builds, container image builds and long test suites usually drive the largest share. Ask for a sizing review based on your pipeline run history and for a clear split between runner hardware, its operation and any cloud build capacity you add.

Staff time is the largest cost component for many teams, and it recurs. It covers platform administration, access management, monitoring, security patching, runner maintenance, user support and migration work. A small team may absorb this into existing platform duties, while a regulated organization often needs a named owner, documented procedures and an on-call path. Compare these hours against what Bitbucket seats, build minutes or a Data Center or Hybrid License renewal would otherwise cost, and include the hours for pull request and CI migration as a one-time item.

Forgejo is community-governed, and the project's own support model is community and documentation based, while commercial support comes from a provider you contract. Support is recurring if you buy a retainer, and it can be bundled with upgrades, monitoring and testing. Ask any provider what response times they commit to in writing, which Forgejo versions they cover, who handles security fixes, and what happens during a release change. Forgejo's FAQ and release pages describe the project's support windows, so use those dates when you compare quotes.

Ask for a written scope that separates one-time work from recurring work. One-time items usually include the migration of repositories, pull requests and CI definitions, identity integration and the initial hardening. Recurring items usually include infrastructure, backups, upgrades, runner capacity, monitoring and support. Request assumptions for user count, repository count and size, pipeline volume, retention period and the Bitbucket plan you are replacing, so you can compare fairly against Bitbucket Cloud seats, build minutes or a Data Center or Hybrid License renewal. DeployOpen issues a quote from the written scope, and engagements are typically fixed-scope.

The effort depends mainly on how much history you need to carry across, how many repositories depend on Bitbucket-specific features, and how many pipelines must be rebuilt. Plain Git history moves with a clone or mirror, which is the simple part. Pull requests, review comments, issues and wikis need a separate plan, because Forgejo's dump-repo command does not list Bitbucket as a source. The main drivers are the count of repositories, the volume of open pull request history you want to keep, Bitbucket Pipelines configurations to rewrite for Forgejo Actions, and branch permissions and user access to re-create. Ask any provider for a written inventory of these four items before agreeing on a figure.

A team with Git administration experience and someone who can run a Forgejo server can move plain repositories without outside help. Work is harder when the team must script pull request exports through the Bitbucket API, respect rate limits during bulk reads, and rewrite CI. Bitbucket Cloud limits most API resources to 1,000 requests per hour, so large exports need throttling and planning. Outside help is most useful for an inventory, a tested migration on a copy of the data, and a cutover plan. Decide early which parts your staff will own after go-live, such as backups, upgrades and user administration.

Expect work in four areas. First, server administration: installing Forgejo, configuring the database, reverse proxy, TLS, storage and backups. Second, CI rewrites: Forgejo Actions is built in and designed to be familiar to GitHub Actions users, but it is not compatible with GitHub Actions, and it is also not Bitbucket Pipelines, so each pipeline needs translation and testing with separate runners. Third, access mapping: map Bitbucket workspaces, projects, groups and branch restrictions onto Forgejo organizations, teams and branch protection. Fourth, identity: decide how users sign in and who approves access changes. Confirm each item against the current Forgejo documentation for your version.

No general duration can be given here without the inventory, because timing follows the scope. In broad terms, the schedule has four phases: inventory and design, a trial migration on copies of selected repositories, pipeline rewrites with testing, and a cutover with a fallback plan. Repository count, the depth of pull request history, and the number of CI pipelines with external integrations are the variables that extend the schedule most. Ask for a timeline tied to a written scope and a list of assumptions, and ask how the provider will handle items that fail the trial migration.

Git history moves easily, but pull request history needs a platform importer or a custom export. Forgejo's dump-repo command exports issues, pull requests, releases, labels, milestones, comments and wiki from git, GitHub, Gitea and GitLab, but Bitbucket is not on its list of sources. Practical options include exporting pull requests and comments from the Bitbucket API within rate limits and loading them into an archive, using a documented import path into an intermediate platform, or keeping old pull requests read-only in Bitbucket. Decide which records must be kept for audit, then confirm the export method and its fidelity for each record type before you rely on it.

Yes, Forgejo documents transparent upgrades from Gitea installations up to Gitea v1.22. The documented path has two steps: first to Forgejo v10.0.x, then to any later Forgejo version. This matters if you are already running Gitea and want to switch forges without moving repositories. It does not apply to Bitbucket directly, so a Bitbucket move still needs the export work described above. Check the upgrade guide for your exact Gitea version and back up data before each step.

Forgejo federation is experimental and under active development. It uses the ForgeFed protocol, which is based on ActivityPub. Treat it as a capability to watch, not one to plan a production workflow around. Your Bitbucket move should rely on standard Git hosting, pull requests, issues and backups that you can operate today. If cross-instance collaboration matters to your organization, ask the provider to show the current state of federation in the Forgejo version you plan to run and to document what is not yet supported.

Forgejo is governed by an independent project and its domains are held by Codeberg e.V., a non-profit association registered in Berlin. Its stable releases receive full support for three months plus a two-week window, while LTS releases receive critical bugfixes and security support for one year and three months. Forgejo v15 is the LTS release supported until July 15, 2027, and v17.0.0 is supported until January 28, 2027. Your choice is between running an LTS line for predictable patching and taking stable releases more often. Support contracts from outside providers, including DeployOpen retainers for upgrades and testing, are priced from a written scope, so ask for one.