kunchenguid/runner-up
运维与部署在自有机器上自托管 GitHub Actions runner,每个任务使用全新的容器、虚拟机或账户。
项目介绍
runner-up 把 GitHub Actions 任务放到你自己的 Linux、macOS 和 Windows 机器上运行。协调器通过 runner scale sets 与 GitHub 通信,把等待中的任务分配到空闲机器,再通过 SSH 在全新的 Docker 容器、KVM 虚拟机、tart macOS 克隆、Apple container 客户机、Hyper-V 虚拟机或 Windows 账户里启动单任务 runner。host 类型的位置则直接在机器上运行任务。每台机器划分为若干 place,place 服务于工作流通过 runs-on 请求的 pool。
适合有闲置硬件或 Mac、希望降低云端 CI 开销并让任务之间相互隔离的团队。它不同于重复注册的普通自托管 runner,也不同于需要 Kubernetes 集群的自动扩缩方案,runner-up 只要求能通过 SSH 访问各台机器。
快速使用
先在协调器机器(Linux 或 macOS)上安装 runner-up 并核对前置条件,包括以仓库管理员身份登录的 gh,以及到各工作机的免密 SSH。
# 服务一个仓库,并定义一个 Linux pool 标签。
runner-up init --repo you/app --pool my-linux
# 添加一台 Docker 工作机(Linux 上默认)。
runner-up machine add box --ssh ci@box
# 检查生成的配置并启动协调器。
runner-up check-config
runner-up serve
然后在工作流中请求该 pool:
jobs:
build:
runs-on: my-linux
默认情况下新加入的机器会服务配置中的所有 pool。如果希望 Mac 只跑 macOS 任务,需要在配置文件中新增 pool,并把 Mac 的各个 place 指向它,然后再次运行 runner-up check-config。完整的配置文件格式、服务安装、Windows 设置和更新流程见 README。
使用约束
协调器只能运行在 Linux 或 macOS,需要 gh 对所服务的每个仓库有管理员权限(服务组织还需 admin:org),到每台工作机有密钥 SSH,并且各机器安装了对应提供方的工具:Docker、KVM 相关软件和云镜像、Apple silicon 上的 tart,或仍属实验性的 Apple container 和 Hyper-V。Windows 工作机需要管理员完成一次设置。
runner scale sets 仍处于 GitHub 预览阶段,上游变更可能让 runner-up 暂时失效,直到它跟进。Docker place 共享宿主机内核,KVM place 能访问宿主机回环地址上的服务;对不太信任的代码应使用 KVM,并保护回环服务。host place 在任务之间不重新创建。来自 fork 的拉取请求默认被拒绝,只有完全信任所有 fork PR 时才应启用。Hyper-V、Apple container、Windows 账户以及运行中修改配置这些路径被标注为实验性或只经过部分验证。资源用量读数是采样观测值,不是硬上限。项目采用 MIT 许可证。
HotRepo 点评
runner-up 在 2026-11-04 的 Go 新项目榜上有记录,采集窗口内新增 18 颗星;项目页面显示约 133 颗星、6 个 fork,尚未进入全语言日榜。它的定位具体,README 也写明了隔离方式、故障处理和取舍,但这个年轻项目在状态说明中列出多个提供方尚未经过真实日常工作验证,依赖这些实验路径前应重点核查。
本文由 AI 根据项目 README 生成,更新于 ,以项目官方文档为准。