Configurer et gérer des backends App Hosting

App Hosting a été conçu pour être facile à utiliser et nécessiter peu de maintenance, avec des paramètres par défaut optimisés pour la plupart des cas d'utilisation. En parallèle, App Hosting fournit des outils pour gérer et configurer les backends en fonction de vos besoins spécifiques. Ce guide décrit ces outils et processus.

Définir et mettre à jour des variables d'environnement et des secrets

App Hosting vous permet d'utiliser des variables d'environnement pour les valeurs de configuration non sensibles et des secrets pour les paramètres sensibles tels que les clés API, les identifiants de base de données et les jetons de service.

  • Variables d'environnement standards : utilisées pour les configurations non sensibles en texte brut (telles que les URL d'API publiques, les flags de fonctionnalité ou les cibles de compilation). Les valeurs sont visibles par tous les membres du projet.
  • Secrets : utilisés pour les paramètres sensibles (tels que les codes secrets du client OAuth, les jetons d'API ou les mots de passe de base de données). Les secrets sont stockés dans Cloud Secret Manager. Les valeurs des secrets sont protégées et ne sont jamais affichées en texte brut dans la console Firebase. À la place, la console fournit des liens profonds pour afficher et gérer les valeurs des secrets directement dans Cloud Secret Manager.

Vous pouvez définir et gérer les paramètres d'environnement à l'aide de deux approches complémentaires :

  • Console Firebase : ajoutez, modifiez et associez rapidement des secrets ou des variables de manière dynamique lors de la création initiale du backend ou après le déploiement dans les paramètres du backend.

  • Code-first (apphosting.yaml) : déclarez des variables d'environnement et des références de secrets dans le fichier de configuration de votre dépôt pour les déploiements contrôlés par version, ou utilisez apphosting.<env>.yaml pour définir des valeurs différentes pour différents environnements.

Console Firebase

Capture d'écran de la boîte de dialogue de la console Firebase permettant d'ajouter des variables d'environnement

apphosting.yaml 

env:
  - variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
  - variable: API_KEY
    secret: myApiKeySecret

Gérer les variables et les secrets dans la console Firebase

Vous pouvez configurer des variables d'environnement et des secrets dans la console Firebase lors de la création d'un backend ou à tout moment depuis les paramètres de votre backend. Les modifications enregistrées sans déploiement prennent effet lors de votre prochain déploiement et n'affectent pas le déploiement actuel.

Configurer des variables et des secrets lors de la création du backend

Lorsque vous créez un backend App Hosting dans la console Firebase, vous pouvez configurer des variables d'environnement et des secrets standards lors de l'étape Configurer votre backend de l'assistant de configuration :

  1. Dans la console Firebase, accédez à Hébergement et sans serveur > App Hosting, puis cliquez sur Créer un backend.
  2. Suivez les étapes initiales de l'assistant pour sélectionner votre région principale et votre dépôt de code.
  3. Dans la section Configurer votre backend, recherchez les fiches réductibles Variables d'environnement et Secrets, où vous pouvez ajouter des variables standards et associer des secrets.
  4. Suivez les étapes de l'assistant de création de backend, puis cliquez sur Terminer et déployer.

Gérer les variables et les secrets dans les paramètres du backend

Vous pouvez afficher, ajouter, modifier ou supprimer des variables d'environnement et des secrets pour les backends actifs à partir du tableau de bord des paramètres du backend :

  1. Dans la console Firebase, sélectionnez votre backend App Hosting, puis ouvrez Paramètres > Environnement.
  2. Examinez les configurations existantes dans le tableau Variables d'environnement :
    • Variables standards : les valeurs sont affichées en texte brut dans des blocs de code copiables.
    • Secrets : affiché sous la forme d'un lien cliquable indiquant le nom du secret (qui ouvre Cloud Secret Manager dans la console Google Cloud) ainsi que sa version ciblée (par exemple, latest ou un numéro de version spécifique comme 2).
  3. Pour ajouter une variable ou un secret :
    1. Cliquez sur Ajouter.
    2. À l'étape 1 : Sélectionner le type, choisissez Variable d'environnement standard (pour les données non sensibles visibles par tous les membres du projet) ou Secret (pour les clés API et les identifiants sensibles à accès restreint), puis cliquez sur Suivant.
    3. À l'étape 2 : Configurer les paramètres, saisissez le nom de la clé et la valeur en texte brut (pour les variables standards) ou sélectionnez l'ID et la version du secret (pour les secrets).
    4. Enregistrez vos modifications à l'aide de l'une des options suivantes :
      • Enregistrer et déployer : met immédiatement à jour la configuration du backend, et déclenche une nouvelle compilation et un nouveau déploiement.
      • Enregistrer (dans la flèche du menu déroulant à côté de Enregistrer et déployer) : enregistre les modifications de configuration sans déclencher de déploiement immédiat. Les paramètres mis à jour prennent effet lors de votre prochain déploiement.
  4. Pour modifier ou supprimer une entrée existante, cliquez sur le menu Autres actions (...) à la fin de la ligne :
    • Sélectionnez Modifier pour modifier la clé, la valeur, le mappage de secret ou la version, puis cliquez sur Enregistrer et déployer ou Enregistrer.
    • Sélectionnez Supprimer et confirmez la suppression dans la boîte de dialogue.

Transférer des variables à partir de fichiers dotenv

Pour les applications Next.js, les fichiers dotenv contenant des variables d'environnement fonctionnent avec App Hosting.

Lorsque vous créez ou mettez à jour un backend, vous pouvez transférer des variables d'environnement de votre fichier dotenv vers la console Firebase en copiant et en collant l'intégralité du contenu du fichier dotenv dans le premier champ Clé du formulaire Ajouter sous Paramètres > Environnement.

Toutes les variables d'environnement copiées de cette manière sont automatiquement mises en forme dans le formulaire sans qu'il soit nécessaire de les saisir individuellement, à condition que l'entrée utilise la mise en forme KEY=value standard :

KEY1=value1
KEY2=value2
KEY3=value3

Pour un contrôle complexe ou précis des variables d'environnement avec n'importe quel framework, nous vous recommandons d'utiliser apphosting.yaml.

Gérer les variables et les secrets dans apphosting.yaml

Pour les workflows code-first, déclarez des variables d'environnement standards et des références de secrets sous la clé env: dans le fichier de configuration apphosting.yaml de votre dépôt de projet (voir Créer et modifier apphosting.yaml).

env:
  # Standard environment variables
  - variable: PUBLIC_API_URL
    value: https://api.example.com
    availability:
      - BUILD
      - RUNTIME
  - variable: FEATURE_FLAG_NEW_UI
    value: "true"

  # Secret references backed by Cloud Secret Manager
  - variable: DATABASE_URL
    secret: projects/PROJECT_ID/secrets/db-connection-string/versions/latest
  - variable: GEMINI_API_KEY
    secret: myGeminiApiKeySecret@1

Chaque entrée de env: accepte les champs suivants :

  • variable : nom de la variable d'environnement exposé au processus de votre application.
  • value : valeur de chaîne en texte brut (pour les variables d'environnement standards).
  • secret : référence du secret Cloud Secret Manager (pour les secrets). Vous pouvez utiliser le nom court du secret (tel que myGeminiApiKeySecret ou myGeminiApiKeySecret@1 épinglé) ou le chemin d'accès complet à la ressource (projects/PROJECT_ID/secrets/SECRET_ID/versions/VERSION). Pour en savoir plus, consultez Stocker des paramètres secrets et y accéder.
  • availability : contrôle si la variable ou le secret est accessible pendant la phase BUILD, à l'étape RUNTIME ou les deux.

Définir la disponibilité des variables

Les variables d'environnement et les secrets configurés dans la console Firebase sont disponibles au moment de la compilation et de l'exécution. Il s'agit également du comportement par défaut pour les entrées définies dans apphosting.yaml, sauf si vous limitez le champ d'application à l'aide de la propriété availability. Dans apphosting.yaml (mais pas dans la console), vous pouvez limiter une variable ou un secret à l'environnement de compilation (BUILD) ou à l'environnement d'exécution (RUNTIME).

Accéder aux variables et aux secrets dans le code d'application

Qu'elles soient configurées dans la console Firebase ou dans apphosting.yaml, les variables d'environnement et les secrets sont exposés à l'environnement d'exécution de votre application en tant que variables d'environnement standards (par exemple, process.env dans Node.js).

// Accessing a standard environment variable
const apiUrl = process.env.PUBLIC_API_URL;

// Accessing a secret
const apiKey = process.env.GEMINI_API_KEY;

export async function fetchData() {
  const response = await fetch(`${apiUrl}/data`, {
    headers: {
      'Authorization': `Bearer ${apiKey}`
    }
  });
  return response.json();
}
  • Accès côté serveur : toutes les variables d'environnement et tous les secrets sont accessibles de manière sécurisée dans les contextes d'exécution côté serveur (tels que les composants serveur Next.js, les routes d'API ou les gestionnaires de backend Node.js).

  • Exposition côté client : pour exposer des variables d'environnement standards au navigateur dans des frameworks comme Next.js, assurez-vous que la clé de variable respecte les conventions du framework (par exemple, préfixée par NEXT_PUBLIC_).

    env:
  - variable: NEXT_PUBLIC_STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      - BUILD
      - RUNTIME

Hiérarchie des variables

Firebase App Hosting applique vos variables d'environnement et vos secrets dans un ordre de priorité basé sur leur source. Les configurations définies dans la console Firebase remplacent toujours les paramètres déclarés dans les fichiers apphosting.yaml et dotenv. Si une variable d'environnement ou une clé secrète portant le même nom existe à la fois dans apphosting.yaml et dans la console Firebase, la valeur de la console est prioritaire lors de la compilation et de l'exécution.

Voici l'ordre de priorité complet :

  1. Console Firebase : variables et secrets définis dans la console
  2. apphosting.<env>.yaml : variables et secrets spécifiés dans un fichier YAML spécifique à l'environnement, tel que apphosting.staging.yaml (voir Déployer plusieurs environnements)
  3. apphosting.yaml : variables et secrets spécifiés dans le fichier apphosting.yaml
  4. Système Firebase : variables définies par Firebase qui contiennent des valeurs pour FIREBASE_CONFIG ou FIREBASE_WEBAPP_CONFIG, ainsi que des variables d'environnement qui définissent les noms d'hôte et les ports des applications SSR (définies par les adaptateurs App Hosting dans bundle.yaml)

Variables d'environnement renseignées automatiquement

Certaines variables d'environnement sont automatiquement renseignées par App Hosting. Cela inclut celles renseignées par Google Cloud, ainsi que les variables d'environnement spécifiques à Firebase lorsque appId est défini sur le backend lors de la configuration :

  • FIREBASE_CONFIG : (disponible dans les environnements de compilation et d'exécution) fournit les informations de configuration du projet Firebase suivantes :

    {
  "databaseURL": "https://DATABASE_NAME.firebaseio.com",
  "storageBucket": "PROJECT_ID.firebasestorage.app",
  "projectId": "PROJECT_ID"
}

    Cette configuration est appliquée automatiquement lorsque vous initialisez le SDK Admin Firebase sans argument.

  • FIREBASE_WEBAPP_CONFIG : (disponible uniquement dans l'environnement de compilation) fournit les informations de configuration du projet Firebase suivantes :

    {
  "apiKey": "API_KEY",
  "appId": "APP_ID",
  "authDomain": "AUTH_DOMAIN.firebaseapp.com",
  "databaseURL": "https://DATABASE_NAME.firebaseio.com",
  "messagingSenderId": "PROJECT_NUMBER",
  "projectId": "PROJECT_ID",
  "storageBucket": "PROJECT_ID.firebasestorage.app"
}</span>

    Le SDK JS Firebase recherche automatiquement cette variable d'environnement FIREBASE_WEBAPP_CONFIG dans un script post-installation lors de la compilation, ce qui vous permet également d'initialiser le SDK client sans aucun argument.

Pour en savoir plus sur l'utilisation de ces variables d'environnement pour initialiser les SDK, consultez Initialiser automatiquement le SDK Admin Firebase et les SDK Web.

Notez que les valeurs de votre configuration Firebase réelle correspondront aux ressources spécifiques que vous avez provisionnées dans votre projet.

Hiérarchie des variables

Firebase App Hosting applique vos variables dans un ordre de priorité basé sur leur source. Par exemple, les valeurs définies dans la console Firebase remplacent toujours les valeurs définies dans les fichiers apphosting.yaml et dotenv, ou sont prioritaires sur celles-ci.

Voici l'ordre de priorité complet :

  1. Console Firebase : variables définies dans la console
  2. apphosting.<env>.yaml : variables spécifiées dans un fichier YAML spécifique à l'environnement, tel que apphosting.staging.yaml (voir Déployer plusieurs environnements)
  3. apphosting.yaml → variables spécifiées dans le fichier apphosting.yaml
  4. Système Firebase : variables définies par Firebase qui contiennent des valeurs pour firebase_config json ou firebase_webapp_config, ainsi que des variables d'environnement qui définissent les noms d'hôte et les ports des applications SSR (définies par les adaptateurs App Hosting dans bundle.yaml)

Noms réservés et limites

Les variables d'environnement définies dans le contrat d'exécution du conteneurCloud Run sont réservées et ne peuvent pas être définies.

Les variables d'environnement fournies par l'environnement, autres que celles définies automatiquement, pourront faire l'objet de modifications dans des versions d'exécution ultérieures. Nous vous recommandons de ne pas dépendre de variables d'environnement que vous n'avez pas explicitement définies, ni de les modifier. Envisagez de préfixer toutes les variables d'environnement avec une clé unique pour éviter les conflits.

Certaines clés de variables d'environnement sont réservées à un usage interne. N'utilisez aucune de ces clés dans vos fichiers de configuration :

  • Chaînes vides ("")
  • Clés contenant "="
  • Clés commençant par X_FIREBASE_, X_GOOGLE_ ou CLOUD_RUN_
  • PORT
  • K_SERVICE
  • K_REVISION
  • K_CONFIGURATION
  • Clés en double

Créer et modifier apphosting.yaml

Pour les configurations avancées telles que les secrets ou les paramètres d'exécution (simultanéité, processeur et limites de mémoire), vous devez créer et modifier le fichier apphosting.yaml dans le répertoire racine de votre application. Ce fichier accepte les références aux secrets gérés avec Cloud Secret Manager, ce qui permet de l'enregistrer en toute sécurité dans le contrôle de code source.

Pour créer apphosting.yaml, exécutez la commande suivante :

firebase init apphosting

Cette commande crée un fichier apphosting.yaml de démarrage de base avec un exemple de configuration (commenté). Après modification, un fichier apphosting.yaml standard peut se présenter comme suit, avec les paramètres du service Cloud Run du backend, certaines variables d'environnement et certaines références aux secrets gérés par Cloud Secret Manager :

# Settings for Cloud Run
runConfig:
  minInstances: 2
  maxInstances: 100
  concurrency: 100
  cpu: 2
  memoryMiB: 1024

# Environment variables and secrets
env:
  - variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app
    availability:
      - BUILD
      - RUNTIME

  - variable: API_KEY
    secret: myApiKeySecret

    # Same as API_KEY above but with a pinned version.
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

    # Same as API_KEY above but with the long form secret reference as defined by Cloud Secret Manager.
  - variable: VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID

    # Same as API_KEY above but with the long form secret reference with pinned version.
  - variable: PINNED_VERBOSE_API_KEY
    secret: projects/test-project/secrets/secretID/versions/5

Le reste de ce guide fournit plus d'informations et de contexte pour ces exemples de paramètres.

Configurer les paramètres du service Cloud Run

Les paramètres apphosting.yaml vous permettent de configurer la manière dont votre service Cloud Run est provisionné. Les paramètres disponibles pour le service Cloud Run sont fournis dans l'objet runConfig :

Notez que cpu, memoryMiB et concurrency ont des limites interdépendantes (par exemple, les configurations de mémoire plus élevées nécessitent des limites de processeur minimales plus élevées, et les processeurs fractionnaires nécessitent une simultanéité de 1). Consultez la documentation Cloud Run sur les limites de processeur et les limites de mémoire pour connaître les plages valides et les combinaisons requises.

Remplacer les scripts de compilation et d'exécution

App Hosting déduit la commande de compilation et de démarrage de votre application en fonction du framework détecté. Si vous souhaitez utiliser une commande de compilation ou de démarrage personnalisée, vous pouvez remplacer les valeurs par défaut de App Hosting dans apphosting.yaml.

scripts:
  buildCommand: next build --no-lint
  runCommand: node dist/index.js

La commande de compilation de remplacement est prioritaire sur toutes les autres commandes de compilation. Elle désactive les adaptateurs de framework pour votre application et désactive toutes les optimisations spécifiques au framework fournies par App Hosting. Il est préférable de l'utiliser lorsque les fonctionnalités de votre application ne sont pas bien prises en charge par les adaptateurs. Si vous souhaitez modifier votre commande de compilation, mais continuer à utiliser les adaptateurs fournis, définissez plutôt votre script de compilation dans package.json, comme décrit dans Adaptateurs de framework App Hosting.

Utilisez le remplacement de la commande d'exécution lorsqu'une commande spécifique que vous souhaitez utiliser pour démarrer votre application est différente de la commande déduite par App Hosting.

Configurer la sortie de compilation

App Hosting optimise par défaut les déploiements de votre application en supprimant les fichiers de sortie inutilisés, comme indiqué par le framework. Si vous souhaitez optimiser davantage la taille de déploiement de votre application ou ignorer les optimisations par défaut, vous pouvez remplacer ce paramètre dans apphosting.yaml.

outputFiles:
  serverApp:
    include: [dist, server.js]

Le paramètre include accepte une liste de répertoires et de fichiers relatifs au répertoire racine de l'application qui sont nécessaires pour déployer votre application. Si vous souhaitez vous assurer que tous les fichiers sont conservés, définissez "include" sur [.]. Tous les fichiers seront alors déployés.

Stocker des paramètres secrets et y accéder

Les informations sensibles telles que les clés API doivent être stockées en tant que secrets. Vous pouvez associer des secrets à votre backend dans la console Firebase ou les référencer dans apphosting.yaml pour éviter d'enregistrer des informations sensibles dans le contrôle de code source.

Les paramètres de type secret représentent des paramètres de chaîne dont la valeur est stockée dans Cloud Secret Manager. Au lieu de dériver directement la valeur, les paramètres secrets vérifient l'existence dans Cloud Secret Manager et chargent les valeurs lors du déploiement.

env:
  - variable: API_KEY
    secret: myApiKeySecret

Les secrets dans Cloud Secret Manager peuvent avoir plusieurs versions. Par défaut, la valeur d'un paramètre de secret disponible pour votre backend actif est épinglée à la dernière version disponible du secret au moment de la compilation du backend. Si vous avez des exigences concernant la gestion des versions et du cycle de vie des paramètres, vous pouvez épingler des versions spécifiques dans la console Firebase ou dans apphosting.yaml. Par exemple, pour épingler la version 5 dans apphosting.yaml :

env:
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

Vous pouvez créer des secrets à l'aide de la commande firebase apphosting:secrets:set de la CLI Firebase. Vous serez alors invité à ajouter les autorisations nécessaires. Ce flux vous permet d'ajouter automatiquement la référence du secret à apphosting.yaml.

Accorder l'accès à Cloud Secret Manager

Pour que App Hosting puisse récupérer les valeurs des secrets lors des déploiements de compilation et d'exécution, le compte de service du backend App Hosting doit être autorisé à accéder à Cloud Secret Manager.

Si vous créez des secrets à l'aide de la console Cloud Secret Manager ou de la CLI gcloud au lieu de firebase apphosting:secrets:set, accordez l'accès à votre backend à l'aide de la CLI Firebase :

firebase apphosting:secrets:grantaccess SECRET_NAME

Vous pouvez également attribuer le rôle "Accesseur de secrets Secret Manager" (roles/secretmanager.secretAccessor) à l'agent de service App Hosting (service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com) ou au compte de service d'exécution de votre backend à l'aide de la CLI gcloud :

gcloud secrets add-iam-policy-binding SECRET_NAME \
    --member="serviceAccount:service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com" \
    --role="roles/secretmanager.secretAccessor"

Accès à la console et autorisations basées sur les rôles

La console Firebase limite de manière dynamique les fonctionnalités de gestion des environnements et des secrets en fonction des autorisations IAM de l'utilisateur :

  • Rôle de lecteur : les utilisateurs disposant d'autorisations de projet en lecture seule peuvent afficher les paramètres de configuration existants, mais ne peuvent pas les modifier.
    • Pendant la création du backend, le bouton Créer un backend est désactivé.
    • Dans Paramètres > Environnement du backend, le bouton Ajouter est désactivé et les menus de ligne Autres actions (...) sont masqués.
  • Autorisations Secret Manager manquantes : les utilisateurs qui ne disposent pas des autorisations IAM pour interagir avec Cloud Secret Manager voient un message d'avertissement dans la console (Demandez à un propriétaire de projet l'autorisation d'ajouter des secrets) :
    • Lors de la création du backend, la fiche Secrets est désactivée.
    • Dans Paramètres > Environnement du backend, l'option Secret est désactivée lorsque vous cliquez sur Ajouter, et certaines options du menu de ligne Autres actions (...) sont masquées sur les entrées de secret existantes.

Configurer l'accès au VPC

Votre backend App Hosting peut se connecter à un réseau de cloud privé virtuel (VPC). Pour en savoir plus et obtenir un exemple, consultez Connecter Firebase App Hosting à un réseau VPC.

Utilisez le mappage vpcAccess dans votre fichier apphosting.yaml pour configurer l'accès. Utilisez un nom de réseau/connecteur complet ou un ID. L'utilisation d'ID permet la portabilité entre les environnements de préproduction et de production avec différents connecteurs/réseaux.

Configuration de la sortie VPC directe (apphosting.yaml) :

runConfig:
  vpcAccess:
    egress: PRIVATE_RANGES_ONLY # Default value
    networkInterfaces:
      # Specify at least one of network and/or subnetwork
      - network: my-network-id
        subnetwork: my-subnetwork-id

Configuration du connecteur sans serveur (apphosting.yaml) :

runConfig:
  vpcAccess:
    egress: ALL_TRAFFIC
    connector: connector-id

Gérer les backends

Les commandes de gestion de base des backends App Hosting sont fournies dans la console Firebase et la CLI Firebase. Cette section décrit certaines des tâches de gestion les plus courantes, y compris la création et la suppression de backends.

Créer un backend

Un backend App Hosting est l'ensemble des ressources gérées que App Hosting crée pour créer et exécuter votre application Web.

Console Firebase : accédez à Hébergement et sans serveur > App Hosting, puis cliquez sur Créer un backend (s'il s'agit du premier backend de votre projet Firebase, cliquez sur Commencer).

CLI Firebase (v13.15.4 ou ultérieure) : pour créer un backend, exécutez la commande suivante à partir de la racine du répertoire de votre projet local, en fournissant votre ID de projet en tant qu'argument :

firebase apphosting:backends:create --project PROJECT_ID

Pour la console ou la CLI, suivez les instructions pour choisir une région, configurer une connexion GitHub et configurer ces paramètres de déploiement de base :

  • Définissez le répertoire racine de votre application (par défaut, /).

    C'est généralement là que se trouve votre fichier package.json.

  • Définir la branche en ligne

    Il s'agit de la branche de votre dépôt GitHub qui est déployée sur votre URL active. Il s'agit souvent de la branche dans laquelle les branches de fonctionnalités ou de développement sont fusionnées.

  • Accepter ou refuser les déploiements automatiques

    Les déploiements automatiques sont activés par défaut. Une fois la création du backend terminée, vous pouvez choisir de déployer immédiatement votre application sur App Hosting.

  • Attribuez un nom à votre backend.

  • Sélectionnez votre environnement d'exécution. Par défaut, la version recommandée la plus récente de Node.js est présélectionnée.

    • Configurez les mises à jour automatiques des images de base (ABIU). ABIU est activé par défaut et applique automatiquement les correctifs de sécurité à votre environnement sous-jacent. Vous pouvez désactiver l'ABIU en sélectionnant "Non spécifié" pour votre environnement d'exécution.

Supprimer un backend

Pour supprimer complètement un backend, commencez par le supprimer à l'aide de la console Firebase ou de la CLI Firebase, puis supprimez manuellement les éléments associés, en veillant à ne pas supprimer les ressources susceptibles d'être utilisées par d'autres backends ou d'autres aspects de votre projet Firebase.

Console Firebase : dans le menu Paramètres, sélectionnez Supprimer le backend.

CLI Firebase (v13.15.4 ou version ultérieure)

  1. Exécutez la commande suivante pour supprimer le backend App Hosting. Cette opération désactive tous les domaines de votre backend et supprime le service Cloud Run associé :

    firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID

  2. (Facultatif) Dans l'onglet de la console Google Cloud pour Artifact Registry, supprimez l'image de votre backend dans "firebaseapphosting-images".

  3. Dans Cloud Secret Manager, supprimez tous les secrets dont le nom contient "apphosting", en veillant à ce qu'ils ne soient pas utilisés par d'autres backends ou d'autres aspects de votre projet Firebase.