This is a good fit primarily if you want to run a Radicle node that only seeds repos you tell it to. If you want to write code which you publish on Radicle, you need the tool that signs all your work with your private key (of your Radicle identity) - i.e. the `rad` CLI - and running that in a container isn't very useful. (e.g. think about how you'd replace `rad clone`). Having said that, here's a container image I maintain, in case it helps: https://quay.io/repository/radicle_garden/radicle-node

In a nutshell, I summarise it like this: I see Open Source Software is a public good. As a public good, it doesn't belong in any proprietary platform, nor should orgs of any kind be in a position to gate keep it. We should rather host it on a public, peer-to-peer network that everyone can have access to.

yes, we currently have just the base building blocks (`rad follow` - allowlist / `rad block` - blocklist) for the fancier things to be built on. When you "seed" a repository, by default you seed it only with "followed" scope, which means you would only see issues and "Patches" (our term for PR/MR) from the repo maintainers + other peers you follow (i.e. in your allowlist).

yup ! https://radicle.dev/2025/08/14/jujutsu-with-radicle

it's a little of both: on the one hand we're working on CI integrations (through generic webhooks or CI-engine-specific adapters that basically implement the CI engine's API [1]), so you can keep on using your existing CI solution. On the other hand, yes, there is also work towards a new CI engine (Ambient [2]), which aims to make it safe and secure to run CI on other people's code, which is important when working towards a distributed, community-ran, CI system. We should have more docs regarding the CI story up on radicle.dev in the next week or two.

[1] - https://radicle.network/nodes/index.radicle.garden/rad%3Az3G... , [2] - https://ambient.liw.fi/

1. yes, it's in the user guide [1] 2. Git LFS should work, yes. Care to try and report back ? ;) Open a new topic on the Zulip #Support channel [2] if you run into any issues.

[1] - https://radicle.dev/guides/user#4-embracing-the-onion [2] - https://radicle.zulipchat.com/#narrow/channel/369873-Support

yes, they're stored in git itself. See https://radicle.dev/guides/protocol#collaborative-objects

It should!

And yet, that's technically not CI.

The whole point we started using automation servers as an integration point was to avoid the "it works on my machine" drama. (Have watched at least 5 seasons of it - they were all painful!).

+1 on running the test harness locally though (where feasible) before triggering the CI server.

So, if I understand correctly, you’re not so much concerned about the p2p architecture, rather than the default seeding policy? (You’d prefer that to be selective rather than open by default? )