如果你用过 GitHub Actions大概率遇过这样的场面push 之后 job 一直卡在 queued不是代码有 bug而是官方托管的 runner 池在高峰期不够用。你想换成自托管 runner又不想养一台 24 小时开着的机器——补丁、磁盘、扩容、安全加固哪一样都比写代码麻烦。这两条路之间的空白正是今天聊的这个 Show HN 项目想填上的把 GitHub Actions 的 self-hosted runner 跑在 Modal Sandboxes 上。从实现逻辑上看它做的事情很直接每次有匹配条件的 job 进入队列就实时创建一个临时的 Modal Sandbox在里面启动一个 runner跑完 job销毁沙箱。runner 不再是一个需要长期维护的基础设施资产而是一个按事件出现的临时计算资源。这也是我看完这个项目之后最想表达的判断这个方案真正改变的不是“省钱”也不是“提速”而是把 runner 从“机器”变成了“API 调用”。1. Runner 选择的死结托管池不够用自托管又太难维护1.1 GitHub 托管 runner 的隐形天花板GitHub 托管 runner 最大的优点是“不用管”。机器、补丁、清理、扩容这些都是平台方的事用户只需要在 workflow 里写runs-on: ubuntu-latest剩下的交给平台。但当项目成长到一个阶段这套托管方案会陆续露出几道裂缝。第一道裂缝是硬件规格。托管 runner 默认的 CPU、内存档位有限绝大多数场景够用但一旦测试任务需要 GPU或者要编译一个吃内存的大单体项目默认档位就不够了。虽然也有更大规格的 runner 可选但价格会明显上升而且这类资源在高峰期同样要排队。第二道裂缝是峰值排队。托管 runner 是全组织共享资源热门时段里大家都在抢配额。我见过不止一次一个耗时两小时的集成测试把整个组织的并发额度占满后面几十个 PR 的 job 全部卡在 queued 状态。问题不在代码而在资源调度。第三道裂缝是自定义依赖。托管 runner 提供的是通用环境装一个特殊版本的 JDK 要自己下载写一个需要特定系统组件的测试只能干瞪眼想跑一个带 GPU 的模型验证更是无从下手。你越需要控制环境托管 runner 就越显得不够灵活。1.2 传统自托管 runner 的维护成本既然托管有天花板很多人第一反应是自托管。买几台机器注册成 runner所有问题都解决了表面看确实如此——环境自由、规格可控、不排队。但真正负责过的人都知道这只是把问题从 CI 侧转移到了运维侧。首先runner 机器需要常驻。哪怕一天只有两小时在跑任务机器也要 24 小时开机电费和机器成本从来没有离开过。其次系统需要持续维护安全补丁、依赖升级、磁盘清理、runner 版本更新。这些事不紧急但很磨人而且一旦忘记某天某个 job 就会以奇怪的方式失败。更麻烦的是规模和隔离。多台机器混跑不同项目的 job环境容易被前一个 job 污染机器出问题时要手动从 runner 池里摘除临时并发上来还要预先规划机器数量。自托管真正的代价不是买机器的钱而是把一个本应“运行时”的问题变成了“长期运维”的问题。1.3 两条路之间缺的是“用完即走”的 runner所以大家真正需要的其实是一个满足四个条件的 runner环境可以自由定制要什么镜像、什么依赖、什么 GPU 都能给没有闲置成本