Multi-input, multi-output backup service for Forgejo and derivatives
- Rust 98%
- Nix 2%
Each one is gated by a `tokio::sync::Semaphore`. Each repo acquires an OwnedPermit before spawning; the permit is held for the task's lifetime, and automatically released on drop. Signed-off-by: NotAShelf <raf@notashelf.dev> Change-Id: Icb359f7e82b0bbbeac232f0b79cf13186a6a6964 |
||
|---|---|---|
| nix | ||
| src | ||
| .envrc | ||
| .gitignore | ||
| .rustfmt.toml | ||
| .taplo.toml | ||
| Cargo.lock | ||
| Cargo.toml | ||
| flake.lock | ||
| flake.nix | ||
| README.md | ||
Konservejo
Declarative, pipeline-based backup orchestrator for Forgejo with a focus on backpressure tolerance, cryptographic verification, and fan-out concurrency.
Name Origin
The name is derived from similar Esperanto morphology the same way the original name does:
konservi= to preserve-ejo= place
morphing into "preservation place" or "archive."
Why?
Currently my work outside of Github is scattered on various Forgejo instances. I do not wish to consolidate those into one, as I use those various instances with different goals and intents but I do want a safeguard that encapsulates all. Thus, I've come up with a decision to create a proper solution that scratches my itch. Here's how it is meant to look like:
[Forgejo A] ──┐
[Forgejo B] ──┼──> [Source Adapters] --> [Artifact Stream] --> [Dispatcher] --> [Sink A] --> [Verifier]
[Forgejo C] ──┘ │
├──> [Sink B] --> [Verifier]
└──> [Sink C] --> [Verifier]