रिमोट कॉन्फ़िगरेशन के लिए कीमत
संग्रह की मदद से व्यवस्थित रहें
अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.
Remote Config 1 सितंबर, 2026 से, कीमत का एक ऐसा फ़्लेक्सिबल स्ट्रक्चर उपलब्ध कराएगा जो हर साइज़ के प्रोजेक्ट के लिए बनाया गया है. इसमें बिना किसी शुल्क वाला प्लान और रोज़ाना के इस्तेमाल के हिसाब से पैसे चुकाने वाला टियर, दोनों शामिल होंगे.
सिर्फ़ Remote Config सेवा से सीधे तौर पर किए गए फ़ेच अनुरोधों (क्लाइंट SDK टूल या REST API के ज़रिए) को बिल किए गए इस्तेमाल में शामिल किया जाता है. डेटा फ़ेच करने के ऑपरेशन, नेटवर्क कॉल या Firebase की अन्य सेवाओं से जनरेट होने वाली मेट्रिक, आपके Remote Config के कोटे या बिलिंग में शामिल नहीं होती हैं.
इस टेबल में, स्पार्क और ब्लेज़ प्लान, दोनों के लिए हर प्रोजेक्ट के इस्तेमाल की जानकारी दी गई है:
जानकारी
बिना शुल्क वाला (स्पार्क प्लान)
इस्तेमाल के हिसाब से पैसे चुकाएं (Blaze प्लान)
डेटा फ़ेच करने के अनुरोध
हर दिन ज़्यादा से ज़्यादा 1,00,000
हर दिन 1,00,000 तक बिना किसी शुल्क के.
इसके बाद:
हर दिन 1,00,001 से 1,00,00,000 अनुरोधों के लिए, हर अनुरोध पर 0.000006 डॉलर (10 हज़ार अनुरोधों के लिए 0.06 डॉलर) का शुल्क लिया जाता है.
हर दिन 1 करोड़ से ज़्यादा बार इस्तेमाल करने पर, हर अनुरोध के लिए 0.000001 डॉलर (10 हज़ार अनुरोधों के लिए 0.01 डॉलर) शुल्क लिया जाता है.
सभी सुविधाएं
इसमें मनमुताबिक बनाने की सुविधा, रोलआउट, और A/B टेस्टिंग इंटिग्रेशन शामिल है
इसमें मनमुताबिक बनाने की सुविधा, रोलआउट, और A/B टेस्टिंग इंटिग्रेशन शामिल है
मौजूदा प्रोजेक्ट के लिए ट्रांज़िशन का ग्रेस पीरियड
यह ट्रांज़िशन ग्रेस पीरियड उन प्रोजेक्ट के लिए है जिनमें Remote Config1 सितंबर, 2026 से पहले यह सुविधा चालू की गई है. पे-ऐज़-यू-गो की कीमत पर आसानी से स्विच करने के लिए, मौजूदा प्रोजेक्ट को बिलिंग लागू होने से पहले, ग्रेस पीरियड (कुछ समय के लिए बिना शुल्क के इस्तेमाल करने की अवधि) दिया जाता है. यह ग्रेस पीरियड इस तरह से तय किया जाता है:
मौजूदा बिलिंग प्लान
ट्रांज़िशन के लिए मोहलत
स्टैंडर्ड बिलिंग की शुरुआत
ज़रूरी कार्रवाई / नोट
स्पार्क प्लान(बिना किसी शुल्क के)
तीन महीने
1 दिसंबर, 2026
सुझाई गई कार्रवाई:Cloud Billing सेट अप करें और Blaze प्लान पर अपग्रेड करें.
बोनस: अगर आपने 15 नवंबर, 2026 से पहले अपग्रेड किया, तो आपको पांच महीने का ग्रेस पीरियड मिलेगा. बिलिंग 1 फ़रवरी, 2027 से शुरू होगी.
ब्लेज़ प्लान(जितना इस्तेमाल करें उतना ही चुकाएं)
पांच महीने
1 फ़रवरी, 2027
आपको कुछ करने की ज़रूरत नहीं है. प्रोजेक्ट 1 फ़रवरी, 2027 को स्टैंडर्ड कीमत पर अपने-आप स्विच हो जाएंगे.
स्टैंडर्ड ग्रेस पीरियड
यह ग्रेस पीरियड उन प्रोजेक्ट के लिए है जिन्होंने Remote Config को 1 सितंबर, 2026 को या इसके बाद चालू किया है. इसमें Remote Config
चालू किए गए मौजूदा प्रोजेक्ट (1 सितंबर, 2026 से पहले बनाए गए) भी शामिल हैं. इन प्रोजेक्ट के लिए, ट्रांज़िशन का ग्रेस पीरियड खत्म हो गया है. अगर किसी प्रोजेक्ट में हर दिन फ़ेच करने के 1,00,000 से ज़्यादा अनुरोध किए जाते हैं, तो आपको ये काम करने होंगे:
प्लान / शर्त
ग्रेस पीरियड
ग्रेस पीरियड के बाद क्या होगा
ज़रूरी कार्रवाई / नोट
स्पार्क प्लान(बिना किसी शुल्क के)
30 दिन(यह तब लागू होता है, जब प्रोजेक्ट पहली बार रोज़ाना इस्तेमाल की समयसीमा से ज़्यादा हो जाता है)
31वें दिन से थ्रॉटलिंग शुरू हो जाती है
रोज़ाना इस्तेमाल की सीमा पहली बार पार होने के बाद, प्रोजेक्ट को 30 दिनों तक बिना किसी रुकावट के इस्तेमाल किया जा सकता है. 31वें दिन या उसके बाद थ्रॉटलिंग से बचने के लिए, आपको Blaze प्लान पर अपग्रेड करना होगा.
ब्लेज़ प्लान(जितना इस्तेमाल करें उतना ही चुकाएं)
लागू नहीं (कोई थ्रॉटलिंग नहीं)
डेटा फ़ेच करने के हर अनुरोध के लिए बिलिंग
1,00,000 से ज़्यादा फ़ेच के लिए शुल्क लिया जाता है. कोई थ्रॉटलिंग लागू नहीं की गई है.
इस्तेमाल को ऑप्टिमाइज़ करने के सबसे सही तरीके
इस्तेमाल को ऑप्टिमाइज़ करने के लिए, इनमें से कोई भी काम करें:
क्लाइंट फ़ेच करने के इंटरवल: प्रोडक्शन बिल्ड में, फ़ेच करने के इंटरवल को बहुत कम (उदाहरण के लिए, setMinimumFetchIntervalInSeconds) पर सेट करने से बचें. डिफ़ॉल्ट रूप से, सुझाया गया इंटरवल 12 घंटे का होता है.
ज़रूरी नहीं पैरामीटर के लिए कैश मेमोरी: कॉन्फ़िगरेशन की ऐसी वैल्यू जो स्थिर हैं और जिनमें कभी-कभार ही बदलाव होता है उनके लिए, setMinimumFetchIntervalInSeconds को डिफ़ॉल्ट 12 घंटे से बढ़ाकर 24 या 48 घंटे करें.
ऐप्लिकेशन स्टार्टअप फ़ेच लूप: पक्का करें कि आपका ऐप्लिकेशन, हर स्क्रीन ट्रांज़िशन, गतिविधि फिर से शुरू होने या कॉम्पोनेंट रेंडर होने पर रिमोट फ़ेच को ट्रिगर न करे. लोड होने पर फ़ेच और चालू करें या लोडिंग स्क्रीन के पीछे चालू करें जैसी लोडिंग रणनीतियों का ज़िम्मेदारी से इस्तेमाल करें.
बैकग्राउंड और इनऐक्टिव फ़ेच की ऑडिट करना: बैकग्राउंड वर्कर जॉब, सेवाओं या लेगसी ऐप्लिकेशन मॉड्यूल की समीक्षा करें, ताकि फ़ेच कॉल ("घोस्ट फ़ेच") को हटाया जा सके. ये कॉल तब ट्रिगर होते हैं, जब ऐप्लिकेशन बैकग्राउंड में या इनऐक्टिव होता है.
मॉनिटर करना: Google Cloud कंसोल और Firebase कंसोल के कीमत और इस्तेमाल से जुड़े डैशबोर्ड का इस्तेमाल करें. इससे, हर दिन फ़ेच किए जाने वाले डेटा की मात्रा 1,00,000 अनुरोधों के आस-पास पहुंचने पर, बिलिंग से जुड़ी सूचनाएं अपने-आप सेट अप हो जाएंगी.
अक्सर पूछे जाने वाले सवाल और समस्या हल करने से जुड़ी जानकारी
Remote Config का नया शुल्क क्या है, जो 1 सितंबर, 2026 से लागू होगा?
Remote Config, इस्तेमाल के मुताबिक कीमत तय करने वाले स्ट्रक्चर पर स्विच कर रहा है. इसमें बिना शुल्क वाला टियर भी शामिल है:
स्पार्क (बिना किसी शुल्क वाला) प्लान: बिना किसी शुल्क के, हर दिन ज़्यादा से ज़्यादा 1,00,000 फ़ेच अनुरोध किए जा सकते हैं.
ब्लेज़ (इस्तेमाल के हिसाब से पैसे चुकाएं) प्लान: हर दिन फ़ेच करने के लिए की गई पहली 1,00, 000 अनुरोधों के लिए कोई शुल्क नहीं लिया जाता. इसके बाद:
हर दिन 1,00,001 से लेकर 1,00,00,000 अनुरोधों के लिए, हर 10,000 अनुरोधों पर 0.06 डॉलर (0.000006 डॉलर/अनुरोध) का शुल्क लिया जाता है.
हर दिन 1 करोड़ से ज़्यादा अनुरोध होने पर, हर 10,000 अनुरोध के लिए 0.01 डॉलर (0.000001 डॉलर/अनुरोध) शुल्क लिया जाता है.
सुविधाएं: सभी ऐडवांस सुविधाएं (उपयोगकर्ता की ज़रूरत के मुताबिक बनाना, रोलआउट, और A/B टेस्टिंग इंटिग्रेशन) Spark और Blaze, दोनों प्लान में शामिल हैं. इसके लिए, कोई अतिरिक्त शुल्क नहीं देना होगा.
क्या मुझे Remote Config का इस्तेमाल शुरू करने के लिए, बिलिंग खाते की ज़रूरत है?
नहीं. Remote Config का इस्तेमाल शुरू करने के लिए, आपको बिलिंग खाते की ज़रूरत नहीं है. बिना किसी शुल्क के, Spark प्लान का इस्तेमाल शुरू किया जा सकता है. बिलिंग खाते की ज़रूरत सिर्फ़ तब होती है, जब आपको अपने प्रोजेक्ट को Blaze प्लान में अपग्रेड करना हो. ऐसा तब किया जाता है, जब आपको हर दिन एक लाख से ज़्यादा फ़ेच अनुरोधों को पूरा करना हो.
क्या मुझे अपने कोड को अपडेट करना होगा या रिमोट कॉन्फ़िगरेशन SDK को अपग्रेड करना होगा?
नहीं. Spark और Blaze प्लान के बीच ट्रांज़िशन करते समय, आपको अपने कोड में बदलाव करने या Remote Config क्लाइंट SDK टूल को अपडेट करने की ज़रूरत नहीं है. टियर ट्रांज़िशन और अनुरोध मीटरिंग को Remote Config बैकएंड अपने-आप मैनेज करता है.
बिल किए जाने वाले फ़ेच अनुरोध की ज़रूरी शर्तें क्या हैं?
फ़ेच करने का अनुरोध तब होता है, जब आपका क्लाइंट ऐप्लिकेशन या बैकएंड सर्वर, अपडेट की गई पैरामीटर वैल्यू की जांच करने के लिए Remote Config सर्वर को कॉल करता है. उदाहरण के लिए, क्लाइंट एसडीके में fetch() या fetchAndActivate() को चालू करना या REST/Admin SDK का इस्तेमाल करके टेंप्लेट वापस पाना. सिर्फ़ Remote Config सेवा (क्लाइंट SDK टूल या REST API के ज़रिए) से सीधे तौर पर किए गए फ़ेच अनुरोधों को बिल किए गए इस्तेमाल में शामिल किया जाता है. फ़ेच ऑपरेशन, नेटवर्क कॉल या अन्य Firebase सेवाओं से जनरेट की गई मेट्रिक, आपके Remote Config के कोटे या बिलिंग में शामिल नहीं की जाती हैं.
रीयलटाइम Remote Config: रीयलटाइम कनेक्शन खोलने से, लगातार फ़ेच करने के अलग-अलग अनुरोध जनरेट नहीं होते. हालांकि, जब सर्वर अमान्य होने की सूचना भेजता है, तो अपडेट किए गए कॉन्फ़िगरेशन को डाउनलोड करने के लिए क्लाइंट का कॉल, फ़ेच करने के अनुरोध के तौर पर गिना जाता है.
कैश की गई वैल्यू: डिवाइस पर पहले से सेव की गई कैश की गई वैल्यू का इस्तेमाल करने पर, नेटवर्क कॉल जनरेट नहीं होता. साथ ही, इसे फ़ेच करने का अनुरोध नहीं माना जाता. इसके लिए, activate() या getString() का इस्तेमाल करके, डिस्क/मेमोरी से डेटा पढ़ा जाता है.
अगर मेरा प्रोजेक्ट Spark प्लान पर है और हर दिन फ़ेच किए जाने वाले अनुरोधों की संख्या 1,00,000 से ज़्यादा हो जाती है, तो क्या होगा? मैं अपग्रेड कैसे करूं?
30 दिनों का ग्रेस पीरियड: जब आपका Spark प्रोजेक्ट पहली बार, हर दिन के फ़ेच अनुरोधों की संख्या 1,00,000 से ज़्यादा हो जाती है, तो Firebase आपको 30 दिनों का ग्रेस पीरियड देता है. इस दौरान, आपके Remote Config अनुरोधों को बिना किसी रुकावट के पूरा किया जाता रहेगा.
काउंटडाउन जारी रहना: 30 दिनों का ग्रेस पीरियड तब शुरू होता है, जब आपका प्रोजेक्ट पहली बार हर दिन 1,00,000 फ़ेच अनुरोधों से ज़्यादा हो जाता है. 30 दिनों की यह उलटी गिनती न तो रुकती है और न ही रीसेट होती है. भले ही, इस समयावधि के दौरान रोज़ाना के इस्तेमाल की सीमा, 1,00,000 अनुरोधों की सीमा से कुछ समय के लिए कम हो जाए.
कोटा की सूचनाएं: हर दिन फ़ेच किए जाने वाले डेटा का वॉल्यूम 1,00,000 के कोटे के आस-पास पहुंचने और उसके बराबर होने पर, प्रोजेक्ट एडमिन को ईमेल से सूचनाएं मिलती हैं. साथ ही, उन्हें कंसोल बैनर की सूचनाएं भी मिलती हैं.
थ्रॉटलिंग का जोखिम: अगर आपने 30 दिनों की ग्रेस अवधि के खत्म होने तक Blaze प्लान पर अपग्रेड नहीं किया, तो Remote Config सेवा थ्रॉटलिंग शुरू हो जाएगी. यह उन अनुरोधों के लिए होगी जो रोज़ाना की 1,00, 000 की सीमा से ज़्यादा हैं. इससे क्लाइंट को अपडेट किए गए कॉन्फ़िगरेशन नहीं मिल पाएंगे.
अपग्रेड करने का तरीका: बिना किसी रुकावट के सेवा का इस्तेमाल जारी रखने के लिए, Firebase कंसोल में जाकर Blaze प्लान पर अपग्रेड करें. Blaze प्लान पर अपग्रेड करने से, आपका प्रोजेक्ट Google Cloud Billing खाते से लिंक हो जाता है.
उपयोगकर्ताओं को Remote Config पैरामीटर की नई वैल्यू नहीं मिल रही हैं. क्या यह समस्या, कीमत या कोटे से जुड़ी है?
हां. अगर आपका प्रोजेक्ट Spark प्लान पर है, हर दिन के लिए अनुरोधों की सीमा 1,00,000 से ज़्यादा हो गई है, और 30 दिनों का ग्रेस पीरियड खत्म हो गया है, तो हर दिन की सीमा से ज़्यादा के अनुरोधों को सर्वर थ्रॉटल कर देता है. Firebase कंसोल में जाकर, इस्तेमाल से जुड़ी मेट्रिक देखें. अगर हर दिन के सक्रिय उपयोगकर्ताओं को हर दिन 1,00,000 से ज़्यादा फ़ेच की ज़रूरत है, तो Blaze प्लान पर अपग्रेड करें.
मैं अपने मौजूदा इस्तेमाल को कैसे देखूं, ताकि बिल का अनुमान लगाया जा सके?
अगर आपने Blaze प्लान लिया है, तो Google Cloud कंसोल में जाकर, लागत को मैनेज करने और इस्तेमाल से जुड़ी रिपोर्ट देखी जा सकती हैं. ज़्यादा जानकारी के लिए, अपनी क्लाउड बिलिंग रिपोर्ट और लागत के रुझान देखना लेख पढ़ें.
एसकेयू के हिसाब से फ़िल्टर करते समय, यह एसकेयू चुनें:
SKU आईडी: 37B1-4623-6F54
SKU का नाम: अनुरोधों को फ़ेच करना
Google Cloud कंसोल में, कोटा और सिस्टम की सीमाएं पेज पर जाकर, मौजूदा इस्तेमाल और सिस्टम की चालू सीमाओं पर नज़र रखी जा सकती है. ज़्यादा जानकारी के लिए, कोटा देखना और मैनेज करना लेख पढ़ें. रिपोर्ट फ़िल्टर करते समय, पक्का करें कि आपने वह Firebase API चुना हो जिसके लिए आपको कोटे की जांच करनी है (उदाहरण के लिए, firebaseremoteconfig.googleapis.com).