2026 年 Capacitor 应用的最佳 CI/CD 平台

Capacitor CI/CD 的备选方案正在减少。Microsoft App Center 的构建与分发服务已于 2025 年 3 月 31 日停止服务。Ionic Appflow 正在进行为期数年的逐步停运。GitHub Actions、GitLab CI、Bitrise 和 Codemagic 依然在运行，且在各自擅长的领域表现出色。

常见的错误是将此视为一场单纯的选拔赛，从中挑选 一个 平台，并将整个 pipeline 迁移到该平台。大多数 Capacitor 团队已经在使用 CI。他们缺乏的是通用 CI 在以下三个任务中表现不佳： 签名 Native Build, 实时更新，以及 将 App 安装到真机.

Capgo 专为这三个任务而构建，旨在配合 内部 你已信任的 CI 运行。保留 GitHub Actions 或 GitLab CI 来处理 lint、类型检查、单元测试和 Web build。当 pipeline 需要 iOS 或 Android 二进制文件、OTA bundle 或测试人员可安装的预览版时，请调用 Capgo。

2026 年的市场格局

即便它们已不再是 2026 年的首选方案，这两个名字仍频繁出现在搜索结果中。

• Microsoft App Center 已于 2025 年 3 月 31 日退役。Build 和 distribute 功能已停止。Analytics 和 Diagnostics 服务将延长至 2027 年 3 月 31 日。CodePush 不再由 Microsoft 托管。如果您仍在使用 App Center pipeline，请阅读 从 App Center 迁移到 Capgo.
• Ionic Appflow 替代方案 已于 2025 年 2 月 11 日停止新的商业销售。现有客户的访问权限将保留至 2027 年 12 月 31 日。目前仍可使用，但现在启动的所有项目都必须在 2028 年前完成迁移。请参阅 Ionic Appflow 的替代方案.

以下是团队实际在运行的平台：

• GitHub 操作 以及 GitLab CI: 通用型 CI。在 Linux 上表现出色。但在 Native Build 方面成本高且功能不完善。
• Bitrise 以及 Codemagic: 移动端 CI 专家。签名和商店提交功能强大。但不提供托管的 Capacitor Live Updates。
• Capgo: Capacitor 原生 Live Updates、云原生 Build 以及可安装的设备预览，可通过你现有的 CI 进行调用。
• Capawesome Cloud: 以替代 CI 为卖点的 Capacitor 原生 Live Updates 和 Native Build。你只需连接 Git，然后通过 GitHub Actions 调用。后端封闭，存在严重的供应商锁定，且价格策略多次变动。

2026 年真正值得思考的问题不是“哪个 CI 应该取代 GitHub Actions？”，而是“当 Capacitor App 需要二进制文件、OTA bundle 或手机安装时，GitHub Actions 应该调用什么？”

通用型 CI 依然做得不够好的地方

GitHub Actions 和 GitLab CI 是优秀的“厨房”。但它们并不是 Native Build 农场、OTA 网络或 QA 设备实验室。

原生 build

iOS 仍然需要 Xcode、证书、provisioning profiles 以及 Mac。Android 仍然需要 keystore 和 Play upload key。在 GitHub Actions 上使用托管 macOS 分钟数的成本远高于 Linux。即便在 GitHub 2026 年 1 月降价后，标准 macOS 分钟的价格仍约为标准 Linux 分钟的十倍（GitHub Actions 计费).

这就是为什么许多 Capacitor 团队已经拆分了 pipeline：使用 Linux 进行 PR 检查，而将签名二进制文件交给其他工具。Capgo Native Build 就是那个“其他工具”。任务将运行在 ubuntu-latest。由 Capgo 运行 Mac。

Live Updates

CI 可以编译 web bundle，但它无法通过 channels、rollback、加密和 device logs 将该 bundle 推送到已安装 App 的设备上。Live Updates 是一项产品，而不是一个 YAML 步骤。跳过 OTA 的 Capacitor 团队，必须为了那些本不需要新二进制文件的 JavaScript 修复，去等待 App Store 和 Play 的审核。

Capgo Capgo Live Updates 与 CI 并行。Pipeline 构建 web app，然后 upload bundle。只要 native shell 没有变化，用户无需经过应用商店的往返即可获得更新。

移动应用测试

在 Linux 上运行单元测试并不能证明应用在手机上的表现。TestFlight 处理、Play Store 内部测试轨道，以及“你能安装我刚发给你的这个 IPA 吗？”这类流程，才是审核中最慢的部分。Capgo PR 预览 将每个 pull request 放入一个 channel。测试人员只需在现有的 App 中切换 channel 即可。Native build 任务还可以生成一个 QR 安装链接 用于 APK 或 IPA。

这并不是设备农场。如果你需要模拟器矩阵或 Firebase Test Lab，请将这些任务保留在 CI 中。Capgo 填补了 CI 很少能解决的空白：让一个拿着手机的人，在不到一分钟内，就能看到正确的 build。

功能矩阵

有三点非常突出：Capgo、Capawesome Cloud 和 Appflow 都将 bundle 管理的 Live Update 与 Native Build 结合在了一起，而 Appflow 正在逐步淡出。只有 Capgo 的设计初衷是 保持 GitHub Actions 或 GitLab CI 的原有优势，而非取而代之。Capawesome Cloud 是另一个 Capacitor 原生选项，但它是一个后端封闭的替代型 CI。Bitrise 和 Codemagic 可以管理原生二进制文件，但你仍需自行组装 OTA 和设备预览。

各平台详细对比

Capgo

Capgo 是通用型 CI 所缺失的 Capacitor 发布层。

• Live Updates：加密 Web-bundle OTA、channels、回滚、增量更新以及设备 logs。
• 原生 build: 在云端进行 iOS 和 Android 二进制文件的签名，包括提交至应用商店。CI runner 可以保持在 Linux 环境。Capgo 已经支持 Xcode 26 以满足 App Store Connect 2026 年 4 月的要求。
• 真机测试: PR 预览频道，原生构建产物的 QR 链接，以及 Capgo 移动端 App 用于在真机上检查 bundle。

你无需将 lint 和单元测试从 GitHub Actions 中移走。只需在 Web build 成功后添加两个 CLI 调用：

- name: Live update
  run: npx @capgo/cli@latest bundle upload --channel production

- name: Native build
  run: npx @capgo/cli@latest build request com.example.app --platform ios --build-mode release

付费方案起步价为 12 美元/月（按年计费），包含 Live Update 以及 Native Build 时间（约 15 次 build/月，超出部分通过 credits 计费）。该入门价格自发布以来从未上调。详见 定价, 使用 Capgo Build 实现 CI/CD，以及 GitHub Actions 构建指南.

updater 插件是开源的 (MPL-2.0)，后端也是开源的 (AGPL-3.0)。你可以审计、fork 或 自行托管。付费的 Capgo Cloud 是可选的基础设施，而非陷阱。

Capawesome Cloud

Capawesome Cloud CI —— 即包含 Native Builds 和 Live Updates 的 Capawesome Platform —— 是另一种 Capacitor 原生方案，它将 OTA 与 iOS/Android 云端构建打包在一起。其产品理念与 Capgo 正好相反： 取代 GitHub Actions 和 GitLab，而不是接入它们。

他们的 Native Builds 发布公告写得很明确：不使用第三方 CI/CD。只需连接 GitHub、GitLab、Bitbucket 或 Azure DevOps。将 pipeline 放入 capawesome.config.json。在 Capawesome Cloud 内部运行。你可以通过 CLI 触发构建，但其预设的工作流是供应商托管的 CI。Git 集成、签名、构建时长、Live Updates 以及商店提交全部集成在一个封闭的后端中。插件和 CLI 是开源的，但后端不是。自行托管的效果也仅是部分实现：你可以托管 bundle，但元数据仍保留在 Capawesome Cloud 中。

这就是完全的供应商锁定。以后想要离开，意味着必须迁移更新器、构建配置、Git 连接以及发布元数据。Capgo 将这些组件保留在你的代码库和 CI 中，其开源的更新器和后端为你提供了随时退出的可能。

定价策略是另一个分歧点。Capgo 的付费方案自发布以来一直采用 $12/月 按年计费的方式。价格从未上涨过。而 Capawesome 的商业模式已经多次发生变化：

• Native Builds 发布时：从 $9/月 包含 1,000 次 Live Update 和 200 分钟构建时长。 $299/月.
• 2026 年 5 月平台重构：Live Updates 从按 MAU 计费改为按更新次数计费，随后 在客户投诉后又改回了 MAU 计费。 全套 Platform SKU（包含构建、Live Updates 和发布）起步价为 $19/月。Business 版为 $499/月.
• 当前公开定价仍将 Live Updates（起价 $9/月）与完整平台分开计费（起价 $19/月).

不断变动的低价标签并不等同于稳定不变的公平价格。如果你想要 Capacitor live updates 和 Native Build，又不想放弃现有 CI，Capgo 正合适。如果你已经全面采用 Capawesome 插件，并希望使用它们与 Git 集成的 CI，请阅读 Capgo 与 Capawesome Cloud 对比 以及 迁移指南.

来源： Capawesome Native Builds 发布公告, Capawesome Platform 发布公告, Capawesome 定价.

GitHub 操作

GitHub Actions 是大多数 Capacitor 仓库默认的 CI，在进行 PR 检查时也应保持如此。Linux 任务成本很低。工作流与 code 紧密结合。缓存、矩阵构建和强制状态检查都是成熟的解决方案。

它不是：移动端 DevOps 平台。你需要编写 YAML，配置 Fastlane 或 Capgo 进行签名。你需要自行托管 OTA，或者干脆没有 OTA。一旦 iOS 构建在每次 pull request 时运行，macOS 的时长费用将占据账单的大头。

行之有效的混合方案： GitHub Actions 用于 lint、测试等 npm run build。Capgo 用于 bundle upload原生构建和预览。 这种拆分比把整个移动端 pipeline 强行放到托管 Mac 上更便宜、更快。配置指南： GitHub Actions Live Updates 以及 自动构建与发布.

GitLab CI

与 GitHub Actions 结构相同。Linux CI 很强，Mac runner 可选，不支持托管的 Capacitor Live Updates，也没有可安装的 PR channel。如果代码库已经在 GitLab 上，就继续用。调用 Capgo，方式 .gitlab-ci.yml 相同。参见 GitLab 配置 以及 GitLab 上的 Android 自动化构建.

Bitrise

Bitrise 是一个移动端 CI 平台，拥有丰富的 step 库、托管签名和应用商店发布功能。你可以通过 npm 个步骤加上原生 iOS 和 Android 步骤来构建 Capacitor 应用。如果团队需要专门的移动端 runner 集群且不需要 OTA，这是一个不错的选择。

它缺失的是 Capacitor 式的发布闭环：即 Live Update、PR channel 以及一个无需迁移整个 pipeline 即可由现有 GitHub 工作流调用的 CLI。此外，其定价也处于移动端 CI 的高位。如果你已经在原生应用开发中标准化使用了 Bitrise，可以继续使用。但如果你仍需要 OTA 和设备预览，请添加 Capgo；不要认为 Bitrise 能取代这一层。

Codemagic

Codemagic 起家于 Flutter 构建，现在也支持 Ionic 和 Capacitor 的 YAML 工作流，并提供托管的 Android keystore、App Store Connect API 密钥，以及向 TestFlight 和 Play 发布的功能。签名管理是其优势。

它和 Bitrise 有同样的短板：缺乏托管的 Live Update。你仍然需要将 OTA bundle 上传到其他地方。如果你的 GitHub Actions 配置中唯一的缺口是“不想在 Mac 上维护 Fastlane”，那么 Codemagic 可以填补这个缺口。而 Capgo 则能填补更大的缺口 以及 通过一个 CLI 同时解决 OTA 和预览的缺口。本站提供的 Codemagic 教程： 使用 Codemagic 构建 iOS.

Ionic Appflow 替代方案

Appflow 是 Ionic 的一体化产品：原生构建、签名、Live Updates 和应用商店发布。它也是 CI 的替代方案，而不是 GitHub Actions 的插件。Ionic 于 2025 年 2 月 11 日宣布商业服务逐步终止。现有客户可继续使用至 2027 年 12 月 31 日。

如果你已经在用 Appflow，现在就规划退出，而不是等到 2027 年底。对等替换方案是用 Capgo 做 Live Updates 和 Native Build，同时继续使用（或重新使用）GitHub Actions 做 PR 自动化。迁移： 从 Appflow 迁移至 Capgo.

Microsoft App Center

2026 年已不是选项。构建和分发已于 2025 年 3 月 31 日结束。作为托管服务的 CodePush 也已下线。尚未完成迁移的团队仍在找它。Capacitor 的路线是：用 Capgo 做 OTA，加上 Capgo Build 或你自己的 CI 来出二进制包。先看： App Center 迁移 以及 CodePush 替代方案.

Xcode Cloud

对于已在 App Store Connect 中的纯 iOS 原生应用，Apple 的 CI 够用。但它不能构建 Android，不能发布 Capacitor Live Updates，也不能为 Web Bundle 的 QA 提供 PR 通道。把它当作 Apple 侧的补充，而不是 Capacitor 平台。

Capgo 如何接入你的 pipeline

2026 年的最佳配置如下：

1. 在每个 pull request 中，GitHub Actions 或 GitLab CI 会在 Linux 上安装依赖、运行测试并构建 Web 应用。
2. 如果仅涉及 Web 端变更，Capgo 会将 bundle 上传到 PR channel。审核人员只需打开现有 App，切换 channel 即可测试。无需等待 TestFlight。详见 将每个 pull request 转化为可安装的预览版.
3. 如果涉及 native code、插件或权限变更，同样的 workflow 会请求 Capgo Native Build，并分享一个 QR 安装链接。
4. 在 main 分支或版本 tag 上，Capgo 会根据实际变更内容，发布生产环境的 live update，或将签名二进制文件推送到 TestFlight 和 Play。

一个精简的 GitHub Actions 示例：

name: Capacitor CI
on:
  pull_request:
  push:
    branches: [main]
    tags: ['v*']

jobs:
  web:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: '24'
          cache: 'npm'
      - run: npm ci
      - run: npm test
      - run: npm run build
      - name: Upload live update
        if: github.event_name == 'push' && github.ref == 'refs/heads/main'
        run: npx @capgo/cli@latest bundle upload --channel production
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
      - name: Native build on tag-style releases
        if: startsWith(github.ref, 'refs/tags/v')
        run: npx @capgo/cli@latest build request com.example.app --platform ios --build-mode release
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}
          BUILD_CERTIFICATE_BASE64: ${{ secrets.BUILD_CERTIFICATE_BASE64 }}
          P12_PASSWORD: ${{ secrets.P12_PASSWORD }}
          CAPGO_IOS_PROVISIONING_MAP_BASE64: ${{ secrets.CAPGO_IOS_PROVISIONING_MAP_BASE64 }}
          APPLE_KEY_ID: ${{ secrets.APPLE_KEY_ID }}
          APPLE_ISSUER_ID: ${{ secrets.APPLE_ISSUER_ID }}
          APPLE_KEY_CONTENT: ${{ secrets.APPLE_KEY_CONTENT }}
          APP_STORE_CONNECT_TEAM_ID: ${{ secrets.APP_STORE_CONNECT_TEAM_ID }}

该示例仅限 iOS。Android 需要 ANDROID_KEYSTORE_FILE, KEYSTORE_KEY_ALIAS, KEYSTORE_KEY_PASSWORD, KEYSTORE_STORE_PASSWORD，以及 PLAY_CONFIG_JSON。请勿复制 iOS env 代码块，仅需修改 --platform。请参考 GitHub Actions 构建指南中的矩阵。Signing secrets 保存在 GitHub 中，并通过构建请求作为环境变量传递。Capgo 不需要成为你的 Git 唯一事实来源。完整示例请参阅 builder GitHub Actions 文档 以及 CI/CD 集成.

选择合适的配置

没有绝对的赢家。以下场景涵盖了大多数 Capacitor 团队的需求。

你已经在用 GitHub Actions 或 GitLab CI。 继续使用它们。添加 Capgo 来实现 Live Update、Native Build 和 PR 预览。这是 2026 年的默认方案。

你正在使用 Capawesome Cloud。 他们需要 Git 连接、YAML 替代方案和发布元数据。这在短期内很方便，但当你想要迁移时就会很麻烦。Capgo 能够保留你的 CI，完全开源，且没有那每月 12 美元的入门门槛。查看 Capgo 与 Capawesome Cloud 对比.

你仍在使用 Appflow。 你可以在 2027 年 12 月 31 日前完成迁移。拖延只会让迁移压力集中爆发。将 Live Update 和 Native Build 迁移到 Capgo，如果 Appflow 也是你的 CI，则将 PR 自动化移回 GitHub Actions。

你正在从 App Center 迁移。 构建 pipeline 已不存在，且 CodePush 并非托管产品。与其在 GitHub Actions 上从零开始重建 OTA，不如直接用 Capgo 替换这两部分。

macOS 的运行时长正在占据 GitHub 账单的大头。 不要将 lint 和单元测试移出 GitHub。将 Native Build 迁移到 Capgo，这样 iOS 就不再需要在 Actions 的托管 Mac 上运行。PR 状态检查保持原样即可。

你正准备在 2026 年启动一个 Capacitor 应用。 跳过 Appflow 和 App Center。从 GitHub Actions 开始构建 CI。第一天就接入 Capgo 来实现 OTA、云端构建和设备预览。如果后续有特定的 runner 或 step-library 需求，可以再添加 Bitrise 或 Codemagic。大多数团队并不需要额外的平台。除非你非常想要 Capawesome Cloud 的插件库并愿意为此更换 CI，否则请跳过它。

常见问题

最适合 Capacitor 应用的 CI/CD 平台是什么？

继续用你现有的 CI 做 lint、单元测试和 Web 构建。用 Capgo 补齐已签名的 iOS 和 Android 原生构建、Live Updates 以及可安装到设备上的测试。如果不需要 Live Updates，Bitrise 和 Codemagic 可以替代原生构建。Capawesome Cloud 覆盖 OTA 和原生构建，但作为替代 CI，它的后端是封闭的。Appflow 仍向现有客户提供至 2027 年 12 月 31 日，但已不是新项目的首选。

我应该用移动端 CI 平台替换 GitHub Actions 吗？

通常不用。GitHub Actions 和 GitLab CI 擅长在 Linux 上做 PR 检查。真正昂贵的是 macOS 原生构建、签名、Live Updates，以及把构建装到手机上。Capgo 设计为从现有 pipeline 调用，而不是取代它。

Bitrise 和 Codemagic 是否包含 Capacitor 的 Live Updates？

不包含。两者都擅长原生构建、签名和应用商店发布。但你仍需要一个独立的 Live Updates 产品，才能无需商店审核发布 JavaScript、CSS 和 HTML。Capgo 在同一个 workflow 中覆盖原生构建和 Live Updates。

Capgo 如何通过 CI 测试移动应用？

Capgo 能把 PR 变成专用 channel 上的可安装预览版，把原生构建产物作为 QR 安装链接分享，并让 QA 在设备上已安装的 App 中切换 channel。这比等 TestFlight 快。它不能替代用于模拟器矩阵的 device farm。

2026 年 Ionic Appflow 还是一个合理的选择吗？

除非你已经是其客户。Ionic 已于 2025 年 2 月 11 日停止新的商业销售，现有 Appflow 访问权限将持续至 2027 年 12 月 31 日。新的 Capacitor 项目应该保留现有的 CI 并添加 Capgo，而不是选择一个注定会停产的平台。

Capawesome Cloud CI 与 Capgo 相比如何？

Capawesome Cloud 是一个全栈式的 Capacitor CI：连接 git，使用 GitHub Actions，并在其云端运行 Native Build 和 Live Update。这就是供应商锁定。Capgo 是开源的（插件和后端），可以接入你现有的 CI，并自发布以来一直保持每月 12 美元的入门价格。Capawesome 已经多次调整价格，包括 Native Build 从发布时的每月 9 美元，到 2026 年 5 月的平台 SKU 起价为每月 19 美元，Business 版从 299 美元涨至 499 美元。

总结

2026 年的 Capacitor 备选名单比看起来要短：两个已退役或即将退役的全栈平台，两个没有 OTA 功能的移动端 CI 通用平台，一个可连接 git 并能替换你现有 pipeline 的 Capacitor CI，以及一个你已经在使用的通用 runner。交付最快的团队，绝不是那个在新的供应商上重建 CI 的团队。而是那些保留 GitHub Actions 或 GitLab CI，并针对 CI 处理不佳的任务添加 Capacitor 层面的团队。

这一层就是 Capgo： Native Build, 实时更新，以及 设备测试，由你已有的 pipeline 触发。开源。价格公道且从未涨价。并非封闭式的 CI 替代方案。

创建 Capgo 账号，然后按照 CI/CD 集成 或 GitHub Actions 中的 Capgo Build。如果你想先看产品展示，请从 Native Build, Capgo Live Updates，以及 PR 预览.