GitHub Alternatives: Hosted Git, Self-Hosting and Migration

The right GitHub alternative depends on what you are replacing: a remote Git repository, a collaboration platform, a CI service, or the organisation that operates the hosting. Those are different decisions. Moving commits is relatively contained; moving reviews, build credentials and contributor habits is a project of its own.

For hosted Git with integrated CI, start by evaluating GitLab. For a forge on infrastructure you control, compare Gitea and Forgejo. For an eligible Free Software project, consider Codeberg. SourceHut belongs on the list if its contribution workflow fits your maintainers. These are recommendations based on documented capabilities, not results from running the servers.

GitHub alternatives by hosting responsibility

Sources: GitLab, Gitea, Forgejo, Codeberg and SourceHut, checked October 26, 2026. GitLab.com's hosted Free limits are not a description of every self-managed GitLab installation.

SourceHut's pricing needs a careful reading: during its public alpha, payment is optional for most services but required for builds and chat. People contributing to a hosted project are not all required to buy subscriptions. Do not multiply a subscription figure by every occasional contributor without checking the service's actual rules.

Choose a platform around the work after git push

For a small commercial team, count the people in your top-level GitLab group before relying on its hosted Free plan. Then inventory build minutes, artifact storage and any deployment integrations. A plan can be free for repository hosting and still fail your CI budget.

Gitea and Forgejo make the operating boundary explicit: you choose the machine and storage, and you own recovery when they fail. That suits a team with an operator and a reason to control hosting. It is less attractive when nobody is responsible for restoring a deleted repository, applying updates or rotating runner credentials. Free software does not remove those jobs.

Codeberg is a community service with a Free Software mission. It should not be presented as unrestricted, no-cost storage for proprietary company repositories. Read the service's current terms for your project before treating it as a destination.

If your reason for leaving GitHub is an AI or data-use policy, read each destination's current terms separately. A license on forge software does not establish how a hosted provider uses data, and moving to another brand does not itself establish a different policy. This article makes no provider-specific AI training guarantee.

For a closer comparison of the integrated platform, read GitLab alternatives. The free Git client guide addresses desktop clients rather than repository hosting, so changing clients should be evaluated separately from moving a forge.

What a Git mirror does and does not move

GitHub's repository duplication guide describes a bare clone followed by a mirror push. This preserves repository refs, including branches and tags. Repositories using Git LFS require separate LFS fetch and push steps.

A repository that clones successfully is only the first acceptance check. A release engineer must still be able to publish, a contributor must still be able to open a review, and a restricted account must still be denied access.

A migration pilot with a clear rollback point

Start with a low-risk repository that resembles your real workflow. Record the source's branches, tags, LFS use, branch rules, integrations and latest successful release. Create an empty destination repository before using a mirror push: mirror operations can overwrite destination refs, so do not aim them at a repository containing work you need.

1. Transfer Git history and LFS data using the destination's supported process. Compare expected refs and test a clean clone from a second environment.
2. Check whether an importer supports your issues and reviews. If it does not, keep an accessible archive with links from the new project.
3. Rebuild CI with new credentials. Validate a pull request, a protected-branch merge and a release job; confirm which system is allowed to deploy.
4. Recreate permissions and webhooks. Test with a maintainer account and a restricted account rather than relying on the administrator view.
5. Set a cutover window. Freeze writes on the old forge, reconcile final changes, update remotes and document how to restore service if acceptance fails.

Avoid two writable copies without a reconciliation plan. They can diverge while both appear healthy. Preserve the original repository until the destination's recovery, permissions and release path have been checked.

When staying on GitHub costs less

Keep GitHub if external contributions, Actions integrations and release tooling are the work you would spend weeks rebuilding without a clear gain. Choose GitHub alternatives when the hosting requirement, cost model or operating control is concrete enough to justify that work. A good migration ends with a functioning contribution and release process, not just a new remote URL.