Firexport / Blog

Seit dem 1. September 2026 richtet sich der Preis von Firebase Remote Config danach, wie oft Apps ihre Konfiguration abrufen. Die ersten 100.000 Fetches pro Tag sind in jedem Tarif kostenlos. Darüber zahlen Blaze-Projekte pro Fetch, und Spark-Projekte werden irgendwann gedrosselt. Die meisten Apps bleiben unter der Grenze. Ob Ihre dazugehört, hängt weniger davon ab, wie viele Nutzer Sie haben, als von einer Einstellung in Ihrem Code: dem minimalen Fetch-Intervall.

Die Preise

• Die 100.000 gelten pro Projekt. Eine Android-App, eine iOS-App und eine Website im selben Projekt teilen sie sich.
• Sie gelten pro Tag, und ein ruhiger Tag gleicht einen vollen nicht aus. Ein Launch-Tag mit einer Million Fetches kostet 5,40 $, auch wenn der Rest des Monats unter 100.000 bleibt.
• Weder Ihr Code noch Ihre SDK-Version muss sich ändern. Firebase zählt die Fetches auf seiner Seite, in beiden Tarifen.

Wann die neuen Preise für Ihr Projekt gelten

Projekte, die Remote Config vor dem 1. September 2026 aktiviert haben, bekommen zuerst eine Übergangsfrist. Welche, hängt vom Tarif des Projekts ab:

Die Preisseite sagt nicht, was mit einem Spark-Projekt geschieht, das zwischen dem 15. November und dem 1. Dezember auf Blaze umgestellt wird. Wenn Sie das vorhaben, rechnen Sie mit einer Abrechnung ab dem 1. Dezember.

Sollten Sie vor dem 15. November auf Blaze umstellen?

• Wenn Ihr Projekt weniger als 100.000 Fetches pro Tag macht, nein. Spark funktioniert weiter wie bisher, Blaze ebenso.
• Wenn es mehr macht oder nah dran ist, verschafft Ihnen ein Upgrade vor dem 15. November zwei Monate, Dezember und Januar, um die Fetches zu senken, bevor etwas abgerechnet wird. Die Alternative mit Spark ist die Drosselung, und die ist für die meisten Apps schlimmer als ein paar Dollar.
• Blaze verknüpft das Projekt mit einem Cloud-Billing-Konto und hat keine Ausgabenobergrenze. Andere Produkte behalten ihre kostenlose Nutzung, und Sie zahlen nur, was darüber hinausgeht. Richten Sie beim Upgrade eine Budgetbenachrichtigung ein (siehe unten).

Was Drosselung bei Spark bedeutet

Der erste Tag, an dem ein Spark-Projekt 100.000 Fetches überschreitet, startet eine Kulanzfrist von 30 Tagen, in der jeder Fetch noch bedient wird. Der Countdown pausiert nicht und beginnt nicht von vorn, wenn die Nutzung zwischendurch wieder unter die Grenze fällt. Ab Tag 31 werden alle Fetches nach dem 100.000. eines Tages abgelehnt. Die App läuft weiter, aber ein Gerät, dessen Fetch abgelehnt wird, bleibt bei den Werten, die es schon hat, oder bei seinen In-App-Standardwerten: Ein Rollout, ein A/B-Test oder ein Kill Switch erreicht es nicht. Projektadministratoren bekommen E-Mails und ein Banner in der Console, wenn sich die Nutzung dem Limit nähert. Eine Warnung im Posteingang ist also der Moment, genauer hinzusehen.

Ihre Fetches zählen

Ein Fetch ist eine Anfrage, die den Remote-Config-Server erreicht:

Aufrufe, die andere Firebase-Produkte intern machen, zählen ebenfalls nicht. So sehen Sie, wie viele Fetches Ihr Projekt macht:

• Firebase Console: Nutzung und Abrechnung (Usage and billing), Abschnitt Remote Config. Bei Spark zeigt die Karte zum Kontingentfortschritt die Fetches des Tages im Verhältnis zu 100.000. Bei Blaze teilt ein Balkendiagramm jeden Tag auf die Preisstufen auf.
• Google Cloud Console: IAM & Verwaltung > Kontingente und Systemlimits (IAM & Admin > Quotas & System Limits), gefiltert nach firebaseremoteconfig.googleapis.com, in beiden Tarifen. Bei Blaze zeigen die Cloud-Billing-Berichte die Kosten unter der SKU Fetch Requests: 37B1-4623-6F54 für Projekte, die am oder nach dem 1. September 2026 erstellt wurden, 598C-0184-404A für ältere.

Teilen Sie dann die Fetches eines typischen Tages durch die aktiven Nutzer dieses Tages in Analytics. Mit dem Standardintervall von 12 Stunden und ohne Echtzeit-Listener kommt ein Gerät auf höchstens etwa zwei Fetches pro Tag, das Ergebnis liegt also bei 2 oder darunter, etwas höher, wenn viele Nutzer die App auf mehreren Geräten haben oder Ihre Website aus mehreren Browsern besuchen. Liegt es deutlich über 2, umgeht etwas in Ihrem Code das Intervall, und der Abschnitt über zusätzliche Fetches zeigt, wo Sie suchen müssen.

Was Ihre App zahlen wird

Die täglichen Fetches sind die täglich aktiven Nutzer mal die Fetches pro Nutzer und Tag. Geben Sie Ihre eigenen Zahlen ein oder die, die Sie nach einem Launch erwarten:

Einige Größenordnungen, mit Blaze, für einen Monat aus 30 gleichen Tagen:

Bei einer Million täglicher Nutzer spart der Schritt von 10 Fetches pro Nutzer auf 2 etwa 1.440 $ im Monat. Umgekehrt gerechnet: So viele tägliche Nutzer passen in die kostenlosen 100.000:

Woher zusätzliche Fetches kommen und wie Sie sie reduzieren

Jede Fetch-Methode prüft zuerst das minimale Fetch-Intervall. Innerhalb davon gibt das SDK die Werte zurück, die es schon hat, und es wird keine Anfrage gesendet. Wie viele Fetches eine App macht, hängt also davon ab, wie dieses Intervall eingestellt ist, und von den wenigen Dingen, die es umgehen. Suchen Sie zuerst jede Stelle, an der Ihr Code es setzt oder umgeht:

grep -rniE "minimumfetchinterval|fetch\(0|expirationduration|timespan\.zero" \
  --exclude-dir={node_modules,build,Pods,.dart_tool,.gradle} .

1. Ein kurzes Fetch-Intervall, das in Produktion geblieben ist

Der Standard ist 12 Stunden auf Android, Apple-Plattformen, im Web und in Flutter. Kürzere Werte stammen aus Entwicklungs-Setups und aus Beispielen: Der eigene Flutter-Einstiegscode von Firebase setzt eine Stunde, „um häufige Aktualisierungen zu ermöglichen“, und viele Tutorials übernehmen das. Unverändert ausgeliefert, erlaubt eine Stunde jedem Gerät einen Fetch pro Sitzung, die eine Stunde nach dem letzten Fetch beginnt, bis zu 24-mal am Tag. Beschränken Sie kurze Werte auf Debug-Builds:

// Android (Kotlin). On AGP 8+, BuildConfig.DEBUG needs
// buildFeatures { buildConfig = true } in build.gradle.
Firebase.remoteConfig.setConfigSettingsAsync(
    remoteConfigSettings {
        // 12 hours in release builds
        minimumFetchIntervalInSeconds = if (BuildConfig.DEBUG) 60 else 43200
    }
)

// iOS (Swift)
let settings = RemoteConfigSettings()
#if DEBUG
settings.minimumFetchInterval = 60
#else
settings.minimumFetchInterval = 43200 // 12 hours
#endif
RemoteConfig.remoteConfig().configSettings = settings

// Flutter. kDebugMode is in package:flutter/foundation.dart.
await FirebaseRemoteConfig.instance.setConfigSettings(RemoteConfigSettings(
  fetchTimeout: const Duration(minutes: 1),
  minimumFetchInterval:
      kDebugMode ? const Duration(minutes: 1) : const Duration(hours: 12),
));

// Web. 12 hours is the default, so deleting the line does the same.
const remoteConfig = getRemoteConfig(app);
remoteConfig.settings.minimumFetchIntervalMillis = 12 * 60 * 60 * 1000;

Für Werte, die sich selten ändern, empfiehlt Firebase, noch weiter zu gehen, auf 24 oder 48 Stunden. Wenn Sie das Intervall verkürzt haben, damit Änderungen die Nutzer schnell erreichen, erledigen Echtzeit-Updates (4) das mit einem Fetch pro Änderung statt einem pro Sitzung.

2. Ein fetch(0) aus einem Fix für „Remote Config wird nicht aktualisiert“

Eine verbreitete Antwort auf „meine neuen Werte werden nicht angezeigt“ ist, dem Fetch-Aufruf ein Intervall von null zu übergeben. Auf Android und Apple-Plattformen hat dieses Argument Vorrang vor den Einstellungen, sodass der Aufruf jedes Mal an den Server geht, egal wie das Intervall konfiguriert ist:

// Each of these ignores the interval and goes to the server on every call:
remoteConfig.fetch(0)                                // Android
remoteConfig.fetch(withExpirationDuration: 0)        // iOS
remoteConfig.FetchAsync(TimeSpan.Zero)               // Unity

Entfernen Sie das Argument und lassen Sie das konfigurierte Intervall gelten. Die Werte, die ein Nutzer sieht, aktualisieren sich trotzdem innerhalb von 12 Stunden, oder sofort mit einem Echtzeit-Listener.

3. Fetches bei jedem Bildschirm, jedem Resume oder jedem Aufwecken im Hintergrund

Ein Fetch im Setup jedes Bildschirms, in jedem onResume, bei jedem Mounten einer Komponente oder in Application.onCreate, das auch läuft, wenn eine Push-Nachricht oder ein Hintergrundjob die App aufweckt, vervielfacht, was das Intervall erlaubt. Bei 12 Stunden fällt das kaum ins Gewicht, weil die meisten dieser Aufrufe auf dem Gerät beantwortet werden. Bei einem kurzen Intervall oder fetch(0) entstehen genau hier die großen Zahlen. Führen Sie einen Fetch einmal aus, wenn die App im Vordergrund startet, und lesen Sie die Werte überall sonst mit den Gettern. Firebase nennt die im Hintergrund „Ghost Fetches“ und zählt sie zu den ersten Dingen, die man prüfen sollte.

4. Echtzeit-Updates und häufiges Veröffentlichen

Ein Echtzeit-Listener hält eine Verbindung offen, solange die App im Vordergrund ist, und die Verbindung ist kostenlos. Wenn Sie eine neue Version der Vorlage veröffentlichen, lädt jedes Gerät mit aktivem Listener sie herunter, und jeder Download ist ein Fetch, der das Intervall ignoriert. Ein Gerät, das die App später mit einer älteren Version öffnet, bekommt sie auf dieselbe Weise. Jede Veröffentlichung kostet also, egal was sie ändert, bis zu einen Fetch pro Gerät, auf dem Ihre App vor der nächsten Veröffentlichung läuft.

200.000 Geräte an einem Tag mit 10 Veröffentlichungen ergeben allein durch Echtzeit bis zu 2 Millionen Fetches, etwa 12 $ an diesem Tag bei 0,06 $ pro 10.000. Fassen Sie Änderungen in einer Veröffentlichung zusammen statt in mehreren kleinen, und fügen Sie den Listener nur dort hinzu, wo eine sofortige Änderung zählt, etwa bei einem Kill Switch.

5. Die Vorlage bei jeder Serveranfrage laden

Serverseitiges Remote Config, noch in der Preview-Phase, lädt die ganze Vorlage mit einem Admin SDK herunter, und jeder Download ist ein Fetch. Ein Aufruf von getServerTemplate() in einem Cloud-Function- oder Cloud-Run-Handler erzeugt einen pro Anfrage, sodass ein viel genutzter Endpunkt allein über 100.000 pro Tag kommen kann. Laden Sie sie einmal pro Serverinstanz und aktualisieren Sie sie per Timer:

import { initializeApp } from "firebase-admin/app";
import { getRemoteConfig } from "firebase-admin/remote-config";

initializeApp();

const DEFAULTS = { welcome_message: "Hello" };
// At most one fetch per server instance every 10 minutes.
const REFRESH_MS = 10 * 60 * 1000;

let templatePromise; // one template per server instance, kept between requests
let loadedAt = 0;

export async function getConfig() {
  if (!templatePromise) {
    loadedAt = Date.now();
    templatePromise = getRemoteConfig()
      .getServerTemplate({ defaultConfig: DEFAULTS })
      .catch((err) => {
        templatePromise = undefined; // try again on the next request
        throw err;
      });
  }

  const template = await templatePromise;

  if (Date.now() - loadedAt > REFRESH_MS) {
    loadedAt = Date.now();
    // Refreshes in the background. Until it lands, requests get the
    // values already loaded.
    template.load().catch((err) => console.error("Refresh failed", err));
  }

  return template.evaluate();
}

Eine Aktualisierung alle 10 Minuten sind 144 Fetches pro Tag für jede laufende Instanz, unabhängig vom Traffic. Skripte und CI-Jobs, die die Vorlage über die REST-API lesen, zählen auch, wenn auch selten in nennenswertem Umfang.

Beim Wechsel zu Blaze eine Budgetbenachrichtigung einrichten

Blaze hat keine harte Obergrenze. Öffnen Sie in der Google Cloud Console Abrechnung (Billing) > Budgets und Benachrichtigungen (Budgets & alerts) und erstellen Sie ein Budget für das Projekt, in der Nähe dessen, was der Rechner oben ergibt. Standardmäßig schickt es Abrechnungsadministratoren bei 50 %, 90 % und 100 % des Betrags eine E-Mail. Es stoppt keine Ausgaben. Nehmen Sie die erste E-Mail also als Signal, sich das Remote-Config-Diagramm auf der Seite Nutzung und Abrechnung (Usage and billing) anzusehen.

Häufige Fragen

Ist Firebase Remote Config noch kostenlos?

Bis 100.000 Fetches pro Tag und Projekt, mit Spark und mit Blaze. Das Lesen von Werten auf dem Gerät, A/B Testing, Rollouts und Personalisierung kosten nichts extra. Über 100.000 pro Tag zahlen Blaze-Projekte 0,06 $ pro 10.000 Fetches, und Spark-Projekte werden nach einer Kulanzfrist von 30 Tagen gedrosselt.

Ab wann zahlen bestehende Projekte?

Projekte im Blaze-Tarif ab dem 1. Februar 2027. Projekte im Spark-Tarif werden nicht abgerechnet: Für sie gilt die Grenze von 100.000 ab dem 1. Dezember 2026, es sei denn, sie wechseln vor dem 15. November 2026 zu Blaze. In dem Fall beginnt die Abrechnung am 1. Februar 2027.

Gilt das Limit von 100.000 pro App oder pro Projekt?

Pro Projekt. Alle Apps, die in einem Firebase-Projekt registriert sind, teilen es sich.

Muss ich meinen Code ändern oder das SDK aktualisieren?

Nein. Gezählt wird auf den Servern von Firebase, und ein Wechsel zwischen Spark und Blaze erfordert keine Änderung an der App. Codeänderungen spielen nur eine Rolle, wenn Sie weniger Fetches wollen.

Kostet Remote Config in Echtzeit mehr?

Die offene Verbindung zählt nicht. Jeder Download einer neuen Vorlagenversion nach einer Veröffentlichung zählt, einer pro Gerät, und er ignoriert das minimale Fetch-Intervall.

Warum bekommen meine Nutzer die neuen Remote-Config-Werte nicht?

Meist liegt es am minimalen Fetch-Intervall: Ein Gerät behält seine Werte standardmäßig bis zu 12 Stunden, und abgerufene Werte gelten erst nach activate(). Seit den neuen Preisen kann ein Spark-Projekt außerdem gedrosselt werden, sobald es seit mehr als 30 Tagen über 100.000 Fetches pro Tag liegt. Prüfen Sie den Abschnitt Remote Config unter Nutzung und Abrechnung (Usage and billing), bevor Sie das Intervall verkürzen, denn das würde die Drosselung verschlimmern.

Quellen

• Preise für Remote Config: Preise, Übergangstermine, was als Fetch zählt, wo Sie die Nutzung sehen
• Drosselung in Remote Config und Ladestrategien: der Standard von 12 Stunden und was ihn überschreibt
• Remote Config in Echtzeit: wie Updates heruntergeladen werden
• Serverseitiges Remote Config
• Cloud-Billing-Budgets und -Benachrichtigungen