Julian FoadForge Self-Hosting
This proposal facilitates self-hosting software forges.
It is packaging work, which in itself is mundane, but it benefits in three directions at the same time. First, it directly helps a person or small group to reclaim self-agency by hosting their own forge. Second, it contributes to the further development of self-hosting systems, by furthering the usefulness of two existing self-hosting systems, encouraging the communities behind them. Third, it facilitates work towards forge federation, by making it easier for both developers and early adopters to deploy multiple forge instances, including both established (Forgejo) and new experimental forges (Vervis+Anvil).
We are talking about web service deployment packaging (like Docker, Yunohost) rather than OS-level packaging (like Deb, RPM).
Why spend effort on this kind of packaging?
Developers of a piece of software know how to run it locally for development and testing.
Developers integrating multiple components need a way to deploy them all, easily, repeatably, and with the ability to switch between variants of each (such as development and production versions).
Hosting frameworks make this job a whole lot easier.
Why target multiple packaging formats together?
Spread. There is a need to develop hosting systems further, across the FOSS scale, from those supporting the grass-roots FOSS developers, up to those deployed by service providers.
Efficiency. Being familiar with a particular hosting framework makes it easier to package more apps for it. Being familiar with a particular app makes it easier to package it for more hosting frameworks. Tackling the basic hosting needs in a consistent and efficient way then allows to devote effort beyond the basics, to capabilities like backup/restore, DNS/well-known configuration, single-sign-on, integration with a landing page.
Target Components, Hosting, Capabilities
Hosting frameworks targeted:
- Yunohost (based on Debian) -- popular grass-roots self-hosting system-in-a-box
- MASH (based on Ansible+Docker) -- sibling of professional quality Matrix-docker-ansible-deploy
- SHB? (based on Nix)
- K8s?
- more: Fediversity? (~Nix/K8s?), CoopCloud (~container/swarm)...
ForgeFed components targeted, main:
- Forgejo (already in YNH, MASH)
- Vervis
- Anvil
Additional components useful in a real forge deployment:
- Forgejo Runner (already in MASH)
- Woodpecker CI (server + agent) (already in MASH)
- Weblate (already in YNH)
Implementation Status
| . | YNH | MASH | SHB | K8S |
|---|---|---|---|---|
| Vervis | no | no | no | ? |
| Anvil | no | no | no | ? |
| Forgejo | yes S,A,B,D,L,M | yes C... | yes S,A,B... | ? |
| Forgejo-Runner | no | yes C... | yes S,A,B... | yes |
| Woodpecker-CI | yes B,D,L,M | yes C... | no | ? |
| Weblate | yes B,D,L,M | no | no | ? |
Integration features:
- S. Single sign-on (SSO)
- A. Accounts managed externally (LDAP)
- B. Backup/restore
- C. Containerised
- D. DNS/well-known configuration
- L. Launcher/landing page integration
- M. Multiple installs (on different domains/paths)
About The Components
Vervis
Anvil
Forgejo
Forgejo Runner
Forgejo Actions provides CI services, running CI jobs on (remote) agents such as Forgejo Runner or alternatives.
Rationale for inclusion: commonly used with Forgejo.
Woodpecker CI
Woodpecker CI consists of server and runner (agent), and performs CI services for a forge. It is an alternative to using Forgejo Actions.
Rationale for inclusion: Codeberg offers an integrated Woodpecker CI service.
Woodpecker's Forgejo integration documentation
How Libre? Apache-2/CC-BY-SA, Github, Mastodon, Matrix, Xtwitter
Weblate
Weblate provides translation and localisation services. As copy-left libre software it complements a libre forge.
Rationale for inclusion: Codeberg offers an integrated Weblate service.
How Libre? GPL, Github, Mastodon, Xtw/FB/LI...
#Forgejo #forgeFed #forgeFederation #selfHosted #NGI