App Hosting にデプロイする他の方法

ほとんどの場合、自動ロールアウトまたは Firebase コンソールから手動でトリガーされたロールアウトを使用することをおすすめします。ただし、よりカスタマイズされたデプロイ フローを使用することもできます。App Hosting には、カスタム デプロイ用のオプションが複数あります。

ソースからのデプロイ

ソースからデプロイすると、永続的な GitHub 接続を必要とせずに、アプリケーションのソースコードと構成を App Hosting に直接 push できます。

ソースからデプロイする場合、App Hosting はソースコードを Google Cloud Storage バケットにアップロードし、Cloud Build でフレームワークのビルドコマンドを実行して、コンパイルされたアーティファクトを Cloud Run と Cloud CDN にデプロイします。ローカルソースのデプロイには、GitHub のデプロイと同じビルドプロセスが使用されます。プロジェクトに .gitignore ファイルが存在する場合、そのファイルにリストされているファイルとフォルダはデプロイから除外されます。

ローカルソースからデプロイするには、Firebase CLI または Firebase コンソールを使用します。

必要な IAM 権限とインフラストラクチャの設定

Firebase CLI と Firebase コンソールの両方で、同じバックエンド インフラストラクチャを使用してソース アーカイブを保存してビルドするため、両方のデプロイ方法に同じ IAM 権限要件が適用されます。

正確な要件は、特定のロケーション（リージョン）に初めてデプロイするかどうかによって異なります。権限の詳細については、Firebase IAM の概要と特定の Firebase App Hosting の権限をご覧ください。

初期オンボーディング（ロケーションへの最初のデプロイ）の権限

プロジェクトのロケーションでローカルソースのデプロイが初めて開始されると、App Hosting はアーカイブを保存する GCS バケットをプロビジョニングし、App Hosting サービス エージェントにアクセス権を付与する必要があります。これらはプロジェクト レベルの管理タスクであるため、プロジェクト オーナーまたは IAM 管理者の権限が必要です。基本の編集者ロールまたは閲覧者ロールを持つユーザーは、この初期設定を実行できず、ブロックされます。

前提条件となる設定権限は次のとおりです。

  • Storage API を有効にする: serviceusage.services.enable
  • ソースバケットを作成する: storage.buckets.create と storage.buckets.list
  • サービス エージェントを構成する: resourcemanager.projects.setIamPolicy。App Hosting に読み取りアクセス権（roles/storage.objectViewer）を付与して、ビルド中にアップロードされたコードを取得できるようにします。

初期デプロイでは、GCS バケットは 30 日間のライフサイクルで作成され、その後バケットは削除されます。ただし、この期間は Cloud コンソールの [Cloud Storage] -> [バケット] -> [ライフサイクル] -> [ルール] で管理できます。オブジェクト ライフサイクルを管理するをご覧ください。

後続のデプロイの権限（ロケーションの初期化後）

ロケーションのソースバケットとロール バインディングが初期化されると（最初の CLI デプロイまたはコンソールの設定）、通常のデベロッパー、編集者、App Hosting 管理者が更新をデプロイできます。ルーティン デプロイにプロジェクト レベルの管理権限は必要ありません。

アクティブなデプロイの権限には、次のものがあります。

  • バケットを確認する: storage.buckets.list
  • ソース アーカイブをアップロードする: storage.objects.create
  • ビルドとロールアウトをトリガーする: 標準の App Hosting 権限（apphosting.builds.create と apphosting.rollouts.create）

Firebase CLI を使用してソースからデプロイする

Firebase CLI v14.4.0 以降では、アプリのソースコードと構成をローカルマシンから Firebase に直接 push できます。これは、他の Firebase デプロイ（セキュリティ ルールや関数など）をすでに管理していて、ウェブアプリとバックエンド サービスを 1 つの CLI コマンドでデプロイする場合に便利です。

前提条件

  • プロジェクトが Blaze プランに登録されている必要があります。
  • firebase-tools バージョン 14.4.0 以降を実行している必要があります。

デプロイ手順

  1. ローカル プロジェクト ディレクトリで firebase init apphosting を実行します。
  2. プロンプトが表示されたら、[Use an existing project] を選択し、ターゲットの Firebase プロジェクトを選択します。
  3. デプロイ先のバックエンドを新規または既存から選択します。このステップでは、ローカル ディレクトリの App 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 アップロード）

Firebase コンソールには、圧縮されたソース アーカイブを直接アップロードしてアプリケーションをデプロイするためのグラフィカル インターフェースが用意されています。これは、GitHub を使用しない場合や、別の CI/CD 設定を使用する場合に、GitHub 接続フローの代わりとして機能します。

アーカイブのアップロードは、最初のバックエンドの作成時、または既存のバックエンド（Firebase CLI を使用してデプロイされたバックエンドを含む）で手動ロールアウトを作成するときに実行できます。

サポートされている形式

コンソール アップローダーは、次の 2 つの圧縮アーカイブ形式をネイティブに検証して受け入れます。

  • .zip
  • .tgz

これらの形式は、ファイル アップローダーの説明テキストに明示的に表示されます。

デプロイ手順

オプション A: バックエンドの初期オンボーディング時
  1. ソースを選択する: バックエンド作成ウィザードの「アプリをインポートする方法」ステップで、[ZIP をアップロード] を選択します。
  2. オンボーディングの準備: [次へ] をクリックすると、バックグラウンドの準備フローがトリガーされます。このフローでは、Storage API が順次有効になり、正しいロールが設定されていることが確認され、バケットがアップサートされます。UI に、動的なステータス メッセージ（「API を有効にしています...」、「「権限を確認しています...」、「バケットを準備しています...」。
    • エラー処理とガードレール: 準備ステップが失敗した場合（オーナー以外のユーザーが IAM 権限不足により 403 PERMISSION_DENIED を受け取った場合など）、UI に専用の警告が表示され、プロジェクト オーナーに連絡するよう指示されます。ステッパー ナビゲーションは厳密にロックされ、問題が解決するまで [次へ] ボタンと最後の [完了してデプロイ] ボタンは無効のままになります。
  3. ファイルをアップロードする: 準備が正常に完了したら、アーカイブ ファイルを選択するか、ファイル アップローダー コンポーネントにドラッグします。

  4. 設定を構成する: アプリのルート ディレクトリを指定します（デフォルトは /）。

  5. [Finish and Deploy] をクリックします。アーカイブのアップロードは 1 回限りのアクションであり、機能するバックエンドを確保するためにすぐにデプロイする必要があるため、zip アップロードではスタンドアロンの [Finish] ボタンは無効になっています。

オプション B: 手動ロールアウトを作成する
  1. [ダイアログを開く]: App Hosting ダッシュボードで、[ロールアウトを作成] をクリックします。
  2. ソースを選択: ダイアログのステッパーで [ZIP をアップロード] を選択します。バックエンドに既存の GitHub 接続がない場合、[GitHub] オプションは無効になります。
  3. 準備とアップロード: 選択すると、同じバックグラウンド準備フロー（「API を有効にしています...」、「権限を確認しています...」、「バケットを準備しています...」）。成功したら、アップローダーを使用してアーカイブ ファイルをドラッグまたは選択し、[アプリのルート ディレクトリ] を指定して、[デプロイ] をクリックしてビルドとロールアウトをトリガーします。

Terraform を使用したデプロイ

ビルドプロセスとデプロイされた環境をより細かく制御する必要がある場合は、Terraform を使用してデプロイできます。Terraform を使用すると、宣言型構成ファイルを使用して App Hosting リソースを定義して管理できます。また、App Hosting に依存してソースコードからビルドするのではなく、独自のビルド済みコンテナ イメージを App Hosting に直接デプロイできます。

Terraform を初めて使用する場合は、Terraform と Firebase を使ってみるをご覧ください。Terraform にすでに精通している場合は、サンプル構成ファイルとその他の App Hosting リソースから始めることができます。

CI/CD 用の GitHub 接続を設定する

GitHub リポジトリは、Firebase コンソールのバックエンド設定の [デプロイ] タブでいつでも接続できます。これにより、ローカル環境からアプリのプロトタイプをデプロイし、準備が整ったら自動化された CI/CD パイプラインに移行できます。

AI ツールを使用してデプロイする

Firebase Studio は 2027 年 3 月 22 日にサポート終了となります。App Hosting バックエンドは影響を受けませんが、Firebase Studio の [公開] ボタンは廃止されます。URL を変更せずに更新を公開し続けるには、プロジェクトを移行してください。移行手順の詳細