我们先解决“构建跑在哪里”
本地开发机适合交互式工作，却不一定适合承接长时间、可重复的自动化任务。RunnerVM 将一台独享物理 Mac mini 作为可按周期租用的开发基础设施，让构建脚本、缓存目录、工具链和产物路径可以被团队持续管理。
服务的核心不是把桌面搬到浏览器，而是提供一台能够通过图形界面或命令行工作的云端 Mac。开发者可以根据项目需要运行 Xcode、xcodebuild、fastlane、测试工具与常用依赖管理流程。
开发者基础设施团队
让持续奔跑的构建任务，有一台清楚归属的云端 Mac
RunnerVM 为 iOS、macOS、CI/CD 与 AI 实验提供独享物理 Mac mini 节点。我们不把共享虚拟资源包装成独享设备，而是把机型、区域、价格、交付状态和问题处理路径逐项说明。
1
种在售配置
5
个节点或机房
365 天
节点正常运行
RUNNERVM
构建任务运行单
物理节点
代码提交
独享 Mac
构建产物
- 在售机型
- Runner M4
- 硬件
- M4 / 16GB / 256GB
- 设备属性
- 独享物理机，非虚拟机
- 可选区域
- 新加坡、日本（东京）、韩国（首尔）、香港、美国东部
配置可核对
订单可追踪
问题可复盘
RunnerVM 从一条反复执行的构建链路出发
移动应用构建不是一次性的远程操作。代码检出、依赖恢复、签名材料注入、归档、导出和日志留存会持续发生，团队需要的是可重复使用、归属明确的运行环境。
识别重复任务
把频繁发生的签名、归档、导出和日志收集从个人设备中拆出来。
固定运行环境
以独享物理节点保持工具链、缓存与构建目录的可管理性。
留下核验路径
让配置、订单、节点、工单和运行记录能够沿同一条链路追踪。
哪些任务适合交给 RunnerVM，哪些判断仍由团队负责
清楚说明边界，比把所有问题都归入“云服务能力”更重要。我们提供运行环境与节点管理，项目架构、签名策略、依赖版本和发布决策仍由使用团队掌握。
适合持续构建与远程开发
适用于 iOS 与 macOS 编译、CI/CD 执行器、React Native iOS 打包、Xcode 自动化归档、命令行任务、远程调试准备，以及对 Apple Silicon 环境有明确需求的 AI 实验。
- 需要独享计算环境和稳定目录结构
- 需要按天、周、月或季使用设备
- 需要在五个在售区域中选择接入位置
不把共享资源写成独享设备
RunnerVM 的在售服务是独享物理 Mac mini，交付对象为非虚拟机。页面不会用模糊的“高性能实例”替代真实机型，也不会出现目录之外的内存、存储或芯片组合。
- 不代替团队决定项目依赖与发布流程
- 不承诺未经项目验证的构建耗时
- 不以共享虚拟资源冒充独享物理节点
产品事实只有一套，展示语言可以不同
RunnerVM 的多语言页面、方案说明、下单配置和支持答复共同引用同一份产品事实。用户切换语言后，配置、价格、区域和支付范围不应发生变化。
配置如实
在售设备逐项写明芯片、内存、存储与物理属性。当前 Runner M4 对应 M4、16GB、256GB，不增加未在售机型，也不把附加存储写成基础配置。
价格一致
按天、周、月、季的价格在方案页、下单页和相关说明中保持一致。所有订单以美元结算，附加项单独列明，不用模糊的起步价隐藏完整周期成本。
节点可核验
目录明确列出五个在售区域。用户选择区域时，只展示当前机型支持的组合；网络排查则记录源节点、目标节点、时间与完整输出。
问题可追踪
技术问题以订单、节点、发生时间、复现步骤和脱敏日志为基础进入工单。处理状态、补充信息与结论沿同一工单更新，避免信息散落。
配置目录
1 个方案
区域目录
5 个节点
计费周期
天 / 周 / 月 / 季
支付范围
USDT-TRC20 或银行卡
银行卡支付仅指 Visa、Mastercard、Amex，经 Stripe 处理；实际可用网关以后端接口返回为准，所有订单统一以美元（USD）结算。
五个节点覆盖亚洲主要接入方向与美国东部
节点选择不只看地图距离。团队还应结合成员位置、代码与依赖来源、远程操作链路、产物上传方向和企业网络出口进行测试，再确定订单区域。
SG
新加坡
适合面向东南亚的开发团队，也可作为跨区域协作时的亚洲接入选择。下单前建议从实际办公网络进行延迟与路由测试。
JP
日本（东京）
适合日本本地及与东京网络路径较近的团队。对于频繁远程桌面操作的工作流，应同时观察 p50、p95 与晚高峰表现。
KR
韩国（首尔）
为韩国方向的开发与构建任务提供区域选择。涉及大体积依赖或产物时，需要把下载源和上传目标一并纳入测试。
HK
香港
适合需要亚洲跨境接入路径的团队。不同运营商的实际路由可能不同，因此区域名称不能替代项目网络的实测结果。
US-E
美国东部
适合团队成员、代码服务或交付链路主要位于美国东部方向的任务。跨洲远程操作应优先使用自动化执行并保留完整日志。
先测远程交互，再测构建链路
建议从实际网络分别检查 ping、traceroute、DNS 与目标端口，再运行一次接近真实项目的依赖获取和产物上传。公开延迟数据用于比较，不替代团队自身网络测试。
从交付前检查到订单结束，每一步都有明确责任点
独享设备并不意味着可以忽略访问控制。RunnerVM 负责节点交付、服务侧凭据流程和订单结束后的处理；用户负责首次安全设置、项目权限、构建材料和业务数据备份。
-
01
交付前核对设备
核对在售机型、内存、基础存储、网络连接与设备可访问状态，并将订单关联到用户选择的区域。交付信息以订单和控制台返回为准。
RunnerVM 负责：配置与节点一致性 -
02
首次连接后更新安全设置
用户领取连接凭据后，应核验主机指纹、更新首次密码、限制不必要的访问来源，并检查远程桌面与命令行连接是否符合团队策略。
用户负责：凭据保管与权限分配 -
03
租用期间控制项目数据
证书、描述文件、源码、缓存、日志和构建产物应按项目分目录管理。共享给团队成员时采用最小权限，并对关键产物保留独立备份。
共同目标：减少权限扩散与数据混放 -
04
订单结束后撤销访问
服务侧撤销与订单关联的连接凭据并进入设备处理流程。用户应提前导出需要保留的产物、移除项目密钥并确认自动化任务不再向节点发送数据。
结束条件：访问撤销、任务停止、数据完成处置
需要用户主动备份的内容
源码仓库之外的构建产物、导出文件、项目日志、自定义脚本、缓存中唯一存在的文件，以及团队后续仍需使用的配置记录。
提交支持信息前先脱敏
日志应保留时间、命令、错误码和上下文，但移除密码、令牌、私钥、证书口令及其他能够直接建立访问的内容。
状态记录回答发生了什么，复盘说明下一步怎么改
RunnerVM 的服务可用率目标为 99.9%。节点全年 365 天正常运行，不设置固定的服务中断时段；突发设备、外部网络或用户配置问题则按实际影响范围记录和处理。
服务可用率目标
99.9%
实际事件的认定、核验与处理范围以适用服务条款为准。
90 天前
每格 3 天
最近记录
状态条用于呈现近 90 天记录跨度。节点在下单时的实际可用性以控制台实时返回为准。
事件信息可定位
记录开始与结束时间、受影响节点、用户可见现象、确认方式和恢复结果，避免只发布没有边界的状态结论。
先恢复，再核对范围
优先恢复设备或连接能力，随后结合订单、节点、时间和日志核对影响范围，并通过工单更新处理状态。
改进项必须能执行
复盘摘要区分设备、网络、交付与流程问题，并明确检查项、负责人和验证方式，不使用无法核验的绝对承诺。
每日记录
节点连接与服务状态
事件记录
时间、范围、现象与恢复结果
复盘摘要
原因分类、改进项与验证路径
不同语言页面的配置和价格会不同吗？
不会。页面语言只改变表达方式，不改变在售机型、周期价格、附加选项、区域目录和支付范围。发现信息不一致时，可通过 support@runnervm.com 或控制台工单提交具体页面与截图。
RunnerVM 会替团队指定节点吗？
不会直接替项目做决定。我们公开新加坡、日本（东京）、韩国（首尔）、香港、美国东部五个节点的目录，并提供网络排查方法。团队应结合实际办公网络、依赖来源和交付目标测试后选择。
遇到构建或连接问题时，怎样更快进入排查？
先记录订单标识、节点区域、发生时间、复现步骤和完整错误输出，再检查支持指南。仍未解决时登录控制台提交工单；日志在提交前应移除凭据与敏感材料。
下一次构建
把可重复的构建任务交给一台独享云端 Mac
先核对 Runner M4 的配置、周期与五个可选区域，再进入下单流程。需要讨论项目需求时，可通过支持邮箱或控制台工单联系团队。