Configura e gestisci i backend di hosting delle app

App Hosting è stato progettato per essere facile da usare e richiedere poca manutenzione, con impostazioni predefinite ottimizzate per la maggior parte dei casi d'uso. Allo stesso tempo, App Hosting fornisce strumenti per gestire e configurare i backend in base alle tue esigenze specifiche. Questa guida descrive questi strumenti e processi.

Imposta e aggiorna i secret e le variabili di ambiente

App Hosting ti consente di utilizzare le variabili di ambiente per i valori di configurazione non sensibili e i secret per i parametri sensibili come chiavi API, credenziali del database e token di servizio.

  • Variabili di ambiente standard: utilizzate per configurazioni di testo normale non sensibili (come URL di API pubbliche, flag di funzionalità o target di build). I valori sono visibili a tutti i membri del progetto.
  • Secret: utilizzati per parametri sensibili (come client secret OAuth, token API o password del database). I secret sono supportati da Secret Manager di Cloud. I valori dei secret sono protetti e non vengono mai visualizzati in testo normale nella console Firebase. Al contrario, la console fornisce deep link per visualizzare e gestire i valori dei secret direttamente in Cloud Secret Manager.

Puoi definire e gestire i parametri dell'ambiente utilizzando due approcci complementari:

  • Console Firebase: aggiungi, modifica e collega rapidamente secret o variabili in modo dinamico durante la creazione iniziale del backend o dopo il deployment nelle impostazioni del backend.

  • Code-first (apphosting.yaml): dichiara le variabili di ambiente e i riferimenti ai secret nel file di configurazione del repository per i deployment con controllo della versione o utilizza apphosting.<env>.yaml per impostare valori diversi per ambienti diversi.

Console Firebase

Uno screenshot della finestra di dialogo della console Firebase per l'aggiunta di variabili di ambiente

apphosting.yaml 

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

Gestisci variabili e secret nella console Firebase

Puoi configurare le variabili di ambiente e i secret nella console Firebase durante la creazione di un backend o in qualsiasi momento dalle impostazioni del backend. Le modifiche salvate senza deployment vengono applicate alla prossima implementazione e non influiscono su quella attuale.

Configura variabili e secret durante la creazione del backend

Quando crei un nuovo backend App Hosting nella console Firebase, puoi configurare variabili di ambiente e secret standard durante il passaggio Configura il tuo backend della configurazione guidata:

  1. Nella console Firebase, vai a Hosting e serverless > App Hosting e fai clic su Crea backend.
  2. Completa i passaggi iniziali della procedura guidata per selezionare la regione principale e il repository di codice.
  3. Nella sezione Configura il backend, individua le schede comprimibili per Variabili di ambiente e Secret, dove puoi aggiungere variabili standard e allegare secret.
  4. Completa la procedura guidata di creazione del backend e fai clic su Fine ed esegui il deployment.

Gestisci variabili e secret nelle impostazioni di backend

Puoi visualizzare, aggiungere, modificare o eliminare variabili di ambiente e secret per i backend attivi dalla dashboard delle impostazioni del backend:

  1. Nella console Firebase, seleziona il tuo backend App Hosting e apri Impostazioni > Ambiente.
  2. Esamina le configurazioni esistenti nella tabella Variabili di ambiente:
    • Variabili standard: i valori vengono visualizzati come testo normale in blocchi di codice copiabili.
    • Secret: visualizzati come link selezionabile che mostra il nome del secret (che apre Cloud Secret Manager nella console Google Cloud) insieme alla versione di destinazione (ad esempio latest o un numero di versione specifico come 2).
  3. Per aggiungere una variabile o un secret:
    1. Fai clic su Aggiungi nuovo.
    2. In Passaggio 1: seleziona il tipo, scegli Variabile di ambiente standard (per i dati non sensibili visibili a tutti i membri del progetto) o Secret (per le chiavi API e le credenziali sensibili con accesso limitato), quindi fai clic su Avanti.
    3. In Passaggio 2: configura le impostazioni, inserisci il nome della Chiave e il Valore in testo normale (per le variabili standard) o seleziona l'ID Secret e la Versione (per i secret).
    4. Salva le modifiche utilizzando una delle seguenti opzioni:
      • Salva ed esegui il deployment: aggiorna immediatamente la configurazione del backend e attiva una nuova build e un nuovo rollout.
      • Salva e basta (dalla freccia menu a discesa accanto a Salva ed esegui il deployment): salva le modifiche alla configurazione senza attivare un'implementazione immediata. Le impostazioni aggiornate verranno applicate al deployment successivo.
  4. Per modificare o eliminare una voce esistente, fai clic sul menu Altre azioni (...) alla fine della riga:
    • Seleziona Modifica per modificare la chiave, il valore, la mappatura del secret o la versione, quindi fai clic su Salva ed esegui il deployment o Salva.
    • Seleziona Elimina e conferma la rimozione nella finestra di dialogo.

Trasferisci le variabili dai file dotenv

Per le app Next.js, i file dotenv contenenti variabili di ambiente funzionano con App Hosting.

Quando crei o aggiorni un backend, puoi trasferire le variabili di ambiente dal file dotenv alla console Firebase copiando e incollando l'intero contenuto del file dotenv nel primo campo Chiave del modulo Aggiungi nuovo in Impostazioni > Ambiente.

Tutte le variabili di ambiente copiate in questo modo vengono formattate automaticamente nel modulo senza doverle inserire singolarmente, purché l'input utilizzi la formattazione KEY=value standard:

KEY1=value1
KEY2=value2
KEY3=value3

Per un controllo complesso o granulare delle variabili di ambiente con qualsiasi framework, ti consigliamo di utilizzare apphosting.yaml.

Gestisci variabili e secret in apphosting.yaml

Per i workflow code-first, dichiara le variabili di ambiente standard e i riferimenti ai secret nella chiave env: nel file di configurazione apphosting.yaml del repository del progetto (consulta Crea e modifica 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

Ogni voce in env: supporta i seguenti campi:

  • variable: il nome della variabile di ambiente esposta al processo dell'applicazione.
  • value: il valore della stringa di testo normale (per le variabili di ambiente standard).
  • secret: il riferimento al secret di Cloud Secret Manager (per i secret). Puoi utilizzare il nome breve del secret (ad esempio myGeminiApiKeySecret o myGeminiApiKeySecret@1 bloccato) o il percorso completo della risorsa (projects/PROJECT_ID/secrets/SECRET_ID/versions/VERSION). Per ulteriori dettagli, consulta Archivia e accedi ai parametri secret.
  • availability: controlla se la variabile o il secret sono accessibili durante la fase BUILD, in RUNTIME o in entrambi i casi.

Imposta la disponibilità delle variabili

Le variabili di ambiente e i secret configurati nella console Firebase sono disponibili sia in fase di build sia in fase di runtime. Questo è anche il comportamento predefinito per le voci definite in apphosting.yaml, a meno che non restringi l'ambito utilizzando la proprietà availability. In apphosting.yaml (ma non nella console), puoi limitare una variabile o un secret solo all'ambiente di build (BUILD) o solo all'ambiente di runtime (RUNTIME).

Accedi a variabili e secret nel codice dell'applicazione

Sia che siano configurate nella console Firebase o in apphosting.yaml, le variabili di ambiente e i secret vengono esposti al runtime dell'applicazione come variabili di ambiente standard (ad esempio process.env in 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();
}
  • Accesso lato server: tutte le variabili di ambiente e i secret sono accessibili in modo sicuro nei contesti di esecuzione lato server (come i componenti server Next.js, le route API o i gestori di backend Node.js).

  • Esposizione lato client: per esporre le variabili di ambiente standard al browser in framework come Next.js, assicurati che la chiave della variabile segua le convenzioni del framework (ad esempio, con il prefisso NEXT_PUBLIC_).

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

Gerarchia delle variabili

Firebase App Hosting applica le variabili di ambiente e i secret in un ordine di precedenza basato sulla loro origine. Le configurazioni impostate nella console Firebase hanno sempre la precedenza sui parametri dichiarati nei file apphosting.yaml e dotenv. Se esiste una variabile di ambiente o una chiave secret con lo stesso nome sia in apphosting.yaml sia nella console Firebase, il valore della console ha la precedenza durante l'esecuzione della build e del runtime.

Ecco l'ordine di precedenza completo:

  1. ConsoleFirebase → variabili e secret impostati nella console
  2. apphosting.<env>.yaml → variabili e secret specificati in un file YAML specifico per l'ambiente, ad esempio apphosting.staging.yaml (consulta Esegui il deployment di più ambienti)
  3. apphosting.yaml → variabili e secret specificati nel file apphosting.yaml
  4. Sistema Firebase → variabili impostate da Firebase che contengono valori per FIREBASE_CONFIG o FIREBASE_WEBAPP_CONFIG, nonché variabili di ambiente che impostano i nomi host e le porte per le app SSR (impostate dagli adattatori App Hosting in bundle.yaml)

Variabili di ambiente compilate automaticamente

Esistono variabili di ambiente che vengono compilate automaticamente da App Hosting. Queste includono quelle compilate da Google Cloud, nonché le variabili di ambiente specifiche di Firebase quando appId è impostato sul backend durante la configurazione:

  • FIREBASE_CONFIG: (disponibile negli ambienti di build e runtime) Fornisce le seguenti informazioni di configurazione del progetto Firebase:

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

    Questa configurazione viene applicata automaticamente quando inizializzi l'SDK Firebase Admin senza argomenti.

  • FIREBASE_WEBAPP_CONFIG: (disponibile solo nell'ambiente di build) Fornisce le seguenti informazioni di configurazione del progetto Firebase:

    {
  "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>

    L'SDK Firebase JS verifica automaticamente la presenza di questa variabile di ambiente FIREBASE_WEBAPP_CONFIG in uno script postinstall durante la build, consentendoti di inizializzare l'SDK client anche senza argomenti.

Per maggiori dettagli su come utilizzare queste variabili di ambiente per inizializzare gli SDK, consulta Inizializza automaticamente l'SDK Firebase Admin e gli SDK web.

Tieni presente che i valori nella configurazione Firebase effettiva corrisponderanno alle risorse specifiche di cui hai eseguito il provisioning nel progetto.

Gerarchia delle variabili

Firebase App Hosting applica le variabili in un ordine di precedenza basato sulla loro origine. Ad esempio, i valori impostati nella console Firebase sostituiscono sempre o hanno la precedenza sui valori impostati nei file apphosting.yaml e dotenv.

Ecco l'ordine di precedenza completo:

  1. ConsoleFirebase → variabili impostate nella console
  2. apphosting.<env>.yaml → variabili specificate in un file YAML specifico dell'ambiente, ad esempio apphosting.staging.yaml (vedi Esegui il deployment di più ambienti)
  3. apphosting.yaml → variabili specificate nel file apphosting.yaml
  4. Sistema Firebase → variabili impostate da Firebase che contengono valori per firebase_config json o firebase_webapp_config, nonché variabili di ambiente che impostano i nomi host e le porte per le app SSR (impostate dagli adattatori di App Hosting in bundle.yaml)

Nomi riservati e limitazioni

Le variabili di ambiente definite nel contratto di runtime del container Cloud Run sono riservate e non possono essere impostate.

Le variabili di ambiente fornite dall'ambiente, diverse da quelle impostate automaticamente, potrebbero cambiare nelle versioni future del runtime. Come best practice, ti consigliamo di non fare affidamento su variabili di ambiente che non hai impostato in modo esplicito né di modificarle. Valuta inoltre la possibilità di aggiungere un prefisso a qualsiasi variabile di ambiente con una chiave univoca per evitare conflitti.

Alcune chiavi delle variabili di ambiente sono riservate per uso interno. Non utilizzare nessuna di queste chiavi nei file di configurazione:

  • Stringhe vuote ("")
  • Chiavi che contengono "="
  • Chiavi che iniziano con X_FIREBASE_, X_GOOGLE_ o CLOUD_RUN_
  • PORT
  • K_SERVICE
  • K_REVISION
  • K_CONFIGURATION
  • Chiavi duplicate

Crea e modifica apphosting.yaml

Per la configurazione avanzata, ad esempio secret o impostazioni di runtime come concorrenza, CPU e limiti di memoria, devi creare e modificare il file apphosting.yaml nella directory root dell'app. Questo file supporta i riferimenti ai secret gestiti con Cloud Secret Manager, il che lo rende sicuro per il controllo del codice sorgente.

Per creare apphosting.yaml, esegui il comando seguente:

firebase init apphosting

In questo modo viene creato un file apphosting.yaml di base con una configurazione di esempio (commentata). Dopo la modifica, un file apphosting.yaml tipico potrebbe essere simile al seguente, con le impostazioni per il servizio Cloud Run del backend, alcune variabili di ambiente e alcuni riferimenti ai secret gestiti da 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

Il resto di questa guida fornisce ulteriori informazioni e contesto per queste impostazioni di esempio.

Configura le impostazioni del servizio Cloud Run

Con le impostazioni di apphosting.yaml, puoi configurare il provisioning del tuo servizio Cloud Run. Le impostazioni disponibili per il servizio Cloud Run sono fornite nell'oggetto runConfig:

Tieni presente che cpu, memoryMiB e concurrency hanno limiti interdipendenti (ad esempio, configurazioni di memoria più elevate richiedono limiti di CPU minimi più elevati e le CPU frazionarie richiedono una contemporaneità di 1). Consulta la documentazione di Cloud Run sui limiti della CPU e sui limiti di memoria per gli intervalli validi e le combinazioni richieste.

Esegui l'override degli script di build ed esecuzione

App Hosting deduce il comando di build e avvio dell'app in base al framework rilevato. Se vuoi utilizzare un comando di build o di avvio personalizzato, puoi eseguire l'override dei valori predefiniti di App Hosting in apphosting.yaml.

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

L'override del comando di build ha la precedenza su qualsiasi altro comando di build, disattiva gli adattatori del framework per la tua app e disattiva tutte le ottimizzazioni specifiche del framework fornite da App Hosting. È meglio utilizzarla quando le funzionalità della tua app non sono ben supportate dagli adattatori. Se vuoi modificare il comando di build, ma continuare a utilizzare gli adattatori forniti, imposta lo script di build in package.json come descritto in Adattatori del framework App Hosting.

Utilizza l'override del comando di esecuzione quando vuoi utilizzare un comando specifico per avviare l'app diverso dal comando dedotto da App Hosting.

Configura l'output della build

App Hosting ottimizza i deployment delle app per impostazione predefinita eliminando i file di output inutilizzati, come indicato dal framework. Se vuoi ottimizzare ulteriormente le dimensioni di deployment dell'app o ignorare le ottimizzazioni predefinite, puoi eseguire l'override in apphosting.yaml.

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

Il parametro include accetta un elenco di directory e file relativi alla directory root dell'app necessari per eseguire il deployment dell'app. Se vuoi assicurarti che tutti i file vengano conservati, imposta include su [.] e verrà eseguito il deployment di tutti i file.

Archivia e accedi ai parametri dei secret

Le informazioni sensibili, come le chiavi API, devono essere archiviate come secret. Puoi collegare i secret al tuo backend nella console Firebase o farvi riferimento in apphosting.yaml per evitare di inserire informazioni sensibili nel controllo del codice sorgente.

I parametri di tipo secret rappresentano parametri di stringa con un valore archiviato in Cloud Secret Manager. Anziché derivare il valore direttamente, i parametri secret verificano l'esistenza in Cloud Secret Manager e caricano i valori durante l'implementazione.

env:
  - variable: API_KEY
    secret: myApiKeySecret

I secret in Secret Manager di Cloud possono avere più versioni. Per impostazione predefinita, il valore di un parametro secret disponibile per il backend live è bloccato sull'ultima versione disponibile del secret al momento della creazione del backend. Se hai requisiti per il controllo delle versioni e la gestione del ciclo di vita dei parametri, puoi bloccare versioni specifiche nella console Firebase o in apphosting.yaml. Ad esempio, per bloccare la versione 5 in apphosting.yaml:

env:
  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

Puoi creare secret con il comando Firebase dell'interfaccia a riga di comando firebase apphosting:secrets:set e ti verrà chiesto di aggiungere le autorizzazioni necessarie. Questo flusso ti offre l'opzione di aggiungere automaticamente il riferimento al secret a apphosting.yaml.

Concedi l'accesso a Secret Manager

Affinché App Hosting possa recuperare i valori dei secret durante i rollout di build e runtime, il service account del servizio di backend App Hosting deve disporre dell'autorizzazione per accedere a Cloud Secret Manager.

Se crei secret utilizzando la console di Cloud Secret Manager o l'interfaccia a riga di comando gcloud anziché firebase apphosting:secrets:set, concedi l'accesso al tuo backend utilizzando l'interfaccia a riga di comando Firebase:

firebase apphosting:secrets:grantaccess SECRET_NAME

In alternativa, puoi concedere il ruolo Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) all'agente di servizio App Hosting (service-PROJECT_NUMBER@gcp-sa-apphosting.iam.gserviceaccount.com) o al service account di runtime del tuo backend utilizzando l'interfaccia a riga di comando gcloud:

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

Accesso alla console e autorizzazioni basate sui ruoli

La console Firebase limita dinamicamente le funzionalità di gestione degli ambienti e di Secret Manager in base alle autorizzazioni IAM dell'utente:

  • Ruolo Visualizzatore: gli utenti con autorizzazioni di sola lettura per il progetto possono visualizzare le impostazioni di configurazione esistenti, ma non possono apportare modifiche.
    • Durante la creazione del backend, il pulsante Crea backend è disabilitato.
    • In Impostazioni > Ambiente del backend, il pulsante Aggiungi nuovo è disattivato e i menu delle righe Altre azioni (...) sono nascosti.
  • Autorizzazioni di Secret Manager mancanti: gli utenti che non dispongono delle autorizzazioni IAM per interagire con Cloud Secret Manager visualizzano un messaggio di avviso nella console (Chiedi a un Project Owner l'autorizzazione per aggiungere secret):
    • Durante la creazione del backend, la scheda Secret è disabilitata.
    • In Impostazioni > Ambiente del backend, l'opzione Secret è disabilitata quando fai clic su Aggiungi nuovo e alcune delle opzioni nel menu della riga Altre azioni (...) sono nascoste nelle voci dei secret esistenti.

Configura l'accesso VPC

Il tuo backend App Hosting può connettersi a una rete Virtual Private Cloud (VPC). Per saperne di più e per un esempio, consulta Connetti Firebase App Hosting a una rete VPC.

Utilizza la mappatura vpcAccess nel file apphosting.yaml per configurare l'accesso. Utilizza un nome di rete/connettore completo o un ID. L'utilizzo degli ID consente la portabilità tra ambienti di gestione temporanea e di produzione con connettori/reti diversi.

Configurazione VPC diretto in uscita (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

Configurazione del connettore serverless (apphosting.yaml):

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

Gestisci i backend

I comandi per la gestione di base dei backend App Hosting sono forniti nella console Firebase e nell'interfaccia a riga di comando Firebase. Questa sezione descrive alcune delle attività di gestione più comuni, tra cui la creazione e l'eliminazione dei backend.

Crea un backend

Un backend App Hosting è la raccolta di risorse gestite che App Hosting crea per creare ed eseguire la tua app web.

Console Firebase: vai a Hosting e serverless > App Hosting, quindi fai clic su Crea backend (se questo è il primo backend nel tuo progetto Firebase, fai clic su Inizia).

Interfaccia a riga di comando Firebase: (v13.15.4 o successiva) Per creare un backend, esegui il comando seguente dalla directory principale del progetto locale, fornendo l'ID progetto come argomento:

firebase apphosting:backends:create --project PROJECT_ID

Sia per la console che per l'interfaccia a riga di comando, segui i prompt per scegliere una regione, configurare una connessione GitHub e configurare queste impostazioni di deployment di base:

  • Imposta la directory root dell'app (il valore predefinito è /)

    Di solito è qui che si trova il file package.json.

  • Imposta il branch live

    Questo è il branch del tuo repository GitHub di cui viene eseguito il deployment nell'URL pubblicato. Spesso, è il branch in cui vengono uniti i branch delle funzionalità o dello sviluppo.

  • Accetta o rifiuta le implementazioni automatiche

    Le implementazioni automatiche sono abilitate per impostazione predefinita. Al termine della creazione del backend, puoi scegliere di eseguire immediatamente il deployment della tua app in App Hosting.

  • Assegna un nome al backend.

  • Seleziona l'ambiente di runtime. Per impostazione predefinita, viene preselezionata la versione di Node.js consigliata più recente.

Elimina un backend

Per rimuovere completamente un backend, utilizza prima la console Firebase o l'interfaccia a riga di comando Firebase per eliminarlo, quindi rimuovi manualmente gli asset correlati, prestando particolare attenzione a non eliminare risorse che potrebbero essere utilizzate da altri backend o altri aspetti del tuo progetto Firebase.

Console Firebase: dal menu Impostazioni, seleziona Elimina backend.

Interfaccia a riga di comando Firebase: (v13.15.4 o successive)

  1. Esegui questo comando per eliminare il backend App Hosting. In questo modo, tutti i domini per il backend vengono disattivati e il servizio Cloud Run associato viene eliminato:

    firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID

  2. (Facoltativo) Nella scheda della console Google Cloud per Artifact Registry, elimina l'immagine del tuo backend in "firebaseapphosting-images".

  3. In Cloud Secret Manager, elimina tutti i secret con "apphosting" nel nome, facendo particolare attenzione ad assicurarti che non siano utilizzati da altri backend o altri aspetti del tuo progetto Firebase.