部署到 App Hosting 的其他方式

大多数情况下，我们建议您使用 自动发布或 手动触发发布 （通过 Firebase 控制台）。不过，您可能需要使用更自定义的部署流程。App Hosting 提供了多种自定义部署选项。

从源代码部署

通过从源代码部署，您可以将应用的源代码和 配置直接推送到 App Hosting，而无需建立持久的 GitHub 连接。

从源代码部署时，App Hosting 会将您的源代码上传到 Google Cloud Storage 存储分区，在 Cloud Build 中运行框架的 build 命令，并将编译后的工件部署到 Cloud Run 和 Cloud CDN。本地源代码部署和 GitHub 部署使用相同的 构建流程。如果您的项目中存在 .gitignore 文件，则该文件中列出的文件和文件夹将从部署中排除。

您可以使用 Firebase CLI 或 Firebase 控制台 从本地源代码进行部署。

所需的 IAM 权限和基础架构设置

由于 Firebase CLI 和 Firebase 控制台都使用相同的 后端基础架构来存储和构建源代码归档，因此 这两种部署方法都适用相同的 IAM 权限要求。

具体要求取决于您是否是首次部署到特定位置（区域）。如需详细了解权限，请参阅 Firebase IAM 概览和特定 Firebase App Hosting 权限。

初始配置的权限（首次部署到某个位置）

首次在项目位置启动本地源代码部署时，Hosting 必须预配 GCS 存储分区来存储您的归档，并授予 Hosting 服务代理访问权限。由于这些是项目级管理任务，因此需要 Project Owner 或 IAM 管理员权限 。具有基本 Editor 或 Viewer 角色的用户无法执行此初始设置，并且会被阻止。

前提设置权限包括：

  • 启用 Storage API：serviceusage.services.enable
  • 创建源代码存储分区：storage.buckets.create 和 storage.buckets.list
  • 配置服务代理：resourcemanager.projects.setIamPolicy，以授予 Hosting读取权限 (roles/storage.objectViewer)，以便在构建期间提取 上传的代码。

对于初始部署，系统会使用 30 天的生命周期创建 GCS 存储分区，之后该存储分区会被删除。不过，您可以在 Cloud 控制台中管理此时间范围，具体路径为 Cloud Storage -> 存储分区 -> 生命周期 -> 规则 。请参阅 管理对象 生命周期。

后续部署的权限（位置初始化后）

为某个位置初始化源代码存储分区和角色绑定后 （通过初始 CLI 部署或控制台设置），常规开发者、 Editor 或 App Hosting 管理员 可以部署更新。日常部署不需要项目级管理权限。

有效部署权限包括：

  • 验证存储分区: storage.buckets.list
  • 上传源代码归档：storage.objects.create
  • 触发构建和发布：标准 Hosting 权限 (apphosting.builds.create 和 apphosting.rollouts.create)

使用 Firebase CLI 从源代码进行部署

Firebase CLI v14.4.0 及更高版本 可让您将应用源代码和配置直接从本地 机器推送到 Firebase。如果您已管理其他 Firebase 部署（例如安全规则或函数），并且想要使用单个 CLI 命令同时部署 Web 应用和后端服务，则此方法非常方便。

前提条件

  • 您的项目必须采用 Blaze 方案 。
  • 您必须运行 firebase-tools 14.4.0 版 或更高版本。

部署步骤

  1. 在本地项目目录中运行 firebase init apphosting。
  2. 出现提示时，选择使用现有项目 ，然后选择目标 Firebase 项目。
  3. 选择要部署到的新后端或现有后端；此步骤会为本地目录设置 Hosting 部署，并提示您提供配置详细信息：
    • 要部署到的后端的 ID
    • 要部署到的区域（如果创建新后端）
    • 应用代码根目录的路径
    • 您首选的 Node.js 运行时 。选择版本化运行时可启用 自动基础映像更新 (ABIU) ，以自动将安全补丁应用于底层环境。
  4. App Hosting 会将您的部署偏好设置保存在 firebase.json 中， 并在本地项目中创建该文件（如果尚不存在）。初始化成功完成后，运行 firebase deploy 以部署源代码。

firebase.json 示例

{
  "apphosting": [
    {
      "backendId": "my-backend",
      // rootDir specifies the directory containing the app to deploy, but the entire
      // parent directory of firebase.json will be zipped and uploaded to ensure that
      // dependencies outside of the app directory will be available at build time.
      "rootDir": "./my-app",
      "ignore": [
        "node_modules",
        ".git",
        "firebase-debug.log",
        "firebase-debug.*.log",
        "functions"
      ]
    }
  ]
}

使用 Firebase 控制台进行部署（上传 ZIP 文件）

The Firebase 控制台 提供了一个图形界面，您可以通过直接上传压缩的源代码归档来部署 应用。如果您不想使用 GitHub 或偏好其他 CI/CD 设置，则可以使用此方法来替代 GitHub 连接流程。

您可以在初始后端创建 期间或在现有后端上 创建手动发布 时执行归档上传，包括 最初使用 Firebase CLI 部署的后端。

支持的格式

控制台上传工具原生验证并接受两种压缩归档格式：

  • .zip
  • .tgz

这些格式会明确显示在文件上传工具的说明文本中。

部署步骤

方案 A：在初始后端配置期间
  1. 选择来源：在后端创建向导中，在“您想如何导入应用？”步骤中选择上传 ZIP 文件 。
  2. 配置准备：点击“下一步”会触发后台 准备流程，该流程会依次启用 Storage API、确保设置 正确的角色并 upsert 存储分区。界面会显示加载 微调框以及动态状态消息： “正在启用 API…”、“正在检查 权限…”和“正在准备存储分区…”。
    • 错误处理和防护措施：如果任何准备步骤失败（例如非所有者因 IAM 权限不足而收到 403 PERMISSION_DENIED），界面会显示专用警告，指示您与 Project Owner 联系。步进器导航会严格锁定，“下一步”按钮和最终的“完成并部署”按钮会保持停用状态，直到问题得到解决。
  3. 上传文件：准备工作成功完成后，选择归档文件或将其拖到文件上传工具组件中。

  4. 配置设置：指定应用根目录（默认为 /）。

  5. 点击完成并部署：对于 ZIP 文件上传，系统会停用独立的“完成”按钮，因为上传归档是一次性操作，必须 立即进行部署，以确保后端正常运行。

方案 B：创建手动发布
  1. 打开对话框：在 Hosting 信息中心内，点击创建发布。
  2. 选择来源：在对话框的步进器中选择上传 ZIP 文件。如果后端没有现有的 GitHub 连接，“GitHub”选项会被停用。
  3. 准备和上传：选择会触发相同的后台 准备流程（“正在启用 API…”、“正在检查权限…”，和 “正在准备存储分区…”）。成功后，使用上传工具拖动或选择归档文件 ，指定应用根目录，然后点击部署 以触发构建和发布。

使用 Terraform 进行部署

如果您需要更好地控制构建流程和部署环境，可以使用 Terraform 进行部署。借助 Terraform，您可以使用声明式配置文件定义和管理您的 App Hosting资源，并且能够将自己的预构建容器映像直接部署到 App Hosting，而无需依赖App Hosting从源代码 进行构建。

如果您是 Terraform 新手，请参阅 Terraform 和 Firebase 使用入门。 如果您已熟悉 Terraform，可以开始使用示例配置文件和其他 App Hosting资源。

设置 GitHub 连接以实现 CI/CD

您可以随时在 部署 标签页中连接 GitHub 代码库。Firebase这样，您就可以从本地环境部署应用原型，然后在准备就绪后过渡到自动 CI/CD 流水线。

使用 AI 工具进行部署

我们将于 2027 年 3 月 22 日终止对 Firebase Studio 的支持。 虽然您的 App Hosting 后端不受影响，但发布按钮在 Firebase Studio将被停用。如需继续发布更新而不更改网址，请迁移您的项目。 了解如何迁移。