Decentralized communities can run their own infrastructure.
Self-hosted CI. Local-first deployment. Source replication that doesn’t depend on a forge. Settlement that proves it served you. Every piece ships its protocol, its evidence model, and a forkable playbook so any community can adopt it, audit it, or replace it.
// no premine · no roadmap · no issuer · no censorship
The thesis
Most “decentralized” projects re-introduce a central forge for source, a hosted CI provider for tests, a SaaS dashboard for deployment, and a custodial platform for any interaction with money. Each handoff is a capture surface. A community that depends on those handoffs does not, in practice, run its own infrastructure — it rents it.
The projects below pull each of those layers back into the community. Source replicates over Radicle. CI builds locally and publishes attestations on disk. Deployment binds approved bytes to a hash and verifies on install. Service settlement is gated by evidence and resolved off-chain. Every protocol is versioned, language-agnostic, and forkable.
The four projects
poor-mans-ci
Self-hosted CI for source-controlled communities. Runs tests and builds without GitHub Actions or any centralized provider, publishes signed attestations + artifact hashes, and treats the evidence as the contract.
poor-mans-cd
Local-first continuous delivery control plane. Deploys exact bytes by release manifest, refuses anything that doesn’t match its sha256, and writes audit-grade receipts to disk. A dashboard that rebuilds state from local files alone.
radicle-seed-kit
Always-on Radicle seed node automation. Keeps private repos replicated, helps NAT’d collaborators mirror without exposing keys, and provides the availability layer the rest of the suite assumes.
radicle-priorities
The canonical backlog protocol. Treats BDD .feature files as
the single source of truth and Radicle issues as the collaboration
surface, so the backlog replicates with the code.
(See extremebdd.com for the
methodology site.)
What comes next
Additional projects in the same family are queued. The first is ECSC — evidence-coupled service channels: a protocol for bilateral service settlement over ordinary Lightning channel updates, gated by a verifiable rule that no signed service state exists without valid service evidence. It will land here as its own project page when the protocol freezes.