Critical decisions about Git hosting influence security, velocity and cost. This comparison evaluates Forgejo and Bitbucket across performance, migration complexity, security/SSO, CI/CD integrations, and total cost of ownership (TCO) for teams based in England and across Europe. The article supplies reproducible benchmarks, a practical migration script set, a step-by-step migration checklist, and specific guidance for choosing the right platform by use case.
Executive feature comparison
A concise, actionable matrix helps identify the immediate strategic differences.
| Feature |
Forgejo (self-hosted) |
Bitbucket Cloud / Bitbucket Data Center (Atlassian) |
| Hosting model |
Self-host, container-friendly, full control |
Cloud-hosted SaaS and Data Center (self-managed) |
| Governance & licensing |
Open-source (GPL-style fork of Gitea lineage) |
Proprietary (Atlassian) |
| Cost profile |
Hardware + maintenance + ops |
Per-user SaaS or enterprise license; predictable subscriptions |
| Multi-repo scale |
Scales with infra; tuning required |
Managed scale with SLA (Cloud) or licensed scale (DC) |
| CI/CD |
Integrates with self-hosted runners and external systems |
Native pipelines (Bitbucket Pipelines) + integrations |
| Authentication |
LDAP, OAuth2, SAML via reverse-proxy/SSO |
SAML, OAuth, Atlassian Access for SSO |
| Issue tracking & PR UX |
Lightweight built-in features, plugin ecosystem |
Richer built-in workflows, PR checks, branch permissions |
| Backups & DR |
Operator responsibility; custom strategies |
Built-in backups for SaaS limited; DC offers enterprise options |
| Community & ecosystem |
Growing community, transparent governance |
Large Atlassian ecosystem, marketplace apps |
Benchmark goals and test environment
- Assess clone/push throughput over HTTP(S), API latency for repository listing, and CI-trigger throughput.
- Test environment: four-node Ubuntu 24.04 LTS cluster (2 control, 2 worker), 16 vCPU / 64GB RAM nodes, 10Gbps networking, NVMe storage.
- Tools: time, parallel, curl, wrk, git (2.40+), git-sizer, git-lfs where applicable.
Reproducible clone throughput test (commands)
-
Create a test repository mirror locally:
-
Mirror clone from Bitbucket or a representative repo:
git clone --mirror https://bitbucket.org/team/example-repo.git /tmp/example-repo.git
cd /tmp/example-repo.git
git remote add forgejo https://forgejo.example.org/team/example-repo.git
time git push --mirror forgejo
- Run parallel clones and measure time:
seq 1 50 | parallel -j 10 'time git clone https://forgejo.example.org/team/example-repo.git /tmp/clone-{}'
seq 1 50 | parallel -j 10 'time git clone https://bitbucket.org/team/example-repo.git /tmp/bb-clone-{}'
- Record CPU, disk I/O, and network during tests with sar/iostat and iftop.
API list/latency test (wrk example)
wrk -t12 -c200 -d30s 'https://api.bitbucket.org/2.0/repositories/team?pagelen=50'
wrk -t12 -c200 -d30s 'https://forgejo.example.org/api/v1/users/team/repos'
Interpreting results
- For self-hosted Forgejo, performance will track available CPU, NVMe throughput and web server tuning (nginx, keepalive, gzip, http2). For Bitbucket Cloud, peak throughput is constrained by vendor limits but benefits from global CDN and managed scale. Documented anomalies should be traced to bottlenecks: database (Postgres), I/O, or reverse proxy.
Recommended tuning checklist
- Enable HTTP keepalive, gzip and (where safe) HTTP/2.
- Configure PostgreSQL connection pooling (PgBouncer) and tune shared_buffers/work_mem.
- Use LFS for large binaries; configure a dedicated LFS server or proxy.
Sources and references: Atlassian pipeline limits and Bitbucket API docs are available at Bitbucket API and Forgejo project resources at Forgejo official.

Migration: step-by-step practical guide and scripts
When to choose migration from Bitbucket to Forgejo
- Strict data residency and full control over infrastructure required.
- Desire to avoid vendor lock-in and adopt an open-source code forge.
- Teams with internal SRE capacity and desire to optimize TCO via self-hosting.
Core migration phases
- Inventory and audit
- Code and repository transfer (git mirror)
- Issues, PRs and metadata migration
- CI/CD and pipeline migration
- Cut-over, DNS and access control
- Backups and DR verification
Practical scripts and examples
Repository mirror push (safe, reproducible):
set -e
SRC_URL="$1" # e.g. https://bitbucket.org/team/repo.git
DST_URL="$2" # e.g. https://forgejo.example.org/team/repo.git
TMP_DIR=$(mktemp -d)
echo "Mirroring $SRC_URL -> $DST_URL"
git clone --mirror "$SRC_URL" "$TMP_DIR/repo.git"
cd "$TMP_DIR/repo.git"
git remote add dst "$DST_URL"
git push --mirror dst
rm -rf "$TMP_DIR"
echo "Mirror push complete"
Issue export example using Bitbucket API (JSON export) and import into Forgejo via API: a minimal curl-based approach:
curl -u USER:APP_PASSWORD "https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/issues" -o issues.json
curl -X POST -H "Content-Type: application/json" -H "Authorization: token TOKEN" /
-d @issues.json https://forgejo.example.org/api/v1/repos/{owner}/{repo}/issues
Note: Many teams prefer specialized migration tools such as fast-export or bespoke scripts using the Bitbucket API. A recommended resource is the Bitbucket API docs at developer.atlassian.com.
Common pitfalls and mitigations
- Detached metadata: pull request comments, reviewer states and CI status may not map 1:1 and require transformation.
- LFS objects: ensure LFS endpoint and objects are migrated; use git-lfs migrate export/import.
- User mapping: maintain consistent usernames or implement a mapping table to preserve attribution.
Security, compliance and authentication
Authentication and SSO
- Forgejo supports LDAP/OAuth2 integrations and can be extended with SAML via reverse proxies or middleware. For enterprise SSO with SAML and centralised control, integrate Forgejo with an identity provider (IdP) such as Okta or Microsoft Entra through a gateway like Keycloak.
- Bitbucket Cloud integrates with Atlassian Access for organization-wide SSO and policy enforcement; Bitbucket Data Center supports SAML natively.
Hardening and backups
- Self-hosted Forgejo: implement full-image backups, Postgres base backups (pg_basebackup), WAL archive, and repository-level snapshots. Test restore procedures quarterly.
- Bitbucket Cloud: rely on Atlassian SLAs for availability but maintain export snapshots for business continuity.
Authoritative references: SSO and enterprise guidance at Atlassian Access and security practices for open-source forges at OWASP.
CI/CD and integrations: sample pipelines and migration patterns
Native vs external CI
- Bitbucket Pipelines: quick-to-use native YAML pipelines with per-repo configuration and integrated caching.
- Forgejo: requires external runners (e.g., Jenkins, Drone CI, GitHub Actions runners adapted, or self-hosted Drone which integrates well with Gitea/Forgejo patterns).
Example Drone pipeline for Forgejo (drone.yml)
kind: pipeline
name: default
steps:
- name: test
image: golang:1.20
commands:
- go test ./...
- name: build
image: golang:1.20
commands:
- go build -v ./...
services:
- name: docker
image: docker:dind
Migration of pipelines
- Export pipeline definitions from Bitbucket (yaml) and adapt steps to CI choice (Drone, Jenkinsfiles, GitHub Actions runner).
- Recreate secrets in the new CI provider using injected vaults or secret-management systems.
Total Cost of Ownership (TCO): a practical example
Assume a 50-developer team over 3 years.
- Bitbucket Cloud (Standard) at $3.00/user/month and Premium at $6.00/user/month (reference pricing as listed by Atlassian): Atlassian pricing.
- Standard: 50 * $3 * 12 * 3 = $5,400 over 3 years
-
Premium: 50 * $6 * 12 * 3 = $10,800 over 3 years
-
Forgejo self-hosted (example conservative estimate):
- Infrastructure: 3 x m5.2xlarge-equivalent or on-prem hardware amortized: £6,000/year => £18,000 over 3 years
- SRE/ops: 0.25 FTE allocated cost (salary + overhead) estimate £25,000/year => £75,000 over 3 years
- Additional services (backup storage, monitoring) £3,000/year => £9,000
- Total ≈ £102,000 over 3 years
Interpretation: self-hosting often becomes cost-effective only with larger scale, strict compliance, or when operational efficiency and reuse of existing infrastructure reduce additional overhead. Pricing examples reference Atlassian pages and typical infrastructure costing; teams should model specific regional costs and staffing levels.
Decision checklist by use case
- Small teams (<10) who prefer low ops: Bitbucket Cloud Standard or free tier.
- Regulated environments requiring data residency and audit control: Forgejo self-hosted with documented DR policies.
- Teams requiring deep Atlassian integration (Jira / Confluence tight coupling): Bitbucket (Cloud or Data Center).
- Cost-sensitive at scale (100+ developers) with existing SRE capabilities: consider Forgejo self-host with optimized infra.
Migration checklist (condensed)
- Inventory repos, LFS usage, hooks and webhooks.
- Map users and preserve attribution policies.
- Test mirror push for a small set of repos.
- Migrate issues and PR metadata; validate mapping of comments and timestamps.
- Recreate CI pipelines and secrets; run smoke tests.
- Update DNS and access control; monitor for 72 hours post-cutover.
- Archive old environment with a final snapshot.
Frequently asked questions
How long does a typical migration from Bitbucket to Forgejo take?
A single small repository (under 1GB, few branches) can be mirrored in minutes. A full organizational migration with issues, PRs, CI pipelines and LFS objects generally requires 2–8 weeks for planning, testing and cutover depending on complexity.
Can pull request history and comments be preserved?
Repository commit history is preserved via mirror. Pull request states and threaded comments often require API-based export and transformation; some metadata mappings will need manual reconciliation.
Is Forgejo production-ready for large teams?
Forgejo is used in production across many organizations. Scalability depends on infrastructure choices and operational practices (Postgres tuning, object storage for large files, CDN). For enterprise SLAs, Bitbucket Data Center or Cloud with Atlassian support may be preferable.
What are the licensing and governance differences?
Forgejo is open-source and permits code inspection and self-hosting. Bitbucket is proprietary with paid tiers; governance and roadmaps are vendor-driven.
How to handle CI/CD parity when moving away from Bitbucket Pipelines?
Adopt an external CI system (Drone, Jenkins, GitLab CI runners) and convert pipeline definitions. Secrets and artifact storage must be migrated to the new system.
Tools and libraries exist for specific migrations (e.g., fast-export, bespoke scripts using the Bitbucket API). No universal tool preserves every metadata field; expect transformation scripts.
What security features differ significantly?
Bitbucket Cloud integrates with Atlassian Access for org-wide policy and SSO; Forgejo requires additional components (Keycloak, proxy SAML) for equivalent enterprise SSO and policy enforcement.
How to estimate operational overhead for Forgejo?
Estimate based on required uptime, backup RTO/RPO, security patching cadence and SRE staffing. A pilot migration and canary run provide realistic operational metrics.
Conclusion
Forgejo offers strong control, open-source governance and a flexible self-hosting model favoured when data residency, customization and vendor independence matter. Bitbucket provides rapid onboarding, integrated Atlassian product benefits and managed scale for teams wanting lower operational overhead. Decisions should hinge on compliance needs, available SRE resources, existing Atlassian investments, and a careful TCO comparison with the reproducible benchmarks and migration scripts provided above.
For further technical references and APIs, consult Bitbucket developer docs at Bitbucket API and Forgejo resources at Forgejo official.