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 権限をご覧ください。

初回オンボーディングの権限（ロケーションへの初回導入）

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

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

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

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

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

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

アクティブなデプロイ権限は次のとおりです。

  • バケットを確認する: storage.buckets.list
  • ソース アーカイブをアップロード: storage.objects.create
  • ビルドとロールアウトをトリガーする: 標準の 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. プロンプトが表示されたら、[既存のプロジェクトを使用する] を選択して、ターゲットの 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 アップロード）

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

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

サポートされている形式

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

  • .zip
  • .tgz

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

デプロイ手順

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

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

  5. [完了してデプロイ] をクリックします。アーカイブのアップロードは 1 回限りのアクションであり、バックエンドが機能するように、すぐにデプロイを行う必要があるため、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 リソースを使用して、すぐに始めることができます。

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

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

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

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