cloudparts

Radicle

A peer-to-peer code forge built on Git: every user runs a node that stores and shares repositories, and issues, patches and reviews travel inside the repository as signed Git objects, with no central server.

What it is
Version control
Used for
Issue tracking
Type
Open source
Made by
Radicle (maintainer-led, funded by Radworks grants)
License
MIT and Apache 2.0
Facts checked
20 October 2026
Website Source code

What it is

In Radicle every participant runs a node, identified by an Ed25519 public key, its Node ID. rad init turns an ordinary Git repository into a Radicle one with a Repository ID such as rad:z3gqc…, derived from the hash of its first identity document: a small JSON file, kept at refs/rad/id, that lists the project’s name, default branch, its delegates (the people or bots who maintain it) and how many of them must agree. Nodes gossip three kinds of signed messages, about which nodes exist, which repositories each one holds and when references change, and move the data itself with Git’s own fetch protocol. A repository stays available as long as at least one node that seeds it is online, and anyone can run an always-on seed node.

No server decides what is true. Each peer’s branches live in a namespace named after its Node ID, all sharing one Git object store, and every node signs its references whenever they change. The canonical default branch is whatever enough delegates have pushed: with a threshold of two of three, a commit becomes canonical once two delegates have it. Issues and patches are collaborative objects, Git commit graphs inside the repository that peers merge by union and replay in a fixed order, so they work offline and sync like code. git push rad HEAD:refs/patches opens a patch.

The Heartwood stack is written in Rust, licensed under MIT and Apache 2.0, and funded by grants from Radworks; it does not use a blockchain or token. Radicle 1.0 shipped in September 2024, the latest release is 1.10.3 (September 8, 2026), and in April 2026 the project moved to radicle.dev and radicle.network. On September 23, 2026 it disclosed that traffic between nodes has never been encrypted or properly authenticated, so private repositories can leak to anyone on the network path; the fix, moving to the iroh networking stack, will be a breaking change.

Why teams pick it

  • No single host to trust or lose: any node can serve a repository, and signed references let anyone check updates without a central authority
  • Issues, patches and code review are stored in the repository, so they work offline and move with every clone
  • Plain Git underneath: you push to a rad remote, and tools that sit on Git, such as Jujutsu, keep working
  • Free software with no paid tier, platform account or cryptocurrency involved

Watch out for

  • A repository is only reachable while some node seeding it is online, and the network is small: about 40 seed nodes at the 1.0 launch
  • Private repositories are unsafe over the network until the breaking protocol upgrade: as of October 2026 the project tells users to block them or stop their node
  • CI isn’t part of the core; in 2025 the team itself pushed branches to GitHub by hand to run tests with GitHub Actions
  • The planned move to iroh will split the network into upgraded and non-upgraded nodes that can’t talk to each other

Alternatives

What all version control have in common →Compare side by side →
GitHubCommercialThe largest Git host: repositories, pull requests, code review, issues and packages in one web service, owned by Microsoft since 2018 and used by more than 180 million developers.GitLabCommercialA Git forge sold as one application for the whole software lifecycle, from issues and merge requests to built-in CI/CD, packages and security scanning, that you can use on GitLab.com or run yourself.BitbucketCommercialAtlassian’s Git host, built to sit next to Jira: pull requests, code review and Bitbucket Pipelines CI, as the Bitbucket Cloud service or the self-managed Bitbucket Data Center.GiteaOpen sourceA lightweight, self-hosted Git forge in one Go program: repositories, pull requests, issues, a package registry and GitHub Actions-style CI, under the MIT license.ForgejoOpen sourceA self-hosted Git forge, like a small GitHub you run yourself: repositories, pull requests, issues, a package registry and built-in CI in one Go program, developed by a community under the non-profit Codeberg e.V. as a hard fork of Gitea.CodebergCommercialA public, non-profit Git forge for free and open-source projects, run on Forgejo by Codeberg e.V., a member-owned association in Berlin: repositories, issues, pull requests, CI, static pages and translations without a company behind them.

How it fits with other technologies

Publish a repository and open a patch · bash

rad auth                           # create your key pair (your Node ID) and alias
rad init                           # publish the current Git repository; it gets a rad: ID
rad node start                     # run your node in the background

git switch -c fix-login
git commit -am "Extend login session timeout"
git push rad HEAD:refs/patches     # open a patch; pushing again adds a revision
rad patch                          # list patches

rad clone rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5   # clone Radicle itself by its Repository ID
rad issue open                     # issues live in the repository too

See it in a real stack

No architecture uses Radicle yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2018–2026

Radicle began with Monadic, a Berlin company that Eleftherios Diakomichalis and Alexis Sellier (cloudhead) founded in January 2018 to build a “sovereign” developer stack: one that doesn’t depend on a large platform. The first Radicle, released as an alpha in February 2019, was built on IPFS.

Work on a second protocol, Radicle Link, began in October 2019. It drew on Secure Scuttlebutt and used Git itself for replication, dropping IPFS, and the Radicle Upstream desktop app shipped on it in December 2020. A Swiss non-profit, the Radicle Foundation, was set up in June 2020 to oversee the project, and from 2021 development was funded by Radworks.

In July 2022 the team started over again with Heartwood, the third-generation protocol, and discontinued Upstream. From January 2023 Radicle was developed on Radicle. After 17 release candidates, 1.0 shipped on September 10, 2024 with issues, patches, code review, private repositories and Tor support. In 2025 some ISPs blocked radicle.xyz, which the team blamed on content shown by its public repository explorer, so in April 2026 it split its site (radicle.dev) from the explorer (radicle.network).

Why it’s built this way

Peer-to-peer instead of central or federated servers
The goal is a forge with no single entity controlling the network or users’ data. In the 1.0 announcement the team wrote that sovereign code forges are “possible today, and in our opinion, necessary”, so free software doesn’t depend on large tech platforms.
Git for storage and transport
IPFS was dropped after the first version. Since Radicle Link, repositories are ordinary bare Git repositories and peers fetch with Git’s own protocol, so existing Git tools keep working and each object is stored once.
Issues and patches as Git objects
Storing collaborative objects as commit graphs in the repository means the social side of a project is replicated, verified and available offline exactly like the code, with no database to host.
Trust from signatures, not from a host
Every node signs its references and a repository’s delegates decide its canonical branch, so anyone holding the Repository ID can verify an update without asking a trusted third party.

Timeline

  1. 2018

    Monadic founded in Berlin (January)

  2. 2019

    First Radicle alpha, on IPFS (February); work on Radicle Link begins (October)

  3. 2020

    Radicle Foundation set up (June); Upstream desktop app ships on Radicle Link (December)

  4. 2022

    Work starts on Heartwood, the third protocol (July)

  5. 2024

    Radicle 1.0.0 (September 10)

  6. 2026

    Move to radicle.dev (April 23); 1.10.0 (August 5); network protocol vulnerability disclosed (September 23)

Sources11 · facts checked 20 October 2026

Improve this page on GitHub