独享核心与 NVMe，构建更快

以任务槽位来规划：先确定一个典型任务需要多少线程，再据此划分服务器。粗略估算，按每个任务 8 线程计：

槽位数取下限时，会为宿主机、Runner 代理程序和缓存留出几个线程。编译密集型任务随线程数扩展；测试套件往往受限于单线程或 I/O，因此在购买更多核心之前，先分析流水线中最慢的阶段。善用富余内存：在 tmpfs 目录中构建，可以让许多编译任务的关键路径摆脱磁盘 I/O。

优先使用临时 Runner：每个任务启动一个全新的容器或 microVM，用完即弃，例如 Kubernetes 上的 actions-runner-controller，或 GitLab Runner 的 Docker executor。每个任务都获得干净的环境，而缓存则保存在任务沙箱之外。

在独享的 Runner 上，最大的收益通常来自同样的东西绝不下载两次、绝不构建两次：

• 容器镜像：在内网部署 pull-through 模式的镜像仓库缓存（Distribution 或 Harbor），并把 BuildKit 缓存放在本地 NVMe 上。
• 依赖：npm、PyPI、Maven 和 Go 模块的下载统一经由本地缓存代理。
• 编译器：C、C++ 和 Rust 使用 ccache 或 sccache，Monorepo 则在 NVMe 上部署 Bazel 远程缓存。
• Git：在 Runner 上保留镜像克隆（mirror）或引用克隆（reference clone），并使用浅克隆或部分克隆。

在 Pro 64 上，用一个小容量的 RAID 1 镜像分区安装操作系统，四块 NVMe Gen5 硬盘的其余空间组成 RAID 0 条带存放缓存数据，缓存随时可以重建。所有端口均不限流量，预热缓存、推送制品和同步镜像仓库都不产生额外费用。同一机房内的 Runner 之间可通过免费私有 VLAN 共享缓存。

自托管 Runner 会执行流水线交给它的任何代码，因此要把它当作暴露在外的基础设施来对待：

• 常驻 Runner 上不跑不受信任的代码：GitHub 官方文档建议仅在私有仓库中使用自托管 Runner，因为来自 Fork 的 Pull Request 可以在机器上执行任意代码。公开项目请使用临时 Runner，或者让 Fork 构建继续在 CI 平台托管的 Runner 上运行。
• 区分信任级别：持有生产环境凭据的部署任务，应使用专用 Runner，至少也要放在独立的 Runner 组中。
• 短期凭据：使用 OIDC 联合身份或限定范围的令牌，而不是在主机上存放长期有效的密钥。
• 加固主机：仅允许 SSH 密钥登录、默认拒绝的防火墙策略、自动安全更新；基础步骤请参阅我们的服务器安全加固指南。

让 Runner 主机保持可复现。借助 REST API 和 Terraform Provider，可以定期用干净的镜像重装 Runner；如果一次错误的变更把你锁在外面，还可以通过 KVM 控制台重新进入。