How to Migrate from GitHub to Codeberg

Why Migrate from GitHub to Codeberg?

GitHub is the dominant Git hosting platform in 2026. It’s also owned by Microsoft, hosted on US infrastructure subject to the CLOUD Act, and increasingly turning into an AI training-data source whether you opted in or not. For European open-source projects, individual developers, and organizations that want their code under EU jurisdiction, Codeberg is the credible alternative.

Codeberg is a German non-profit Git hosting service built on Forgejo (the community-maintained fork of Gitea). Free for open source projects, donation-funded, EU-resident, and built explicitly around the values of FOSS sustainability and digital sovereignty. The closest thing the open-source community has to a “GitHub but European.”

For commercial proprietary code, the natural alternative is self-hosted Forgejo on Hetzner — same software, hosted on your own infrastructure, costing roughly €5-30/month total regardless of team size. This guide focuses on Codeberg specifically, but the migration steps work identically for self-hosted Forgejo.

Detailed Migration Steps

Step 1: Create a Codeberg Account

Visit codeberg.org and create an account. Free, requires only email. No credit card.

For organizations migrating, create an organization account after individual signup — this lets you transfer or fork repositories under the org namespace.

Step 2: Decide What to Migrate

Be selective. Migration is faster when you’re not bringing along ten years of dead repositories.

Migrate fully:

• Active open-source projects
• Personal projects you’d be sad to lose if GitHub became hostile
• Repositories with sensitive code or business logic

Consider mirroring (read-only sync GitHub → Codeberg):

• Inactive but referenced repos
• Public projects where GitHub visibility still matters

Skip / archive:

• Long-dead personal experiments
• Repos that exist only as references or forks

For commercial proprietary code, evaluate self-hosted Forgejo on Hetzner instead of Codeberg. Codeberg’s mission is open-source community hosting; commercial repos are accepted but the platform’s character fits FOSS work better.

Step 3: Use Codeberg’s GitHub Import

Codeberg has a built-in GitHub import:

1. Click + → New Migration
2. Choose GitHub
3. Authenticate with GitHub OAuth (or use a personal access token)
4. Select the repository to import
5. Choose what to migrate:
   • ✅ Wiki
   • ✅ Issues
   • ✅ Labels
   • ✅ Pull Requests (as Issues, since GitHub PRs ↔ Codeberg PRs aren’t 1:1 compatible)
   • ✅ Releases
   • ✅ Milestones
6. Click Migrate Repository

For repositories with thousands of issues, the migration may take 30-60 minutes. Don’t worry about doing other work during this — Codeberg handles it asynchronously.

Step 4: Update CI/CD References

Codeberg uses Woodpecker CI (analogous to GitHub Actions). Translate your .github/workflows/*.yml to .woodpecker.yml:

# Example: .woodpecker.yml
steps:
  build:
    image: node:20
    commands:
      - npm install
      - npm run build
      - npm test

For complex GitHub Actions workflows, the translation can be non-trivial. Pragmatic alternatives:

• External CI providers that support Codeberg: Drone Cloud, CircleCI (with their generic Git integration)
• Self-hosted CI on Hetzner: GitLab Runner pointed at Codeberg, or self-hosted Woodpecker

For most projects, the workflow translation takes a few hours and produces simpler, more readable CI configuration.

Step 5: Set Up SSH Keys and Git Remotes

Add your SSH key:

1. Codeberg → User Settings → SSH/GPG Keys
2. Paste your public key

Update local Git remotes:

# Change remote from GitHub to Codeberg
git remote set-url origin git@codeberg.org:username/repo-name.git

# Or add Codeberg as additional remote (for parallel-run period)
git remote add codeberg git@codeberg.org:username/repo-name.git
git push codeberg --all
git push codeberg --tags

Step 6: Update READMEs and Badges

GitHub-specific badges and links need updating:

• Build status badges → use Woodpecker CI badges
• Version badges → Codeberg supports shields.io patterns
• Download counts → Codeberg releases have similar APIs
• Issue links in docs → update from github.com/user/repo/issues to codeberg.org/user/repo/issues

Step 7: Set Up GitHub Mirror (Optional)

For projects where GitHub visibility still matters (open source projects discovered through GitHub search), keep GitHub as a read-only mirror:

# Codeberg has a built-in "Push Mirror" feature
# Repository Settings > Repository > Push Mirror
# Add github.com/user/repo with personal access token

This keeps Codeberg as your source of truth while maintaining GitHub presence.

Step 8: Archive or Delete GitHub Repos

After 30 days of confidence:

• Archive (recommended): Repository Settings → Archive this repository. Read-only, preserves history, signals “moved” to visitors.
• Delete (if you’re certain): Settings → Danger Zone → Delete this repository.

Both options work. Archiving is the safer default — it preserves the migration trail and gives you fallback if you discover something that didn’t migrate.

Tips for a Smooth Migration

• Migrate one repository first as a test. Pick a low-stakes repo to validate the workflow before committing to bulk migration.
• GitHub Actions complexity is the main migration friction. If your workflows use third-party Actions heavily, plan time to translate or replace them.
• Codeberg’s API is similar but not identical to GitHub’s. Custom tooling that calls GitHub API will need updating to use Codeberg’s Forgejo-compatible API.
• Codeberg’s resource limits are designed for FOSS. If you have very large repos or run extensive CI, consider self-hosted Forgejo on Hetzner — same software, your own resources.
• Donate. Codeberg is donation-funded. If you’re using it long-term, contribute to keep it sustainable. €5-10/month is meaningful for the project.
• For organizations migrating large codebases: consider self-hosted Forgejo as primary with Codeberg mirror for community projects. Best of both — full control + visibility where it matters.
• Don’t migrate everything at once. Most companies that successfully migrated to Codeberg did it project-by-project over 3-6 months, validating each before moving on.