@f4grx @OmegaPolice @srtcd424 @be i've been hosting forgejo runners on independent instances and also on codeberg and actually think this is a underrated opening, not a liability.
the first time i deployed a github-pages-like thing and could get walltime latency from the time i pushed to the time a page was deployed below a single second because i had full control of the environment & therefore could do what is treated as dev-only incremental builds without needing to spin up a fresh runner from the ether i was floored. the difference between even ~5 seconds and <1 second is a huge deal when thinking about it at a workflow level.
even when we have had expensive builds, it's clear how cheap the thing microsoft is offering per person. like each runner is effectively a raspi 5, so if you have any more competent hardware than that then self hosting a runner is a win when the platform doesn't try to limit that as a control vector. It's actually a really great shift to think of the git remote as just being a collaboration and relay platform where you put the CI runner in play as a point of optimization.
hijacking the github actions syntax into a runner is a really smart move so migration is straightforward, the biggest change has been putting more meaning into the "runs-on" param. forgejo runners are now just docker-in-docker images and are easy to run. there are some ux problem still - like i had to patch a config issue on codeberg that made external runners unusable last year, which signals that they are not widely adopted, but the potential is real.
