Choosing a Git Host in 2026: The Complete Decision Matrix

Editor’s Note: This article is part of our definitive guide to GitHub Alternatives. Click here to read the main overview.

Table of Contents

• Introduction
• Start Here: Three Questions
• Platforms to Approach with Caution
• A Few Trends Worth Knowing About
• The Full Decision Matrix
  • All-in-One DevOps Platforms
  • Lightweight, Self-Hosted Forges
  • Cloud-Native and Vendor-Specific
  • Non-Profit, Community, and Decentralized
  • Specialized and Niche Platforms
• Quick Picks by Use Case
• Migration Difficulty at a Glance
• Related Tools, Not Hosts
• Conclusion

Introduction

Last verified: August 2026. This is a fast-moving space. Check the linked full review before making a final call. Pricing and availability change often.

This series has covered close to thirty ways to host Git repositories. Some are household names. Others most developers will never need, but should know exist. That’s genuinely useful depth. But it’s not something anyone can read start to finish before deciding.

This article is the shortcut. It pulls every platform covered so far into one place. Everything is organized by what actually distinguishes each one. That lets you narrow twenty-eight options down to two or three worth reading in full. Every row links back to the complete review for that platform.

One thing worth saying up front: a handful of platforms here aren’t live options anymore. Others come with a serious enough caveat. They shouldn’t be evaluated like an actively developed product. Those are called out explicitly below, not buried in a table. The fastest way to waste an afternoon is building a migration plan. Don’t do that around a platform that’s already discontinued.

Start Here: Three Questions

Before the matrix, answer these three questions in order. Each one points you toward a specific part of this guide.

1. Does your data need to stay on infrastructure you control? Maybe for compliance, cost, or principle. If yes, that rules out every SaaS-only platform. GitHub.com, Bitbucket Cloud, and Launchpad are all out. Go straight to Lightweight, Self-Hosted Forges, or the self-hosted rows in All-in-One DevOps Platforms. If no, cloud-hosted options are all on the table.

2. Do you actually need built-in CI/CD? If yes, look at All-in-One DevOps Platforms. If a separate CI tool is fine, don’t default to a heavyweight platform. Plenty of teams adopt one just for the CI/CD. They never touch half its other features. A lightweight forge like Gitea or Forgejo is often the better fit. Pair it with Jenkins or Buildkite instead.

3. Is what you’re hosting actually just ordinary application source code? If not, check Specialized and Niche Platforms. That covers unusual workloads like 500GB of game assets (Perforce) or Ubuntu packaging metadata (Launchpad). Or check Non-Profit, Community, and Decentralized instead. That’s the section for a codebase that needs to survive independent of any single company.

Platforms to Approach with Caution

These are covered in full elsewhere in this series. Don’t evaluate them as live, general-purpose options without reading the caveat first:

• JetBrains Space: Fully discontinued. JetBrains stopped selling new subscriptions in May 2024. It then retired a scaled-down replacement, SpaceCode, before that even left preview. Remaining subscriber access shut down on May 31, 2025. Full review.
• TaraVault: Retired by Inflectra in April 2025. Full review.
• Phabricator: Unmaintained since Phacility wound down operations in 2021. Still usable if self-hosted. It receives no updates or security patches. Full review.
• Google Cloud Source Repositories: Closed to new customers since June 2024. Existing users are unaffected. Google’s recommended path for new projects is Secure Source Manager. Full review and Secure Source Manager review.
• NotABug: As of mid-2026, its web UI remains intermittently inaccessible due to unmitigated AI scraper traffic. Its underlying Gogs fork also has unresolved critical CVEs. Worth reading about for what it represents. Not currently recommended as a primary host. Full review.
• AWS CodeCommit, for context: A genuine exception to the pattern above. It closed to new customers in 2024. That looked like the same fate as Cloud Source Repositories. But AWS reversed course and reopened it in November 2025. It’s back to being a live option. Full review.

That leaves 22 platforms below as genuinely live, actively developed options. GitKraken is also covered, as a related tool rather than a host.

A Few Trends Worth Knowing About

Two cross-cutting things don’t show up cleanly in a per-platform table. Both are worth knowing before you commit to one:

Federation is coming, unevenly. Forgejo is actively building ForgeFed-based federation. Codeberg is funding that work directly. Most other platforms here, including Gitea itself, aren’t pursuing this. If cross-instance collaboration matters to you long-term, that’s currently a Forgejo-specific bet. It’s not an industry-wide direction yet.

AI scraper traffic is now an operational risk for smaller forges. NotABug’s ongoing outages are the starkest example here. But it’s a broader pattern. Community-run infrastructure without significant capacity is increasingly vulnerable to aggressive AI crawlers. Larger, better-resourced platforms, Codeberg among them, have more room to absorb this. A single-maintainer instance usually doesn’t. Factor that into how much you trust a smaller host’s uptime.

The Full Decision Matrix

All-in-One DevOps Platforms

Git hosting, CI/CD, issue tracking, and usually more, bundled into one product.

Lightweight, Self-Hosted Forges

Git hosting first, with CI/CD and everything else treated as optional.

Cloud-Native and Vendor-Specific

Built to integrate tightly with one cloud provider’s ecosystem, at the cost of general-purpose flexibility.

Non-Profit, Community, and Decentralized

Platforms whose entire pitch is not being dependent on a single corporation.

Specialized and Niche Platforms

Solve one specific, non-general-purpose problem better than anything else in this series.

Quick Picks by Use Case

For readers who want a single answer rather than a table:

“I want GitHub, but free and self-hosted.” → Gitea, or Forgejo if community governance matters to you specifically.

“I need enterprise compliance, audit trails, and multi-VCS support.” → RhodeCode, or GitLab’s self-hosted Enterprise tier.

“I’m fully committed to one cloud provider.” → AWS CodeCommit, Secure Source Manager, or Azure DevOps, depending on which cloud.

“I want zero infrastructure to run and maximum independence from any one company.” → Codeberg for an actively growing non-profit. SourceHut for a minimalist, hacker-oriented alternative. Radicle if you want no central server at all.

“My repository is dominated by huge binary assets.” → Perforce P4, without much competition.

“I need exact, auditable control over who can push to which branch.” → Gitolite.

“I’m packaging software for Ubuntu or Debian.” → Launchpad, closer to unavoidable than optional here.

“I want Git hosting and CI/CD in one lightweight self-hosted package, without GitLab’s footprint.” → Harness Gitness or OneDev. Pick based on whether you’d rather run Go or Java.

“I need strong SSO, SAML, or other enterprise identity features out of the box.” → GitLab self-managed. Or Azure DevOps if you’re already on Microsoft identity.

“I want the simplest possible personal forge, just for me.” → Gogs for the smallest possible footprint. Gitea if you want more room to grow.

“I just want to interact with Git faster, not host it somewhere new.” → GitKraken.

Migration Difficulty at a Glance

Not every move is equally hard. A few of the most common paths, roughly ordered from easiest to most involved:

• GitHub or GitLab → Gitea or Forgejo: Usually straightforward. Both have mature import tools for repositories, issues, and pull requests. The workflow feels familiar right away.
• GitHub → Codeberg: Similarly easy at the code level, using Codeberg’s built-in migration tool. Budget extra time for its stricter FOSS-licensing terms.
• Any single-VCS host → RhodeCode: More involved to set up. But the payoff is clear if you’re consolidating scattered Git, SVN, and Mercurial repositories.
• GitHub → Radicle: Technically simple, since Radicle repositories are still just Git underneath. But it’s a genuine mental model shift. Expect to rethink identity, discovery, and availability, not just mirror your history over.
• Anything → Perforce P4: The most involved migration on this list, since it’s a fundamentally different version control model. It’s not just a different host for Git. Treat it as a deliberate architectural decision, not a weekend project.

Related Tools, Not Hosts

Not everything worth mentioning here actually hosts a repository. GitKraken doesn’t host anything. It’s a Git GUI and productivity suite that connects to whichever host you’re already using. It’s also increasingly a tool for supervising AI coding agents alongside your own commits. Maybe your problem is “the command line feels opaque,” not “I need a new host.” GitKraken solves that either way. It doesn’t matter which platform above you land on.

Conclusion

There’s no single winner in this list. There was never going to be one. GitHub earned its dominance by being a genuinely good, general-purpose default. For a large share of teams, it still is. That’s why this series exists as GitHub alternatives, not replacements for it as a category.

The real question isn’t “which platform is best.” It’s “which constraint actually matters to me.” That could be self-hosting, compliance, or cost. It could be vendor independence. Or a workload GitHub was never built for. Once that constraint is clear, twenty-eight options usually drop to two or three fast. At that point, the full reviews linked throughout this article are worth the time.