The Gitea Actions runner

Gitea ships a CI system that speaks the same workflow syntax as GitHub Actions. To actually run jobs you register a runner — and that's a dedicated VM here ( GIT-Runner , 10.100.100.11 ). 
 Why a separate VM rather than running builds in the cluster? Builds are bursty, disk-hungry, and occasionally want privileged operations. Keeping them on their own box means a heavy build can't disturb cluster workloads, and the build host can have Docker installed without that being a concern for the cluster nodes. 
 The runner is the act_runner agent (the project was renamed gitea-runner at v1.0), installed as a systemd service so it survives reboots and restarts on failure. It registers against the Gitea instance and then sits waiting for jobs. 
 GIT-Runner (10.100.100.11)
 - Docker engine (for building images)
 - gitea-runner (systemd service) -> registered to git.example.com
 - labels: ubuntu-24.04, ubuntu-26.04 (which job images it offers)
 
 
 Why we use this: a build runner is just a worker that polls for work. Running it as a plain systemd service on a dedicated VM is about as simple and debuggable as CI gets — when a build misbehaves you SSH to one box and read one service's logs.