ऐप्लिकेशन होस्टिंग बैकएंड कॉन्फ़िगर और मैनेज करें

App Hosting को इस्तेमाल करना आसान है और इसे कम रखरखाव की ज़रूरत होती है. इसकी डिफ़ॉल्ट सेटिंग को ज़्यादातर मामलों के लिए ऑप्टिमाइज़ किया गया है. साथ ही, App Hosting आपको अपनी ज़रूरतों के हिसाब से बैकएंड को मैनेज और कॉन्फ़िगर करने के लिए टूल उपलब्ध कराता है. इस गाइड में, उन टूल और प्रोसेस के बारे में बताया गया है.

एनवायरमेंट वैरिएबल सेट और अपडेट करना

कभी-कभी, आपको अपनी बिल्ड प्रोसेस के लिए अतिरिक्त कॉन्फ़िगरेशन की ज़रूरत पड़ सकती है. App Hosting, एनवायरमेंट कॉन्फ़िगरेशन की सुविधा देता है. इसकी मदद से, इस तरह के डेटा को सेव किया जा सकता है और उसे वापस पाया जा सकता है. इसके लिए, Firebase कंसोल का इस्तेमाल किया जाता है. इसके अलावा, apphosting.yaml में भी ऐसा किया जा सकता है.

कंसोल में एनवायरमेंट वैरिएबल सेट करना, शुरू करने का सबसे तेज़ तरीका है. अगर आपको सीक्रेट पैरामीटर सेव और ऐक्सेस करने हैं, ऐसे वैरिएबल सेट करने हैं जो सिर्फ़ बिल्ड या रन टाइम पर उपलब्ध हों या कई एनवायरमेंट में एनवायरमेंट वैरिएबल शेयर करने हैं, तो apphosting.yaml का इस्तेमाल करें. कंसोल और apphosting.<env>.yaml, दोनों की मदद से अलग-अलग एनवायरमेंट के लिए अलग-अलग वैल्यू सेट की जा सकती हैं.

env:
-   variable: STORAGE_BUCKET
    value: mybucket.firebasestorage.app

वैरिएबल अपडेट करना

बैकएंड के लिए, सेटिंग टैब में जाकर, Firebase कंसोल में एनवायरमेंट वैरिएबल जोड़े जा सकते हैं और उनमें बदलाव किया जा सकता है. व्यू बैकएंड >> सेटिंग >> एनवायरमेंट पर जाएं. इसके बाद, एनवायरमेंट वैरिएबल जोड़ें, उनमें बदलाव करें या उन्हें मिटाएं.

apphosting.yaml, में एनवायरमेंट वैरिएबल जोड़ने और उनमें बदलाव करने के लिए, फ़ाइल को मैन्युअल तरीके से बनाएं और उसमें बदलाव करें.

आपके बदलाव, सिर्फ़ अगले रोलआउट से लागू होंगे. इनका असर मौजूदा रोलआउट पर नहीं पड़ेगा. या तो सेव करें और नया रोलआउट बनाएं या अपने वैरिएबल सेव करें और बाद में डिप्लॉय करें.

वैरिएबल की उपलब्धता सेट करना

Firebase कंसोल में बनाई गई एनवायरमेंट वैरिएबल, बिल्ड टाइम और रन टाइम, दोनों के लिए उपलब्ध होते हैं. यह apphosting.yaml में तय किए गए वैरिएबल के लिए भी डिफ़ॉल्ट शर्त है. हालांकि, availability प्रॉपर्टी का इस्तेमाल करके, इस स्कोप को कम किया जा सकता है. apphosting.yaml में (लेकिन कंसोल में नहीं), एनवायरमेंट वैरिएबल को सिर्फ़ बिल्ड एनवायरमेंट या सिर्फ़ रनटाइम एनवायरमेंट के लिए उपलब्ध कराया जा सकता है.

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

Next.js ऐप्लिकेशन के लिए, NEXT_PUBLIC_ प्रीफ़िक्स का इस्तेमाल उसी तरह किया जा सकता है जिस तरह से dotenv फ़ाइल में किया जाता है, ताकि ब्राउज़र में किसी वैरिएबल को ऐक्सेस किया जा सके.

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

Next.js के लिए dotenv फ़ाइलें

Next.js ऐप्लिकेशन के लिए, एनवायरमेंट वैरिएबल वाली dotenv फ़ाइलें App Hosting के साथ काम करती हैं.

बैकएंड बनाते या अपडेट करते समय, एनवायरमेंट वैरिएबल को अपनी dotenv फ़ाइल से Firebase कंसोल में ट्रांसफ़र किया जा सकता है. इसके लिए, dotenv फ़ाइल के पूरे कॉन्टेंट को कॉपी करें और एनवायरमेंट वैरिएबल की सेटिंग में "नया जोड़ें" फ़ॉर्म के पहले "कुंजी" फ़ील्ड में चिपकाएं.

इस तरह से कॉपी की गई सभी एनवायरमेंट वैरिएबल को फ़ॉर्म में साफ़ तौर पर फ़ॉर्मैट किया जाना चाहिए. इसके लिए, हर वैरिएबल को अलग-अलग डालने की ज़रूरत नहीं है. हालांकि, इनपुट का फ़ॉर्मैट इस तरह का होना चाहिए:

KEY1=value1
KEY2=value2
KEY3=value3

किसी भी फ़्रेमवर्क के साथ एनवायरमेंट वैरिएबल को जटिल या बारीकी से कंट्रोल करने के लिए, हमारा सुझाव है कि आप apphosting.yaml का इस्तेमाल करें.

अपने-आप जनरेट होने वाले एनवायरमेंट वैरिएबल

कुछ एनवायरमेंट वैरिएबल ऐसे होते हैं जो App Hosting अपने-आप भर देता है. इनमें Google Cloud से भरे गए वैरिएबल शामिल हैं. इसके अलावा, सेटअप के दौरान बैकएंड पर appId सेट होने पर, Firebase के लिए खास एनवायरमेंट वैरिएबल भी शामिल हैं:

• FIREBASE_CONFIG: (बिल्ड और रनटाइम एनवायरमेंट में उपलब्ध है) यह Firebase प्रोजेक्ट के कॉन्फ़िगरेशन की यह जानकारी देता है:

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

  बिना किसी आर्ग्युमेंट के Firebase Admin SDK को शुरू करने पर, यह कॉन्फ़िगरेशन अपने-आप लागू हो जाता है.

• FIREBASE_WEBAPP_CONFIG: (सिर्फ़ बिल्ड एनवायरमेंट में उपलब्ध है) यह 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',
  }
  

  Firebase JS SDK टूल, बिल्ड के दौरान postinstall script में इस FIREBASE_WEBAPP_CONFIGएनवायरमेंट वैरिएबल की जांच अपने-आप करता है. इससे, आपको बिना किसी तर्क के क्लाइंट SDK टूल को शुरू करने की अनुमति मिलती है.

SDK टूल को शुरू करने के लिए, इन एनवायरमेंट वैरिएबल का इस्तेमाल करने के तरीके के बारे में ज़्यादा जानने के लिए, Firebase Admin SDK और वेब SDK टूल को अपने-आप शुरू होने की सुविधा चालू करना लेख पढ़ें.

ध्यान दें कि आपके Firebase कॉन्फ़िगरेशन में मौजूद वैल्यू, आपके प्रोजेक्ट में उपलब्ध कराए गए संसाधनों के हिसाब से होंगी.

वैरिएबल हैरारकी

Firebase ऐप्लिकेशन होस्टिंग, आपके वैरिएबल को प्राथमिकता के क्रम में लागू करती है. यह क्रम, उनके सोर्स के आधार पर तय होता है. उदाहरण के लिए, कंसोल में सेट की गई वैल्यू हमेशा apphosting.yaml और dotenv फ़ाइलों में सेट की गई वैल्यू को बदल देती हैं या उन पर प्राथमिकता लेती हैं.

यहां प्राथमिकता का पूरा क्रम दिया गया है:

1. Firebase कंसोल → कंसोल में सेट किए गए वैरिएबल
2. apphosting.<env>.yaml → एनवायरमेंट के हिसाब से तय की गई YAML फ़ाइल में दिए गए वैरिएबल, जैसे कि apphosting.staging.yaml (एक से ज़्यादा एनवायरमेंट डिप्लॉय करना देखें)
3. apphosting.yaml → apphosting.yaml फ़ाइल में तय किए गए वैरिएबल
4. Firebase सिस्टम → Firebase की ओर से सेट किए गए ऐसे वैरिएबल जिनमें firebase_config json या firebase_webapp_config के साथ-साथ एनवायरमेंट वैरिएबल की वैल्यू भी शामिल होती हैं. ये एनवायरमेंट वैरिएबल, एसएसआर ऐप्लिकेशन के लिए होस्टनेम और पोर्ट सेट करते हैं. इन्हें bundle.yaml में App Hosting अडैप्टर सेट करते हैं

रिज़र्व किए गए नाम और सीमाएं

Cloud Run कंटेनर रनटाइम अनुबंध में तय किए गए एनवायरमेंट वैरिएबल रिज़र्व होते हैं और उन्हें सेट नहीं किया जा सकता.

एनवायरमेंट वैरिएबल, एनवायरमेंट के हिसाब से तय होते हैं. अपने-आप सेट होने वाले वैरिएबल के अलावा, अन्य वैरिएबल के रनटाइम वर्शन में आने वाले समय में बदलाव हो सकता है. हमारा सुझाव है कि आप ऐसे एनवायरमेंट वैरिएबल पर भरोसा न करें या उनमें बदलाव न करें जिन्हें आपने साफ़ तौर पर सेट नहीं किया है. साथ ही, टकराव से बचने के लिए, किसी भी एनवायरमेंट वैरिएबल को यूनीक कुंजी के साथ प्रीफ़िक्स करें.

कुछ एनवायरमेंट वैरिएबल कुंजियां, अंदरूनी इस्तेमाल के लिए रिज़र्व की जाती हैं. अपनी कॉन्फ़िगरेशन फ़ाइलों में इनमें से किसी भी कुंजी का इस्तेमाल न करें:

• खाली स्ट्रिंग ("")
• ऐसी कुंजियां जिनमें "=" शामिल है
• X_FIREBASE_, X_GOOGLE_ या CLOUD_RUN_ से शुरू होने वाली कुंजियां
• PORT
• K_SERVICE
• K_REVISION
• K_CONFIGURATION
• डुप्लीकेट कुंजियां

apphosting.yaml बनाना और उसमें बदलाव करना

सीक्रेट या रनटाइम सेटिंग जैसे कि एक साथ कई अनुरोध प्रोसेस करने की सुविधा, सीपीयू, और मेमोरी की सीमाएं जैसी बेहतर कॉन्फ़िगरेशन के लिए, आपको अपने ऐप्लिकेशन की रूट डायरेक्ट्री में apphosting.yaml फ़ाइल बनानी होगी और उसमें बदलाव करना होगा. इस फ़ाइल में, Cloud Secret Manager की मदद से मैनेज किए गए सीक्रेट के रेफ़रंस इस्तेमाल किए जा सकते हैं. इसलिए, इसे सोर्स कंट्रोल में सुरक्षित तरीके से चेक इन किया जा सकता है.

apphosting.yaml बनाने के लिए, यह कमांड चलाएं:

firebase init apphosting

इससे एक बुनियादी स्टार्टर apphosting.yaml फ़ाइल बन जाती है. इसमें कॉन्फ़िगरेशन का उदाहरण (टिप्पणी किया गया) दिया गया होता है. बदलाव करने के बाद, सामान्य apphosting.yaml फ़ाइल कुछ इस तरह दिख सकती है. इसमें बैकएंड की Cloud Run सेवा के लिए सेटिंग, कुछ एनवायरमेंट वैरिएबल, और 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

इस गाइड के बाकी हिस्से में, इन उदाहरण सेटिंग के बारे में ज़्यादा जानकारी और कॉन्टेक्स्ट दिया गया है.

Cloud Run सेवा की सेटिंग कॉन्फ़िगर करना

apphosting.yaml की सेटिंग की मदद से, यह कॉन्फ़िगर किया जा सकता है कि Cloud Run की सेवा कैसे उपलब्ध कराई जाए. Cloud Run सेवा के लिए उपलब्ध सेटिंग, runConfig ऑब्जेक्ट में दी गई हैं:

• cpu – हर सर्विंग इंस्टेंस के लिए इस्तेमाल किए गए सीपीयू की संख्या (डिफ़ॉल्ट रूप से 0).
• memoryMiB – हर सर्विंग इंस्टेंस के लिए मेमोरी की तय की गई रकम, MiB में (डिफ़ॉल्ट रूप से 512)
• maxInstances – एक बार में ज़्यादा से ज़्यादा कंटेनर चलाने की संख्या (डिफ़ॉल्ट रूप से 100 और कोटा के हिसाब से मैनेज किया जाता है)
• minInstances – हमेशा चालू रहने वाले कंटेनर की संख्या (डिफ़ॉल्ट रूप से 0).
• concurrency – हर अनुरोध भेजने वाले इंस्टेंस को ज़्यादा से ज़्यादा इतने अनुरोध मिल सकते हैं (डिफ़ॉल्ट रूप से 80).

cpu और memoryMiB के बीच मौजूद अहम संबंध के बारे में जानें. मेमोरी को 128 से 32768 के बीच की किसी भी पूर्णांक वैल्यू पर सेट किया जा सकता है. हालांकि, मेमोरी की सीमा बढ़ाने के लिए, सीपीयू की सीमाएं बढ़ानी पड़ सकती हैं:

• 4 जीबी से ज़्यादा मेमोरी के लिए, कम से कम दो सीपीयू ज़रूरी हैं
• 8 जीबी से ज़्यादा रैम के लिए, कम से कम 4 सीपीयू ज़रूरी हैं
• 16 जीबी से ज़्यादा के लिए, कम से कम 6 सीपीयू ज़रूरी हैं
• 24 जीबी से ज़्यादा के लिए, कम से कम आठ सीपीयू ज़रूरी हैं

इसी तरह, cpu एट्रिब्यूट की वैल्यू से, एक साथ कई अनुरोध प्रोसेस करने की सेटिंग पर असर पड़ता है. अगर आपने सीपीयू की वैल्यू 1 से कम पर सेट की है, तो आपको कॉंक्यूरेंसी को 1 पर सेट करना होगा. साथ ही, सीपीयू सिर्फ़ अनुरोध प्रोसेस करने के दौरान असाइन किया जाएगा.

बिल्ड और रन स्क्रिप्ट को बदलें

App Hosting, पता लगाए गए फ़्रेमवर्क के आधार पर, आपके ऐप्लिकेशन के बिल्ड और स्टार्ट कमांड का अनुमान लगाता है. अगर आपको कस्टम बिल्ड या स्टार्ट कमांड का इस्तेमाल करना है, तो apphosting.yaml में App Hosting के डिफ़ॉल्ट को बदला जा सकता है.

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

बिल्ड कमांड को बदलने वाली कमांड को अन्य सभी बिल्ड कमांड के मुकाबले प्राथमिकता दी जाती है. साथ ही, यह आपके ऐप्लिकेशन को फ़्रेमवर्क अडैप्टर से ऑप्ट आउट कर देती है. इसके अलावा, यह फ़्रेमवर्क से जुड़े उन सभी ऑप्टिमाइज़ेशन को बंद कर देती है जिन्हें App Hosting उपलब्ध कराता है. इसका इस्तेमाल तब सबसे सही होता है, जब आपके ऐप्लिकेशन की सुविधाओं के लिए अडैप्टर ठीक से काम नहीं कर रहे हों. अगर आपको अपनी बिल्ड कमांड बदलनी है, लेकिन हमारे दिए गए अडैप्टर का इस्तेमाल जारी रखना है, तो package.json में अपनी बिल्ड स्क्रिप्ट सेट करें. इसके लिए, App Hosting फ़्रेमवर्क अडैप्टर में दिए गए निर्देशों का पालन करें.

अगर आपको ऐप्लिकेशन शुरू करने के लिए, App Hosting-इनफ़र्ड कमांड से अलग कोई खास कमांड इस्तेमाल करनी है, तो रन कमांड ओवरराइड का इस्तेमाल करें.

बिल्ड आउटपुट कॉन्फ़िगर करना

App Hosting, आपके ऐप्लिकेशन को डिप्लॉय करने की प्रोसेस को डिफ़ॉल्ट रूप से ऑप्टिमाइज़ करता है. इसके लिए, वह फ़्रेमवर्क के हिसाब से इस्तेमाल न होने वाली आउटपुट फ़ाइलों को मिटा देता है. अगर आपको अपने ऐप्लिकेशन के डिप्लॉयमेंट साइज़ को और ऑप्टिमाइज़ करना है या डिफ़ॉल्ट ऑप्टिमाइज़ेशन को अनदेखा करना है, तो apphosting.yaml में जाकर इसे बदला जा सकता है.

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

include पैरामीटर, ऐप्लिकेशन की रूट डायरेक्ट्री से जुड़ी डायरेक्ट्री और फ़ाइलों की सूची लेता है. ये फ़ाइलें, ऐप्लिकेशन को डिप्लॉय करने के लिए ज़रूरी होती हैं. अगर आपको यह पक्का करना है कि सभी फ़ाइलें सेव रहें, तो include को [.] पर सेट करें. इससे सभी फ़ाइलें डिप्लॉय हो जाएंगी.

सीक्रेट पैरामीटर सेव करना और उन्हें ऐक्सेस करना

एपीआई कुंजियों जैसी संवेदनशील जानकारी को सीक्रेट के तौर पर सेव किया जाना चाहिए. संवेदनशील जानकारी को सोर्स कंट्रोल में सेव करने से बचने के लिए, apphosting.yaml में सीक्रेट का रेफ़रंस दिया जा सकता है.

secret टाइप के पैरामीटर, स्ट्रिंग पैरामीटर होते हैं. इनकी वैल्यू Cloud Secret Manager में सेव होती है. सीधे तौर पर वैल्यू पाने के बजाय, सीक्रेट पैरामीटर यह देखते हैं कि Cloud Secret Manager में कोई सीक्रेट मौजूद है या नहीं. साथ ही, रोलआउट के दौरान वैल्यू लोड करते हैं.

  -   variable: API_KEY
      secret: myApiKeySecret

Cloud Secret Manager में मौजूद सीक्रेट के कई वर्शन हो सकते हैं. डिफ़ॉल्ट रूप से, आपके लाइव बैकएंड के लिए उपलब्ध सीक्रेट पैरामीटर की वैल्यू, बैकएंड बनाते समय सीक्रेट के उपलब्ध सबसे नए वर्शन पर पिन की जाती है. अगर आपको पैरामीटर के वर्शन और लाइफ़साइकल मैनेजमेंट से जुड़ी ज़रूरतें पूरी करनी हैं, तो Cloud Secret Manager की मदद से, उन्हें किसी खास वर्शन पर पिन किया जा सकता है. उदाहरण के लिए, वर्शन 5 पर पिन करने के लिए:

  - variable: PINNED_API_KEY
    secret: myApiKeySecret@5

सीएलआई कमांड firebase apphosting:secrets:set का इस्तेमाल करके सीक्रेट बनाए जा सकते हैं. इसके बाद, आपको ज़रूरी अनुमतियां जोड़ने के लिए कहा जाएगा. इस फ़्लो में, apphosting.yaml में सीक्रेट रेफ़रंस अपने-आप जोड़ने का विकल्प मिलता है.

Cloud Secret Manager की सभी सुविधाओं का इस्तेमाल करने के लिए, Cloud Secret Manager कंसोल का इस्तेमाल करें. ऐसा करने पर, आपको सीएलआई कमांड firebase apphosting:secrets:grantaccess का इस्तेमाल करके, अपने App Hosting बैकएंड को अनुमतियां देनी होंगी.

VPC ऐक्सेस कॉन्फ़िगर करना

आपका App Hosting बैकएंड, वर्चुअल प्राइवेट क्लाउड (VPC) नेटवर्क से कनेक्ट हो सकता है. ज़्यादा जानकारी और उदाहरण के लिए, Firebase App Hosting को वीपीसी नेटवर्क से कनेक्ट करना लेख पढ़ें.

ऐक्सेस कॉन्फ़िगर करने के लिए, अपनी apphosting.yaml फ़ाइल में vpcAccess मैपिंग का इस्तेमाल करें. पूरी तरह से क्वालिफ़ाइड नेटवर्क/कनेक्टर का नाम या आईडी इस्तेमाल करें. आईडी का इस्तेमाल करने से, अलग-अलग कनेक्टर/नेटवर्क के साथ, स्टेजिंग और प्रोडक्शन एनवायरमेंट के बीच पोर्टेबिलिटी की अनुमति मिलती है.

वीपीसी से सीधे बाहर निकलने के लिए कॉन्फ़िगरेशन (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

सर्वरलेस कनेक्टर का कॉन्फ़िगरेशन (apphosting.yaml):

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

बैकएंड मैनेज करना

App Hosting बैकएंड को बुनियादी तौर पर मैनेज करने के लिए कमांड, Firebase CLI और Firebase कंसोल में दी गई हैं. इस सेक्शन में, मैनेजमेंट से जुड़े कुछ सामान्य कामों के बारे में बताया गया है. जैसे, बैकएंड बनाना और मिटाना.

बैकएंड बनाना

App Hosting बैकएंड, मैनेज किए गए संसाधनों का कलेक्शन होता है. App Hosting इसका इस्तेमाल, आपके वेब ऐप्लिकेशन को बनाने और चलाने के लिए करता है.

Firebase कंसोल: Build मेन्यू में जाकर, App Hosting और फिर Create backend चुनें. अगर यह आपके Firebase प्रोजेक्ट का पहला बैकएंड है, तो Get started चुनें.

सीएलआई: (वर्शन 13.15.4 या इसके बाद का वर्शन) बैकएंड बनाने के लिए, अपनी लोकल प्रोजेक्ट डायरेक्ट्री के रूट से यह निर्देश चलाएं. साथ ही, अपने projectID को आर्ग्युमेंट के तौर पर दें:

firebase apphosting:backends:create --project PROJECT_ID

कंसोल या सीएलआई, दोनों के लिए दिए गए निर्देशों का पालन करके, रीजन चुनें, GitHub कनेक्शन सेट अप करें, और डिप्लॉयमेंट की इन बुनियादी सेटिंग को कॉन्फ़िगर करें:

• अपने ऐप्लिकेशन की रूट डायरेक्ट्री सेट करें (डिफ़ॉल्ट रूप से / पर सेट होती है)

  आम तौर पर, आपकी package.json फ़ाइल यहीं मौजूद होती है.

• लाइव ब्रांच सेट करना

  यह आपकी GitHub रिपॉज़िटरी की वह ब्रांच है जिसे आपके लाइव यूआरएल पर डिप्लॉय किया जाता है. अक्सर, यह वह ब्रांच होती है जिसमें फ़ीचर ब्रांच या डेवलपमेंट ब्रांच को मर्ज किया जाता है.

• अपने-आप रोल आउट होने की सुविधा को स्वीकार या अस्वीकार करना

  अपने-आप रोल आउट होने की सुविधा डिफ़ॉल्ट रूप से चालू होती है. बैकएंड बनाने की प्रोसेस पूरी होने के बाद, आपके पास अपने ऐप्लिकेशन को App Hosting पर तुरंत डिप्लॉय करने का विकल्प होता है.

• अपने बैकएंड को कोई नाम असाइन करें.

बैकएंड मिटाना

किसी बैकएंड को पूरी तरह से हटाने के लिए, पहले Firebase CLI या Firebase कंसोल का इस्तेमाल करके उसे मिटाएं. इसके बाद, उससे जुड़ी ऐसेट को मैन्युअल तरीके से हटाएं. इस दौरान, यह ध्यान रखें कि कोई भी ऐसा संसाधन न मिटाएं जिसका इस्तेमाल अन्य बैकएंड या आपके Firebase प्रोजेक्ट के अन्य पहलुओं में किया जा सकता है.

Firebase console: सेटिंग मेन्यू में जाकर, बैकएंड मिटाएं को चुनें.

सीएलआई: (वर्शन 13.15.4 या इसके बाद का वर्शन)

1. App Hosting बैकएंड को मिटाने के लिए, यह कमांड चलाएं. इससे आपके बैकएंड के लिए सभी डोमेन बंद हो जाते हैं और इससे जुड़ी Cloud Run सेवा मिट जाती है:

   firebase apphosting:backends:delete BACKEND_ID --project PROJECT_ID
   

2. (ज़रूरी नहीं) Artifact Registry के लिए Google Cloud Console टैब में, "firebaseapphosting-images" में जाकर अपने बैकएंड की इमेज मिटाएं.

3. Cloud Secret Manager में, "apphosting" नाम वाले सभी सीक्रेट मिटाएं. खास तौर पर, यह पक्का करें कि इन सीक्रेट का इस्तेमाल अन्य बैकएंड या आपके Firebase प्रोजेक्ट के अन्य पहलुओं के लिए न किया जाए.