自托管 runner，就是由你负责管理、接收并执行自动任务的机器。需要控制 macOS 构建环境时，可以考虑租 Mac mini，但拿到机器不等于买到了有人代管的构建服务。
要比较的是任务负载、维护责任和隔离方式。先跑通一个可以重复的构建，再把团队流程搬到长期运行的机器上。
先弄清自己要负责什么
Runner 程序接收任务，Mac 使用已安装的工具和权限执行它。GitHub 的 runner 文档说明了 GitHub Actions 对连接和程序运行的要求。
操作系统、依赖、磁盘空间和 runner 设置，仍然需要有人维护。先明确谁会发现任务失败、谁可以重启，以及机器换掉后怎么重建环境。
还要核对工作流兼容性：GitHub 文档说明 Docker container actions 和 service containers 需要 Linux。不能因为两台机器都能运行 runner，就把依赖 Linux 的流程原样搬到 macOS。
找到保留环境的实际理由
如果重复任务依赖固定环境或可复用的本地资源，常驻机器可能有帮助。但旧文件和隐藏状态也会不断积累。只有保留昨天的结果才能成功的构建，并不算可重复。
把实际任务日历与托管构建方案比较，考虑排队、维护时间，以及一台机器不可用造成的影响。独享 Mac 不等于支持无限并行任务，先测一个任务，再决定是否增加同时运行的数量。
决定什么代码可以运行
执行任务，就意味着允许代码在机器上运行。GitHub 提醒公开仓库的外部贡献可能触及自托管 runner。外部不可信代码，与需要发布权限的任务，应按不同信任等级处理。
使用正式签名材料或其他敏感资源前，先审查权限与隔离方案。不要默认把登录了个人账号、存有私人文件的日常工作机，拿来运行任意外部任务。本文提供选型清单，不是安全配置教程，也不承诺一个普通用户账号就能隔离全部风险。
验证任务和恢复流程
从干净的代码副本开始，试跑一个不含敏感资料的构建。记录工具版本，取回产物，检查日志。只清除自己理解的测试输出后再跑一次，确认成功不依赖没有记录的手动修改。
再做一次受控恢复检查：在任务之间停止 runner，恢复后确认能接收新任务。记下 Mac 被替换时如何重建环境，不要为了测试而中断正式生产任务。
恢复计划还应包含租赁 Mac 的备份与恢复验证，避免更换机器时仍依赖旧机器可以访问。
先选维护方式，再选机器
独享 Mac 设置指南介绍相关的交互式工作流，不代表平台代管 CI，也就是自动构建流程。常驻硬件符合需求时，再查看 Agent.Space 当前 Mac 方案，确认 runner 所需权限。
如果你更在意不用管理机器，可以考虑托管构建服务。真正要得到的是可靠的构建流程，而不只是一直租着一台 Mac。
