GitLab 官方当前列出的 Hosted macOS Runner 镜像只有 macos-15-xcode-16 与 macos-26-xcode-26，且 macOS Hosted Runner 仍标记为 Beta；与此同时，Apple 已发布 Xcode 27 Beta。基于这两个公开状态，截至 2026 年 9 月 5 日，你不能把 GitLab Hosted macOS Runner 作为 Xcode 27 生产迁移的唯一环境。(GitLab Hosted macOS Runner 官方文档)
本周建议动作：保留 Hosted Runner 承担现有稳定工具链和非敏感验证，同时建立一台 Apple Silicon 自托管 Mac，专门验证 Xcode 27、私网依赖和生产签名。不要等待一个尚未公布日期的 Xcode 27 托管镜像上线，再开始做兼容性测试。
最后更新于 2026 年 9 月 5 日，版本状态核实自 GitLab Hosted macOS Runner 文档、GitLab Compute Minutes 文档与 Apple Xcode 27 Release Notes；镜像、Beta/GA 状态或 Xcode 27 发布阶段变化后，应重新复核。
SECTION 01 谁应该用这份 GitLab Hosted macOS Runner 选型判断？
如果你正在制定 Xcode 27 适配计划，需要确认托管镜像是否已经覆盖目标工具链，这篇文章适合你。
如果你负责代码签名、内部制品库、固定出口地址或网络隔离，本文会帮助你判断哪些任务不能放入公共托管池。技术总监和采购负责人则可以用最后的条件分支，把计算用量、维护投入与中断风险放进同一个 TCO 模型。
SECTION 02 版本支持：GitLab Hosted macOS Runner 什么时候能用 Xcode 27？
直接答案是：截至 2026 年 9 月 5 日，GitLab 官方没有列出 Xcode 27 Hosted macOS 镜像，也没有公布可供企业承诺的上线日期。
GitLab 文档将 Hosted runners on macOS 标记为 Beta，并公开列出以下镜像：
macos-15-xcode-16：GA。macos-26-xcode-26：GA，也是未指定镜像时使用的默认镜像。- Xcode 27：当前未出现在官方支持镜像列表中。
GitLab 的镜像生命周期也不能简单理解为“Apple 发布新版本，托管环境马上可用”。官方说明是，新版本镜像通常先进入 Beta，完成验证后才可能成为 GA；同时最多支持 2 个 GA 镜像，旧镜像在新 GA 镜像发布后进入弃用流程，并在 3 个月后删除。(GitLab macOS 镜像与生命周期文档)
Apple 这一侧的版本状态同样需要单独看。Xcode 27 Beta 要求 macOS Tahoe 26.4 或更高版本，并且只能安装、运行在 Apple Silicon Mac 上。也就是说，即使 GitLab 后续公布了 Xcode 27 镜像，你仍然要确认 macOS 版本、Simulator Runtime、依赖工具以及构建脚本是否同时满足要求。(Apple Xcode 27 Release Notes)
这里有四个状态不能混为一谈：
- Hosted Runner 服务状态：当前仍是 Beta。
- macOS 镜像状态：当前公开的 Xcode 26 镜像为 GA。
- Xcode 版本状态：Xcode 27 仍属于 Apple 的 Beta 系列。
- 自托管 Runner 应用状态：可以安装在你管理的 Apple Silicon Mac 上，不依赖 GitLab 是否已经发布对应 Hosted 镜像。
因此，“什么时候支持”目前只能回答为：等待官方镜像列表发生变化，并在企业测试通过后再切换；不能依据论坛猜测或媒体报道承诺日期。
SECTION 03 环境控制：托管和自托管 Mac 的工具链边界
GitLab Hosted macOS Runner 的优势是交付快。每个任务都会获得新配置的虚拟机，任务结束后环境被删除，适合减少跨项目残留和临时环境污染。官方还说明，Hosted Runner 的虚拟机提供无密码 sudo，这对安装依赖方便，但也意味着作业脚本拥有较高的临时管理权限。(GitLab Hosted Runner 官方说明)
它的限制也很明确：
- 不能带入自定义 macOS 镜像。
- 只能从 GitLab 提供的镜像中选择。
- 镜像内没有目标软件时，需要在任务中自行下载安装，增加执行时间。
- Homebrew、Simulator Runtime、Ruby、CocoaPods 等组件的更新时间不完全由你决定。
- macOS Hosted Runner 为无头模式，依赖 UI 交互的部分测试不一定适用。
- Apple Silicon 的性能核与能效核调度不可由你控制，任务间的性能可能存在波动。
自托管 Mac 则相反。你可以固定 Xcode 27 Beta 的具体构建版本，预装指定 Simulator Runtime，把依赖工具写入版本清单，并决定系统更新窗口。GitLab 官方支持在 Apple Silicon 或 Intel Mac 上安装 Runner；不过 macOS Runner 以用户模式的 LaunchAgent 运行，而不是系统级 LaunchDaemon，它依赖登录用户的会话和 Keychain，这会直接影响无人值守、自动登录和重启恢复设计。(GitLab Runner macOS 安装文档)
所以，自托管 Mac 不等于天然可重复。你仍然需要把以下内容纳入仓库或配置管理：
- Xcode 版本与构建号。
- macOS 版本与系统补丁窗口。
- Simulator Runtime 列表。
- Ruby、Bundler、CocoaPods、Swift Package 依赖。
- Homebrew 包清单与安装版本。
xcodebuild参数、签名模式和导出选项。- 节点维护者、变更审批人和回滚方法。
验证环境是否真的可重复，不能只看“同一台机器今天能否打包”。建议使用同一个提交运行至少两次，比较构建产物哈希、依赖解析结果、测试报告和归档日志；再在 Hosted Runner 与自托管 Mac 上各跑一组真实任务，确认差异来自环境而不是脚本偶然性。
SECTION 04 签名安全：正式发布任务的节点边界
技术上，Hosted macOS Runner 可以执行 macOS、iOS、watchOS 和 tvOS 的构建、测试与部署任务；但这不等于它自动满足企业的正式签名政策。GitLab 文档明确提示，集成 Apple 服务、安装到设备或部署到 App Store 前，应用必须完成代码签名；同时 Hosted Runner 中 gitlab 用户的 Keychain 不公开可用，你需要自行创建 Keychain。(GitLab macOS Hosted Runner 使用说明)
正式发布任务至少要审查以下边界：
- 签名证书和私钥如何注入，是否会出现在日志、缓存或临时文件中。
- Provisioning Profile 是否按项目和环境隔离。
- 发布账号是否使用最小权限，而不是共享管理员账号。
- 构建结束后是否删除临时 Keychain、证书、Profile 和导出目录。
- 失败重试时，凭证是否可能被重复使用。
- 审计系统能否记录谁触发了发布、使用了哪个节点和哪个签名资产。
对于普通编译、单元测试、静态检查和不含生产凭证的归档验证，Hosted Runner 的临时环境通常更容易隔离。对于正式签名，建议使用经过安全审查的专用自托管 Mac，并将其限制为发布项目或发布阶段可见。
如果你已有签名节点设计，可以参考本站的企业 iOS 签名节点安全设计思路；如果需要把远程 Mac 纳入团队资产，也应先阅读 VPSNIX 的隐私与服务边界说明，再让安全团队确认数据、凭证和运维责任的归属。
SECTION 05 私网接入：必须回退到自托管 Mac 的任务类型
Hosted Runner 的网络隔离适合“构建节点主动访问公开依赖”的任务。GitLab 官方说明，Hosted Runner 虚拟机只允许向公网发起出站通信，不允许公网入站，也不允许虚拟机之间互相通信；这能降低临时节点被外部访问的风险，却不能自动打通你的企业内网。(GitLab Hosted Runner 网络限制)
你需要特别检查以下依赖：
- 仅允许固定出口 IP 访问的私有制品库。
- 通过 VPN、专线或内网 DNS 才能访问的服务。
- 需要企业代理才能下载的 Swift Package、Ruby Gem 或二进制工具。
- 仅允许白名单设备访问的测试 API。
- 对数据驻留、源代码位置或跨境传输有要求的项目。
- 构建过程中必须访问内部证书服务、密钥服务或发布审批系统的任务。
“Hosted Runner 能拉到 GitLab 代码”只证明 GitLab 代码路径可用，并不代表它可以访问完整的企业依赖，更不能据此判断已经满足合规要求。
建议你让网络、安全和研发效能团队共同输出四份证据：
- 网络流向图：列出代码、依赖、测试服务、制品和发布端点。
- 端点清单：记录域名、端口、认证方式、出口要求和失败处理。
- 失败日志：分别记录 DNS、TLS、代理、白名单和权限失败。
- 安全签字记录：明确哪些任务可进入 Hosted 池，哪些任务只能进入自托管池。
需要固定私网出口、内部依赖或数据边界的任务，通常应直接选择自托管 Mac。自托管 Runner 的定位不是“性能更快”，而是让节点处在你能够审计、隔离和控制的网络边界内。
SECTION 06 容量与队列：Xcode 27 上线前的独立 Runner 建设
如果 Xcode 27 只是少量试验任务，你不一定要立即建设完整节点池；但你应该尽快建立至少一台独立的 Apple Silicon 自托管 Mac，用于验证版本、签名、网络和恢复能力。它可以先承担试点，不必一开始就承担所有生产流水线。
Hosted macOS Runner 的容量受托管资源可用性影响。GitLab 文档提示，底层 macOS 裸机资源有限，资源不足时可能出现较长排队；个别实例还可能无响应，使任务一直挂起直到达到最大执行时长。(GitLab Hosted macOS Runner 资源说明)
自托管 Mac 也不能只按芯片规格估算容量。你需要分别记录：
- 排队时间：任务进入队列到 Runner 接手的时间。
- 执行时间：Runner 开始工作到任务结束的时间。
- 有效产能：扣除维护、重启、缓存失效和故障后的可用时间。
- 峰值并发：真实 PR、测试、归档和发布任务同时到达时的压力。
- 恢复时间：节点重启、Runner 断连、Xcode 异常后的恢复耗时。
- 空闲容量：在不影响目标 SLO 的前提下还能吸收多少突发任务。
不要用一次干净构建推算节点数量。测试组合至少应包含真实 PR、单元测试、Simulator 测试、归档和失败重试，并分别记录缓存命中与未命中结果。
GitLab 提供的 Runner Fleet Dashboard 也将“任务等待 Runner 的平均时间”作为容量判断指标之一；你可以把该指标与企业内部的构建完成目标结合，而不是只比较单次构建耗时。(GitLab Runner Fleet Dashboard 文档)
SECTION 07 TCO 计算：自托管 Mac 的成本模型
Hosted Runner 的账单不能只按流水线墙钟时间估算。GitLab 官方计算规则是：
Compute Minutes = Job duration / 60 × Cost factor
目前文档列出的 macOS Hosted Runner 成本系数为：macOS M1 medium = 6，macOS M2 Pro large = 12，两者状态均为 Beta。具体可用额度、套餐和额外计算分钟仍应以你的企业账单为准。(GitLab Compute Minutes 计算规则)
你可以用下面的变量模型核算，而不是填入未经验证的单价：
Hosted Runner 月成本：
H = Σ（每类任务运行秒数 ÷ 60 × 对应 Cost factor）× 企业计算分钟单价 + 超额费用 + 缓存与制品费用
自托管 Mac 月成本：
S = 设备或租赁成本 + Runner 运维人力 + Xcode 与依赖维护成本 + 网络与安全治理成本 + 备机成本 + 故障中断损失
其中最容易被漏掉的是：
- 签名节点的专用隔离成本。
- 系统更新前的回归验证时间。
- Xcode 多版本并存带来的磁盘与维护成本。
- 节点故障时人工介入和发布延期成本。
- 私网接入、固定出口与安全审计投入。
- 缓存策略不一致导致的额外构建时间。
决策条件列表：
- 若任务使用稳定的 Xcode 版本、没有私网依赖、没有生产签名凭证，且负载按周波动，选 Hosted Runner。
- 若任务必须使用 Xcode 27、指定 Simulator Runtime 或固定依赖版本，选 Apple Silicon 自托管 Mac。
- 若任务需要 Keychain、生产证书、发布账号或内部审批系统，回退到通过审计的专用自托管节点。
- 若任务峰值明显高于稳定基线，使用 Hosted Runner 吸收非敏感峰值，自托管节点维持稳定生产基线。
- 若企业要求所有构建都经过固定出口或数据不能离开私网，优先自托管，不要先假设 Hosted Runner 能通过网络审查。
- 若无法同时满足版本和安全要求，优先保证生产签名边界，再为 Xcode 27 单独建立试点节点。
这也是多数企业更适合采用混合节点池的原因：托管环境负责弹性和标准化任务，自托管 Mac 负责版本缺口、私网依赖和签名安全，而不是强行让一种节点承担全部工作。
如果你需要比较不同周期的 Mac 资源投入，可以先查看 VPSNIX 的方案与计费页面，再把实际构建次数、排队记录、维护工时和备份节点需求代入上面的公式。租赁成本必须以真实节点、周期和账单核算，不能用宣传页上的单一价格替代企业 TCO。
SECTION 08 最终节点池选择与 PoC 路径
结论可以压缩成三条：
- 稳定工具链、普通编译和波动任务：优先 GitLab Hosted macOS Runner。
- Xcode 27 试点、私网依赖和正式签名：优先独立 Apple Silicon 自托管 Mac。
- 大多数企业生产环境：采用 Hosted Runner 与自托管 Mac 的混合部署。
你不需要等 GitLab 公布 Xcode 27 镜像日期才开始行动。先把 Xcode 27、签名和私网任务按敏感度分流，再建立一台独立远程 Mac 做 GitLab Runner PoC，记录真实构建、排队、缓存和重启恢复结果；只有当这些数据证明节点池能够达到目标 SLO，才继续扩展规模。
相比临时依赖个人开发机，VPSNIX 的远程 Mac 更适合作为这种试点节点：你可以按实际周期申请资源，不必先采购整批物理设备，也能把 Runner、Xcode 版本和签名职责放在独立主机上。不过，如果你的负载是长期稳定的高并发重负载，或者必须接入本地 USB 设备、专用硬件和现场网络，长期自购 Mac 可能更合适；远程租赁主要解决的是临时算力、版本验证、团队共享和快速扩容问题。
在这种前提下，先用一台独立 Mac 验证 Xcode 27，再决定是否形成正式节点池，通常比把生产流水线一次性迁入尚未提供 Xcode 27 镜像的 Hosted Runner 更稳妥。若你要开始 PoC，可以从 VPSNIX 的 Mac 远程服务入口确认可用方案，再将真实 GitLab CI/CD 任务接入测试。