Post

Where Should Your Code Live?

Posted Updated
By Aditya Kumar
23 min read
Where Should Your Code Live?

A survey of code repository hosting in 2026

Most developers do not think about where their Git repository lives until something goes wrong. An account gets suspended. A DMCA notice takes down a project overnight. A platform changes its terms of service to train AI models on your code. Then it becomes urgent.

This post is specifically about code repository hosting — where your Git history, branches, and collaboration happen. I am not covering CI/CD, deployment, or compute hosting. Those are separate concerns with separate providers. The question here is narrow: where should your source code live, and what are the tradeoffs?

The Incumbents

GitHub

GitHub is the default. Most open-source projects live there. Most hiring managers look there. Most tooling integrates with it first. If you have no strong reason to be elsewhere, inertia keeps you on GitHub.

But there are reasons to think carefully about this default:

  • DMCA compliance. GitHub is a US-based entity and complies aggressively with DMCA takedown requests. The youtube-dl takedown in 20201 was the most visible example, but smaller projects get hit regularly. The process is automated and weighted toward the claimant. Your project can go offline before you have a chance to respond.
  • AI training. In April 2026, GitHub updated its policy to use interaction data from Copilot Free, Pro, and Pro+ users to train its AI models by default2. This includes code snippets and surrounding context from files you are actively editing. Enterprise users are exempt3. Individual developers are opted in unless they manually disable the setting. This is a meaningful policy distinction. A related class-action lawsuit (Doe v. GitHub) alleging that Copilot violates open-source licenses by reproducing code without attribution is currently before the Ninth Circuit4.
  • Account suspension. GitHub can suspend accounts for terms-of-service violations, and the appeals process is opaque. If your account is suspended, your repositories become inaccessible. For a solo developer, this can mean losing years of work history, issue discussions, and release artifacts in a single action.
  • Microsoft ownership. This is a matter of individual judgment. Some developers are comfortable with Microsoft stewardship5. Others are not. The concern is not about today’s policies but about the structural fact that a single corporation controls the platform where the majority of the world’s open-source code lives.

None of these are reasons to leave GitHub in a panic. They are reasons to understand what you are trading for the convenience.

It is also worth noting that any agreement you have with a hosting provider can develop loopholes over time. Emerging technologies create new categories of use that existing terms of service never anticipated. LLM training on hosted code is the current example, but it will not be the last. And there is a subtler problem with the opt-out model: there is always a gap between when a new policy takes effect and when you discover it and change your settings. During that window, the provider is operating under the new default. If the new default allows training on your code, your code has already been ingested by the time you toggle the setting. Opting out after the fact does not un-train a model. The damage — if you consider it damage — is done before you had a chance to make a choice.

GitHub publishes all DMCA takedown notices in a public repository6, which makes for instructive reading. The scale of enforcement is visible there: in March 2026, Anthropic filed a DMCA against a single repository and GitHub took down the entire fork network of 8,100 repositories in a single action7. Whether or not the takedown was justified, the mechanism itself — one filing, 8,100 repos offline — is worth understanding if your project depends on the platform.

GitLab.com

GitLab is the most feature-complete alternative to GitHub. It offers repository hosting, issue tracking, merge requests, and a comprehensive DevOps platform. The self-managed edition (GitLab CE/EE) can be installed on your own infrastructure, which gives you full control over the data.

On the code hosting side specifically:

  • GitLab has publicly stated that it does not train AI models on customer code at any tier8.
  • DMCA handling follows standard US legal compliance.
  • The interface is heavier than GitHub’s. For pure code hosting, it can feel like overkill.

Bitbucket

Owned by Atlassian. The natural choice if your team already uses Jira, Confluence, and the rest of the Atlassian stack. As a standalone code hosting platform, it has few distinguishing features over GitHub or GitLab. Atlassian ended support for Bitbucket Server in February 20249 and is sunsetting native Issues and Wikis in Bitbucket Cloud in favor of Jira and Confluence integration10.

The Alternatives

Codeberg

Codeberg11 is a non-profit code hosting platform based in Germany, run by the Codeberg e.V. association12. It is powered by Forgejo (see below) and is the closest thing to a “drop-in replacement” for GitHub in terms of user experience.

Why it matters:

  • Non-profit governance. There is no board of directors optimizing for revenue. The platform exists to serve its users. This changes the incentive structure around every policy decision.
  • GDPR jurisdiction. Hosted in Germany, subject to European data protection law. DMCA-style takedowns require rigorous legal proof before action is taken. The bar is higher than in the US.
  • No AI training. Your code is not scraped for model training.
  • Familiar interface. If you know GitHub, you know Codeberg. Pull requests, issues, wikis, releases — the workflow is nearly identical.

The tradeoff is scale. Codeberg runs on non-profit infrastructure. It can be slower than GitHub during peak traffic. The community is smaller, which means fewer eyeballs on your project if discoverability matters to you.

SourceHut

SourceHut13 (sr.ht) is the most opinionated platform on this list. Created by Drew DeVault, it is built around a philosophy of minimalism, privacy, and email-based workflows.

The distinguishing characteristics:

  • Email-native collaboration. There are no pull requests. Contributors send patches via git send-email to the project’s mailing list. Code review happens in email threads. This is how the Linux kernel14 and many other large projects have worked for decades. It is unfamiliar to developers raised on GitHub’s web UI, but it is well-tested at scale.
  • No JavaScript required. The web interface is fast, lightweight, and works in any browser. No tracking, no analytics, no ads.
  • Paid model. SourceHut charges a subscription (approximately $5–$15/month, with financial aid available). This means you are the customer, not the product. The business model is not advertising or data monetization.
  • CI/CD. SourceHut has a built-in build system (builds.sr.ht) that supports multiple Linux distributions and BSDs natively.

The traditional tradeoff was the learning curve. If your contributors are accustomed to clicking “Create Pull Request” on a web page, asking them to learn git format-patch and git send-email felt like a real barrier. In practice, LLM-based coding tools have largely eliminated this friction — any AI assistant can generate a properly formatted patch and compose the email for you. What was once an arcane workflow is now a prompt away, even for newcomers.

Forgejo and Gitea (Self-Hosted)

Forgejo15 and Gitea are lightweight, self-hosted Git forges written in Go. Forgejo is a community-driven fork of Gitea that split off in late 2022 to ensure non-profit governance after Gitea’s domain and trademark were transferred to a for-profit company without community consultation16.

Self-hosting gives you:

  • Total data sovereignty. No third party can suspend your account, take down your repository, or change the terms of service. Your code lives on hardware you control.
  • Policy control. You define the moderation policy, the access controls, and the data retention rules.
  • Low resource requirements. Both Forgejo and Gitea run comfortably on a Raspberry Pi or a $5/month VPS.

The tradeoff is operational responsibility. You are responsible for backups, updates, TLS certificates, uptime, and security patches. For a solo developer, this is manageable. For a team, it requires someone to be on-call for infrastructure.

If you want the Forgejo/Gitea experience without self-hosting, Codeberg is exactly that — a managed Forgejo instance run by a non-profit.

Radicle (Peer-to-Peer)

Radicle17 is a fundamentally different architecture. It is a peer-to-peer code collaboration network with no central server. Repositories are replicated across nodes in a P2P network, and identity is managed via public-key cryptography.

Why this matters:

  • No single point of takedown. There is no server to serve a DMCA notice to. Code propagates across the network. Removing it from one node does not remove it from others.
  • Local-first. Your repository lives on your machine first. Network replication is secondary. You can work offline indefinitely.
  • Sovereignty by design. Social artifacts like issues and code reviews are stored as Git objects, not in a proprietary database controlled by a platform.

The tradeoff is maturity. Radicle is functional but lacks the polish and feature breadth of established platforms. There is no integrated CI/CD, no complex project management, and the contributor onboarding experience is steeper than any server-based forge.

Radicle is best suited for projects that prioritize censorship resistance above all else, or for developers who want to decouple their collaboration workflow from any platform provider entirely.

Decentralized Storage: The Permanence Layer

The platforms above handle the workflow of code collaboration — commits, patches, code review. A separate class of emerging protocols addresses a different problem: ensuring that code, once published, cannot be removed by any single entity.

These are not Git forges. They are storage networks. You pay for availability, and in return you get data that no centralized actor can take down.

Walrus18 is a decentralized storage protocol built on the Sui blockchain. It distributes data across a global network of independent storage nodes using a 2D erasure-coding scheme (RedStuff), which means the data can be reconstructed even if a significant fraction of nodes go offline. You interact with Walrus via a CLI or HTTP API to store and retrieve blobs. Storage is paid in WAL tokens. It also supports hosting fully decentralized static websites (Walrus Sites), which could serve as a censorship-resistant landing page for a project’s documentation and release artifacts.

Arweave19 takes a different approach: permanent storage with a one-time fee. When you store data on Arweave, it is written to an append-only structure (the “blockweave”) and replicated across the network indefinitely. There is no recurring cost and no expiry. This makes Arweave well-suited for archiving snapshots of a repository — a periodic git bundle pushed to Arweave creates an immutable backup that survives regardless of what happens to your primary hosting.

IPFS and Filecoin20 provide content-addressed storage. IPFS gives every piece of data a unique hash; anyone who has the hash can retrieve the data from any node that hosts it. The limitation is that data only stays available as long as at least one node “pins” it. Filecoin adds an incentive layer: storage providers are paid to keep data online, creating a market for reliable long-term hosting. You can push a bare Git repository to IPFS and distribute the hash. The repository becomes globally addressable and difficult to censor, though the workflow is not interactive — you cannot git push to IPFS directly.

These protocols share a common tradeoff: you pay for availability (in tokens, fees, or operational complexity), and in return you get storage that no single entity — no corporation, no government, no DMCA filing — can remove. They are not replacements for a Git forge. They are a complementary layer for projects that need guarantees beyond what any server-based platform can offer.

ProtocolModelCostBest For
WalrusErasure-coded blob storage (Sui)WAL tokensLive data, decentralized sites, API-accessible storage
ArweavePermanent append-only storageOne-time feeImmutable archival snapshots, “permaweb”
IPFS + FilecoinContent-addressed + incentivized pinningFilecoin tokensGlobally addressable backups, large dataset distribution

Encrypted Pushes: Staying on GitHub Without Trusting It

There is a middle path for developers who want to keep GitHub’s network effects and tooling but do not want the platform to have access to their plaintext source: encrypt before you push.

Git supports this natively through clean/smudge filters21. A clean filter runs when content is staged for commit (working directory → repository). A smudge filter runs when content is checked out (repository → working directory). By configuring a clean filter that encrypts and a smudge filter that decrypts, your local working copy remains plaintext while the blobs stored on GitHub are ciphertext. From GitHub’s perspective, your repository contains opaque binary data.

The practical tool for this is git-crypt22. Setup looks roughly like this:

1
2
3
4
5
6
7
8
9
10
11
12

# Install git-crypt and initialize it in your repo
git-crypt init

# Specify which files to encrypt via .gitattributes
echo "*.cpp filter=git-crypt diff=git-crypt" >> .gitattributes
echo "*.h filter=git-crypt diff=git-crypt" >> .gitattributes

# Export the symmetric key (back this up securely)
git-crypt export-key /path/to/keyfile

# Collaborators unlock with the key
git-crypt unlock /path/to/keyfile

You can also do this with a custom script in .gitconfig if you prefer not to depend on git-crypt:

1
2
3
4

# .gitconfig
[filter "encrypt"]
    clean = openssl enc -aes-256-cbc -salt -pbkdf2 -pass file:$HOME/.git-encrypt-key
    smudge = openssl enc -aes-256-cbc -d -salt -pbkdf2 -pass file:$HOME/.git-encrypt-key

Either approach works. The tradeoffs are real:

  • No server-side diffs. Pull requests on GitHub will show binary gibberish. Code review must happen locally or through a separate channel.
  • No GitHub CI/CD. GitHub Actions cannot read your source, so any CI pipelines must run on infrastructure you control. This is outside the scope of this post, but it is the most significant practical limitation.
  • Key management. Every collaborator needs the decryption key. Losing the key means losing access to the repository history. This is a hard operational requirement.
  • Selective encryption. You do not have to encrypt everything. git-crypt lets you specify patterns in .gitattributes, so you can encrypt source files while leaving README.md, LICENSE, and build scripts in plaintext.

The result is a repository that appears on GitHub as a normal project — it has commits, branches, history — but the actual source code is unreadable to the platform, to Copilot, and to any model training pipeline. Your code lives on GitHub’s infrastructure, but GitHub cannot read it.

This is not a clean solution. It adds friction to collaboration, breaks web-based code review, and introduces key management overhead. But for developers or teams who need GitHub’s ecosystem while treating the platform as an untrusted storage layer, it works.

Licensing as a Deterrent

There is another lever available that does not require changing your hosting provider or encrypting your repositories: your choice of license.

Strong copyleft licenses like GPLv323 and AGPL-3.024 create legal uncertainty for anyone who wants to use your code in a proprietary product. The copyleft clause requires that derivative works be released under the same license. If an LLM trained on GPLv3 code is considered a derivative work, the model weights would theoretically need to be released under GPLv3 as well25. No major AI company wants that risk.

This is not a theoretical observation. Some AI coding tools have explicitly marketed the exclusion of GPL-licensed code from their training datasets to offer enterprise customers “license-clean” guarantees. The legal question of whether training constitutes creation of a derivative work remains unresolved — courts have not ruled definitively on GPL propagation to model weights4 — but the ambiguity itself acts as a deterrent. Risk-averse organizations avoid what they cannot confidently defend.

The practical effect: if you license your project under GPLv3 or AGPL-3.0, there is a reasonable chance that commercial LLM training pipelines will filter it out. Not because the law compels them to, but because their legal teams advise against the exposure.

The caveats are real:

  • Adoption. Strong copyleft licenses reduce adoption in commercial settings. Companies with blanket “no GPL” policies will not use your library, even for internal projects. If maximizing adoption matters to you, this is a direct tradeoff.
  • Enforceability. US courts have not yet ruled on whether LLM training on copyleft code triggers the derivative work clause. The “fair use” defense is the primary argument used by AI companies26. Until a court rules, the legal protection is speculative.
  • EU divergence. The EU’s DSM Directive requires AI providers to respect machine-readable opt-outs for text and data mining27. This creates a regulatory framework that is more favorable to rights holders than US law. If your users are primarily in the EU, licensing signals carry more legal weight.
  • Retroactivity. Changing your license today does not un-train models that have already ingested your code under a previous license. The protection is forward-looking.
  • Not “open source” if you add anti-AI clauses. Adding custom “no AI training” clauses to a standard open-source license conflicts with the Open Source Definition28, which prohibits discrimination against fields of endeavor. Your project may no longer qualify as open source under standard definitions. Stick with established licenses (GPLv3, AGPL) rather than inventing custom restrictions.

Licensing is not a silver bullet against AI training. It is a signal — one that risk-averse organizations tend to respect. For developers who want to keep their code publicly available but make it legally inconvenient to train on, a strong copyleft license is the lowest-friction option available.

Comparison

 GitHubGitLab.comCodebergSourceHutForgejo (self-hosted)Radicle
GovernanceMicrosoft (corp.)GitLab Inc. (corp.)Non-profit (Germany)Indie (paid)YouP2P network
JurisdictionUSUS (self-host anywhere)Germany (GDPR)USYoursNone
AI trainingYes (opt-out)NoNoNoN/AN/A
DMCA riskHigh (automated)MediumLow (legal review)LowNoneNone
WorkflowWeb-based PRsWeb-based MRsWeb-based PRsEmail patchesWeb-based PRsP2P/local
CostFree / paid tiersFree / paid tiersFree (donations)~$5–15/moServer costFree
Self-hostableNoYes (CE/EE)Via ForgejoYesYesYes (node)

Jurisdictional Risk

There is a dimension to code hosting that individual developers rarely think about but that matters at the institutional and national level: jurisdiction.

GitHub, GitLab.com, and Bitbucket are all US-based entities subject to US trade sanctions enforced by the Office of Foreign Assets Control (OFAC)29. In July 2019, GitHub restricted access to private repositories, paid features, and the GitHub Marketplace for developers in Iran, Syria, Crimea, Cuba, and North Korea30. Developers in those regions found themselves locked out of their own private repositories overnight. GitHub later secured a license from OFAC to restore full access for Iranian developers in January 202131, but the precedent was set: a policy decision in Washington can make your codebase inaccessible regardless of what your terms of service say.

This is not a hypothetical concern for governments, universities, defense contractors, and companies in non-US jurisdictions. If your country’s relationship with the US changes, your access to a US-hosted platform can change with it. The code is still there. You simply cannot reach it.

For entities that need to account for this risk, several providers operate outside US jurisdiction:

ProviderJurisdictionTypeNotes
CodebergGermany (EU)Non-profit SaaSGDPR-compliant, community-governed
FramagitFrance (EU)Non-profit SaaSOperated by Framasoft, focused on software freedom
GNU SavannahFrance (EU)Non-profit SaaSExclusively for GNU and free software projects
GiteeChinaCommercial SaaSDomestic Chinese alternative to GitHub, operated by Open Source China32
Forgejo / GitLab CEYour choiceSelf-hostedHost on infrastructure in any jurisdiction you control

The self-hosted option is the most defensible for sovereign entities, but it is not absolute. A Forgejo or GitLab CE instance running on domestic infrastructure — a European VPS from Hetzner or Exoscale, or a government-operated data center — places the code under the legal framework of the hosting country, not the platform provider’s country. No foreign platform can suspend your account or change the terms of service. However, self-hosting still has dependencies: your DNS registrar can suspend your domain, your cloud or VPS provider can terminate your account, and a country-level firewall can block your server’s IP entirely. True sovereignty requires owning each layer of the stack — hardware, network, DNS — which is feasible for a government data center but not for a solo developer on a rented VPS.

For individual developers, jurisdictional risk may feel abstract. For a university research group, a defense contractor, or a national open-source initiative, it is a concrete operational concern. The question is not whether your current access will be disrupted. The question is whether your hosting strategy survives a change in geopolitical conditions that you cannot predict.

A Practical Strategy

For most developers, the answer is not “leave GitHub” — it is “do not depend exclusively on GitHub.”

  1. Keep GitHub for discoverability. If you maintain open-source projects, GitHub is where potential contributors find you. The network effect is real.
  2. Mirror to a second home. Push to Codeberg, a self-hosted Forgejo instance, or even a bare Git repo on a VPS. This takes five minutes to set up (git remote add mirror ...) and protects against account suspension or policy changes.
  3. Own your critical repositories. For anything proprietary or sensitive, self-hosting with Forgejo is the most defensible choice. A $5/month VPS running Forgejo gives you a private Git forge with a web UI, access controls, and zero dependence on any platform provider.
  4. Evaluate your exposure to AI training. If you use GitHub Copilot, check your settings. If you do not want your code used for model training, opt out explicitly. If this is a non-negotiable concern, Codeberg or SourceHut are structurally aligned with your preference.

The underlying principle is straightforward: Git is a distributed version control system. Your hosting strategy should be distributed too.

References

Disclaimer: This post is for informational purposes only and does not constitute legal advice. Consult a qualified attorney for guidance on intellectual property, licensing, or jurisdictional matters. This article was generated using the Gemini 3.1 Pro and Claude Opus 4.8 models.

  1. Standing up for developers: youtube-dl is back. GitHub Blog, November 2020. GitHub reinstated the youtube-dl repository after the EFF filed a counter-notice to the RIAA’s DMCA takedown. (Link) ↩︎

  2. GitHub Copilot data usage policy update (April 2026): GitHub began using interaction data from Copilot Free/Pro/Pro+ users for AI model training by default. (Link) ↩︎

  3. GitHub Copilot Trust Center: Copilot Business and Enterprise customers are excluded from data training by default under existing contractual terms. (Link) ↩︎

  4. Doe v. GitHub, Inc. (Copilot class-action lawsuit): Filed November 2022, alleging GitHub Copilot violates open-source licenses by reproducing code without attribution. Oral arguments before the Ninth Circuit held February 2026. (Link) ↩︎ ↩︎2

  5. Microsoft completes acquisition of GitHub. Microsoft News, October 2018. (Link) ↩︎

  6. GitHub DMCA repository: Public archive of all DMCA takedown notices and counter-notices received by GitHub. (Link) ↩︎

  7. Anthropic DMCA takedown notice (March 2026): Anthropic filed a DMCA against a single repository; GitHub processed the takedown against the entire fork network of 8.1K repositories. (Link) ↩︎

  8. GitLab AI data policy: GitLab does not train AI models on customer code at any tier. (Link) ↩︎

  9. Atlassian Server end of support: Atlassian ended support for all Server products, including Bitbucket Server, on February 15, 2024. (Link) ↩︎

  10. Bitbucket Cloud: sunsetting Issues and Wikis. Atlassian is removing native Issues and Wikis from Bitbucket Cloud in favor of Jira and Confluence integration. (Link) ↩︎

  11. Codeberg: Non-profit code hosting powered by Forgejo. (Link) ↩︎

  12. Codeberg e.V.: Registered non-profit association (eingetragener Verein) in Berlin, Germany, founded in 2018. (Link) ↩︎

  13. SourceHut: Minimalist, privacy-focused code hosting with email-based workflows. (Link) ↩︎

  14. Submitting patches: the essential guide to getting your code into the kernel. Linux kernel documentation on the email-based patch workflow. (Link) ↩︎

  15. Forgejo: Community-driven, self-hosted Git forge (fork of Gitea). (Link) ↩︎

  16. Forgejo — beyond coding. We forge. Forgejo’s founding statement explaining the fork from Gitea after its domain and trademark were transferred to a for-profit entity. (Link) ↩︎

  17. Radicle: Peer-to-peer code collaboration network. (Link) ↩︎

  18. Walrus: Decentralized storage and data availability protocol built on Sui, using erasure coding for resilient blob storage. (Link) ↩︎

  19. Arweave: Permanent, decentralized data storage with a one-time fee. Data is written to an append-only “blockweave” and replicated indefinitely. (Link) ↩︎

  20. IPFS and Filecoin: Content-addressed storage (IPFS) with an incentivized pinning layer (Filecoin) for reliable long-term data availability. (IPFS, Filecoin) ↩︎

  21. Git attributes — clean/smudge filters. Git documentation on configuring filters that transform content on checkout (smudge) and staging (clean). (Link) ↩︎

  22. git-crypt: Transparent file encryption in Git using clean/smudge filters with GPG or symmetric key support. (Link) ↩︎

  23. GNU General Public License, version 3 (GPLv3). Free Software Foundation. The copyleft clause requires derivative works to be distributed under the same license. (Link) ↩︎

  24. GNU Affero General Public License, version 3 (AGPL-3.0). Free Software Foundation. Extends GPLv3 copyleft to network use: if you modify the software and let users interact with it over a network, you must release the source. (Link) ↩︎

  25. The Current State of the Theory that GPL Propagates to AI Models Trained on GPL Code. Shuji Sado, November 2025. A detailed analysis of the legal arguments for and against GPL copyleft propagation to LLM weights, with references to ongoing litigation. (Link) ↩︎

  26. Fair use and AI training. U.S. Copyright Office. The Copyright Office’s ongoing study on copyright and AI examines whether training AI models on copyrighted works constitutes fair use under 17 U.S.C. § 107. (Link) ↩︎

  27. EU Directive on Copyright in the Digital Single Market (DSM Directive). Article 4 provides a text and data mining exception but requires that rights holders’ machine-readable opt-outs be respected. (Link) ↩︎

  28. The Open Source Definition. Open Source Initiative. Clause 6 prohibits discrimination against fields of endeavor, which means licenses that restrict AI training may not qualify as “open source.” (Link) ↩︎

  29. GitHub and Trade Controls: GitHub’s official policy on US export control regulations and sanctions compliance. (Link) ↩︎

  30. GitHub blocked developers in Iran, Syria, and Crimea. TechMonitor, July 2019. GitHub restricted access to private repositories and paid features for developers in US-sanctioned countries. (Link) ↩︎

  31. GitHub is now free for teams and available in Iran. Developer Tech, January 2021. GitHub secured an OFAC license to restore full access for Iranian developers. (Link) ↩︎

  32. Gitee: Git-based code hosting platform operated by Open Source China (OSChina), serving as China’s primary domestic alternative to GitHub. (Link) ↩︎

Systems, Infrastructure
git code-hosting open-source infrastructure
This post is licensed under CC BY 4.0 by the author.