Firexport / Blog

Desde el 1 de septiembre de 2026, el precio de Firebase Remote Config depende de cuántas veces las apps hacen fetch de su configuración. Los primeros 100.000 fetches al día son gratis en todos los planes. Por encima de eso, los proyectos en Blaze pagan por fetch y los proyectos en Spark terminan limitados. La mayoría de las apps se quedan por debajo del límite. Que la tuya lo haga depende menos de cuántos usuarios tengas que de un ajuste en tu código: el intervalo mínimo de fetch.

Los precios

• Los 100.000 son por proyecto. Una app de Android, una app de iOS y un sitio web del mismo proyecto los comparten.
• Son por día, y un día tranquilo no compensa uno con mucha actividad. Un día de lanzamiento con un millón de fetches cuesta 5,40 US$ aunque el resto del mes se quede por debajo de 100.000.
• No tienes que cambiar tu código ni tu versión del SDK. Firebase mide los fetches de su lado, en los dos planes.

Cuándo llega el nuevo precio a tu proyecto

Los proyectos que activaron Remote Config antes del 1 de septiembre de 2026 tienen primero un periodo de transición. Cuál les toca depende del plan en el que esté el proyecto:

La página de precios no dice qué pasa con un proyecto de Spark que se pase a Blaze entre el 15 de noviembre y el 1 de diciembre. Si es lo que piensas hacer, cuenta con que la facturación empiece el 1 de diciembre.

¿Deberías pasarte a Blaze antes del 15 de noviembre?

• Si tu proyecto hace menos de 100.000 fetches al día, no. Spark sigue funcionando como antes, y Blaze también.
• Si hace más, o está cerca, pasarte antes del 15 de noviembre te da dos meses, diciembre y enero, para reducir los fetches antes de que se facture nada. La alternativa en Spark es la limitación, que para la mayoría de las apps es peor que unos pocos dólares.
• Blaze vincula el proyecto a una cuenta de Cloud Billing y no tiene límite de gasto. Los demás productos conservan su uso sin costo, y solo pagas lo que lo supere. Configura una alerta de presupuesto al pasarte (más abajo).

Qué significa la limitación en Spark

El primer día en que un proyecto de Spark supera los 100.000 fetches empieza un periodo de gracia de 30 días, durante el cual se sigue atendiendo cada fetch. La cuenta regresiva no se pausa ni se reinicia si mientras tanto el uso vuelve a bajar del límite. Desde el día 31, se rechazan los fetches de cada día que pasen de los 100.000. La app sigue funcionando, pero un dispositivo cuyo fetch se rechaza se queda con los valores que ya tiene, o con los valores predeterminados de la app: no le llega un lanzamiento, una prueba A/B ni un interruptor de emergencia (kill switch). Los administradores del proyecto reciben correos y ven un banner en la consola a medida que el uso se acerca al límite, así que un aviso en tu bandeja de entrada es el momento de revisar.

Cuenta tus fetches

Un fetch es una solicitud que llega al servidor de Remote Config:

Las llamadas que otros productos de Firebase hacen internamente tampoco cuentan. Para ver cuántos fetches hace tu proyecto:

• Firebase console: Uso y facturación (Usage and billing), sección Remote Config. En Spark, la tarjeta de progreso de la cuota muestra los fetches del día frente a los 100.000. En Blaze, un gráfico de barras reparte cada día entre los niveles de precio.
• Consola de Google Cloud: IAM y administración > Cuotas y límites del sistema (IAM & Admin > Quotas & System Limits), filtrado por firebaseremoteconfig.googleapis.com, en cualquiera de los dos planes. En Blaze, los informes de Cloud Billing muestran los cargos con el SKU Fetch Requests: 37B1-4623-6F54 para los proyectos creados el 1 de septiembre de 2026 o después, y 598C-0184-404A para los anteriores.

Luego divide los fetches de un día típico entre los usuarios activos de ese día en Analytics. Con el intervalo predeterminado de 12 horas y sin listener en tiempo real, un dispositivo no puede hacer más de unos dos fetches al día, así que el resultado es 2 o menos, algo más si muchos usuarios tienen la app en varios dispositivos o entran a tu sitio web desde varios navegadores. Si da bastante más de 2, algo en tu código se salta el intervalo, y la sección sobre fetches de más muestra dónde buscar.

Cuánto pagará tu app

Los fetches diarios son los usuarios activos diarios multiplicados por los fetches por usuario al día. Ingresa tus propias cifras, o las que esperas después de un lanzamiento:

Algunos tamaños, en Blaze, para un mes de 30 días idénticos:

Con un millón de usuarios diarios, pasar de 10 fetches por usuario a 2 ahorra unos 1.440 US$ al mes. Visto al revés, estos son los usuarios diarios que caben en los 100.000 gratis:

De dónde salen los fetches de más y cómo reducirlos

Todos los métodos de fetch comprueban primero el intervalo mínimo de fetch. Dentro de él, el SDK devuelve los valores que ya tiene y no se hace ninguna solicitud. Así que los fetches que hace una app dependen de cómo esté configurado ese intervalo, y de las pocas cosas que se lo saltan. Empieza por encontrar cada lugar donde tu código lo configura o se lo salta:

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

1. Un intervalo de fetch corto que se quedó en producción

El valor predeterminado es de 12 horas en Android, en las plataformas de Apple, en la web y en Flutter. Los valores más cortos vienen de configuraciones de desarrollo y de ejemplos: el propio código de primeros pasos de Firebase para Flutter usa una hora “para permitir actualizaciones frecuentes”, y muchos tutoriales lo copian. Si se publica tal cual, una hora permite que cada dispositivo haga un fetch por cada sesión que empiece una hora después del último fetch, hasta 24 veces al día. Deja los valores cortos para las compilaciones de depuración:

// 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;

Para valores que cambian poco, Firebase sugiere ir más allá, a 24 o 48 horas. Si acortaste el intervalo para que los cambios lleguen rápido a los usuarios, las actualizaciones en tiempo real (4) lo consiguen con un fetch por cambio en lugar de uno por sesión.

2. Un fetch(0) que vino de una solución para “Remote Config no se actualiza”

Una respuesta habitual a “mis nuevos valores no aparecen” es pasar un intervalo de cero a la llamada de fetch. En Android y en las plataformas de Apple, ese argumento se impone a la configuración, así que la llamada va al servidor cada vez, sin importar cómo esté configurado el intervalo:

// 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

Quita el argumento y deja que se aplique el intervalo configurado. Los valores que ve un usuario se siguen actualizando en 12 horas como mucho, o al instante con un listener en tiempo real.

3. Hacer fetch en cada pantalla, al reanudar o al despertar en segundo plano

Un fetch en la inicialización de cada pantalla, en cada onResume, en cada montaje de componente o en Application.onCreate, que también se ejecuta cuando un mensaje push o una tarea en segundo plano despierta la app, multiplica lo que permita el intervalo. Con 12 horas suma poco, porque la mayoría de esas llamadas se responden en el dispositivo. Con un intervalo corto o fetch(0), es de ahí de donde salen las cifras grandes. Haz fetch una sola vez, cuando la app se inicia en primer plano, y lee los valores con los getters en el resto de la app. Firebase llama a los de segundo plano “fetches fantasma” (ghost fetches) y los pone entre lo primero que hay que revisar.

4. Actualizaciones en tiempo real y publicaciones frecuentes

Un listener en tiempo real mantiene una conexión abierta mientras la app está en primer plano, y la conexión es gratis. Cuando publicas una nueva versión de la plantilla, cada dispositivo que escucha la descarga, y cada descarga es un fetch que ignora el intervalo. Un dispositivo que abre la app más tarde con una versión anterior la recibe de la misma forma. Así que cada publicación, cambie lo que cambie, cuesta hasta un fetch por cada dispositivo que ejecute tu app antes de la siguiente.

200.000 dispositivos en un día con 10 publicaciones son hasta 2 millones de fetches solo por el tiempo real, unos 12 US$ ese día a 0,06 US$ por cada 10.000. Agrupa los cambios en una sola publicación en lugar de varias pequeñas, y agrega el listener solo donde importe un cambio instantáneo, como un interruptor de emergencia.

5. Cargar la plantilla en cada solicitud al servidor

Remote Config del lado del servidor, todavía en versión preliminar, descarga la plantilla completa con un Admin SDK, y cada descarga es un fetch. Llamar a getServerTemplate() dentro de una Cloud Function o de un controlador de Cloud Run hace uno por solicitud, así que un endpoint con mucho tráfico puede pasar por sí solo de 100.000 al día. Cárgala una vez por instancia del servidor y actualízala con un temporizador:

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();
}

Actualizarla cada 10 minutos son 144 fetches al día por cada instancia en ejecución, sea cual sea el tráfico. Los scripts y los trabajos de CI que leen la plantilla con la API REST también cuentan, aunque rara vez lo suficiente como para importar.

Configura una alerta de presupuesto al pasarte a Blaze

Blaze no tiene un tope fijo. En la consola de Google Cloud, abre Facturación (Billing) > Presupuestos y alertas (Budgets & alerts) y crea un presupuesto para el proyecto, cerca de lo que te da la calculadora de arriba. De forma predeterminada, envía un correo a los administradores de facturación al 50%, 90% y 100% del monto. No detiene el gasto, así que toma el primer correo como la señal para mirar el gráfico de Remote Config en la página Uso y facturación (Usage and billing).

Preguntas frecuentes

¿Firebase Remote Config sigue siendo gratis?

Hasta 100.000 fetches al día por proyecto, en Spark y en Blaze. Leer valores en el dispositivo, A/B Testing, los lanzamientos y la personalización no cuestan nada extra. Por encima de 100.000 al día, los proyectos en Blaze pagan 0,06 US$ por cada 10.000 fetches y los proyectos en Spark se limitan tras un periodo de gracia de 30 días.

¿Cuándo empiezan a pagar los proyectos existentes?

Los proyectos en Blaze, el 1 de febrero de 2027. Los proyectos en Spark no se facturan: el límite de 100.000 se les aplica desde el 1 de diciembre de 2026, salvo que se pasen a Blaze antes del 15 de noviembre de 2026, en cuyo caso la facturación empieza el 1 de febrero de 2027.

¿El límite de 100.000 es por app o por proyecto?

Por proyecto. Todas las apps registradas en un proyecto de Firebase lo comparten.

¿Tengo que cambiar mi código o actualizar el SDK?

No. La medición se hace en los servidores de Firebase, y cambiar entre Spark y Blaze no requiere ningún cambio en la app. Cambiar el código solo importa si quieres menos fetches.

¿Remote Config en tiempo real cuesta más?

La conexión abierta no cuenta. Cada descarga de una nueva versión de la plantilla después de publicar sí cuenta, una por dispositivo, e ignora el intervalo mínimo de fetch.

¿Por qué mis usuarios no reciben los nuevos valores de Remote Config?

Normalmente es por el intervalo mínimo de fetch: de forma predeterminada, un dispositivo conserva sus valores hasta 12 horas, y los valores obtenidos solo se aplican después de activate(). Desde el nuevo precio, un proyecto de Spark también puede estar limitado cuando lleva más de 30 días por encima de 100.000 fetches al día. Revisa la sección Remote Config de Uso y facturación (Usage and billing) antes de acortar el intervalo, lo que empeoraría la limitación.

Fuentes

• Precios de Remote Config: precios, fechas de transición, qué cuenta como fetch, dónde ver el uso
• Limitación de Remote Config y estrategias de carga: el valor predeterminado de 12 horas y lo que lo anula
• Remote Config en tiempo real: cómo se descargan las actualizaciones
• Remote Config del lado del servidor
• Presupuestos y alertas de Cloud Billing