Firebase Remote Config empieza a cobrar: todo lo que cambia a partir del 1 de septiembre

por · Publicada · Actualizado

Si tienes alguna app en producción que use Firebase Remote Config, apunta esta fecha en el calendario: 1 de septiembre de 2026. Google ha anunciado que este servicio, que hasta ahora era gratuito sin ningún tipo de límite real, pasa a un modelo de pago por uso. No entra en pánico todavía, porque la mayoría de proyectos seguirán sin pagar ni un euro, pero sí conviene entender bien qué cambia y, sobre todo, revisar cómo está implementado Remote Config en tu app antes de que llegue la fecha.

Vamos a desgranar el cambio con calma: qué es exactamente lo que se modifica, cuánto vas a pagar si superas el límite gratuito, y qué puedes hacer desde ya para que la factura de Firebase no te dé ningún susto.

¿Qué es Firebase Remote Config y por qué importa este cambio?

Para quien no lo tenga fresco: Remote Config es el servicio de Firebase que permite cambiar el comportamiento y la apariencia de una app sin pasar por la tienda de aplicaciones. Activar una función nueva para un grupo de usuarios, cambiar un texto, ajustar un experimento A/B o desactivar una funcionalidad problemática en caliente… todo eso pasa, en la mayoría de apps Android, por Remote Config.

Precisamente por ser tan transversal —está integrado en experimentos, personalización y rollouts progresivos—, es uno de los servicios de Firebase que más peticiones recibe silenciosamente en segundo plano. Y ahí es donde entra el cambio de precios: cada vez que tu app pide (fetch) una configuración al servidor, esa petición ahora cuenta.

Qué cambia exactamente a partir del 1 de septiembre

Hasta ahora, Remote Config estaba dentro de la lista de productos «no-cost» de Firebase, sin límite práctico de peticiones. A partir del 1 de septiembre de 2026, Google introduce una estructura de precios basada en el uso, con un nivel gratuito por delante. En palabras de la propia documentación de Firebase, Remote Config pasa a una estructura de precios basada en el uso con un nivel sin coste.

Lo importante: no es un cambio retroactivo ni afecta a las funciones que ofrece el servicio. Todas las funciones avanzadas —Personalización, Rollouts e integración con A/B Testing— se mantienen incluidas sin coste adicional en ambos planes. Lo que se empieza a medir es exclusivamente el volumen de peticiones de fetch que hace tu app cada día.

Los nuevos planes: Spark y Blaze

Firebase organiza el nuevo modelo en dos escalones, calcados a los planes generales de la plataforma:

  • Plan Spark (sin coste): hasta 100.000 peticiones de fetch al día sin coste alguno.
  • Plan Blaze (pago por uso): las primeras 100.000 peticiones diarias siguen siendo gratis. A partir de ahí, se cobran 0,06 $ por cada 10.000 peticiones (0,000006 $/petición) entre las 100.001 y los 10.000.000 de peticiones diarias, y 0,01 $ por cada 10.000 peticiones (0,000001 $/petición) para el uso que supere los 10.000.000 diarios.

Dicho de otra forma: cuantas más peticiones hagas, más barata es cada una de ellas por tramos. Y no, no necesitas tener una cuenta de facturación para empezar a usar Remote Config; puedes usar el plan Spark sin coste desde el primer día.

¿Vas a pagar? Cómo saberlo

Para la inmensa mayoría de apps pequeñas y medianas, la respuesta corta es: no. 100.000 peticiones diarias dan bastante margen si tu app respeta los intervalos de refresco recomendados. El problema aparece en dos escenarios muy concretos:

  • Apps con base de usuarios grande que hacen fetch en cada apertura o cada pocos minutos.
  • Implementaciones «agresivas», donde se llama a Remote Config en cada cambio de pantalla, cada onResume() o cada vez que se abre un fragmento, multiplicando las peticiones sin necesidad real.

Si tu app cae en el segundo grupo, es muy probable que hoy mismo ya estés generando un volumen de peticiones que, a partir de septiembre, empezará a facturarse en cuanto pases del umbral gratuito.

El periodo de gracia de 30 días

Google ha pensado en que nadie se quede colgado de un día para otro. Si tu proyecto está en el plan Spark y supera por primera vez las 100.000 peticiones diarias, Firebase concede un periodo de gracia de 30 días durante el cual las peticiones de Remote Config se siguen sirviendo sin interrupción.

Ahora bien, si al terminar esos 30 días no has actualizado a Blaze, el servicio empezará a limitar (throttling) las peticiones que superen el límite diario, lo que puede impedir que los clientes reciban configuraciones actualizadas. Es decir: tu app no se rompe, pero deja de recibir las configuraciones nuevas hasta que actualices el plan. Y ojo, porque pasar al plan Blaze implica vincular el proyecto a una cuenta de Google Cloud Billing, así que conviene tenerlo previsto con margen y no dejarlo para el último día del periodo de gracia.

Cómo comprobar tu consumo actual

Antes de que llegue septiembre, lo primero que deberías hacer es mirar cuántas peticiones está generando tu app hoy. Google ha habilitado un panel específico para esto: si tu proyecto está en el plan Spark, puedes consultar tu uso actual y los límites del sistema activos en la página de Cuotas y límites del sistema de la consola de Google Cloud. Es importante que, al filtrar los informes, selecciones específicamente la API de Firebase que quieres comprobar (por ejemplo, firebaseremoteconfig.googleapis.com), ya que de lo contrario verás datos mezclados de otros servicios.

Además, conviene configurar alertas para no llevarte sorpresas. Google recomienda usar la consola de Google Cloud y los paneles de precios y uso de Firebase para configurar alertas de facturación automáticas cuando el volumen diario de peticiones se acerque a las 100.000.

Buenas prácticas para no disparar la factura

La buena noticia es que reducir el número de peticiones suele ser tan sencillo como revisar dos o tres puntos del código. Google señala directamente los errores más habituales: evitar intervalos mínimos de fetch muy bajos en producción (por ejemplo, con setMinimumFetchIntervalInSeconds), siendo 12 horas el intervalo recomendado por defecto, y asegurarse de que la app no dispara un fetch remoto en cada transición de pantalla, cada reanudación de actividad o cada renderizado de componente.

En la práctica, esto se traduce en revisar tu configuración del cliente de Remote Config. Un ejemplo típico en Kotlin, forzando un intervalo razonable en producción:

Kotlin
val configSettings = remoteConfigSettings {
    // 12 horas es el intervalo recomendado por Google en producción.
    // Evita valores bajos (minutos o segundos) fuera de fases de depuración.
    minimumFetchIntervalInSeconds = 43200 // 12 horas
}

remoteConfig.setConfigSettingsAsync(configSettings)

remoteConfig.fetchAndActivate()
    .addOnCompleteListener { task ->
        if (task.isSuccessful) {
            val updated = task.result
            Log.d("RemoteConfig", "Parámetros actualizados: $updated")
        } else {
            Log.w("RemoteConfig", "Fetch fallido, se usan valores en caché")
        }
    }

Y sobre todo, revisa el lugar desde el que llamas a fetchAndActivate(). Si lo tienes en el onResume() de cada actividad o en cada recomposición de un Composable, ahí es donde probablemente se están multiplicando las peticiones sin que aporten ningún valor real, porque la configuración no cambia cada pocos segundos.

Cómo prepararte antes del 1 de septiembre

Resumiendo el plan de acción antes de que llegue la fecha:

  • Audita tu código y localiza todas las llamadas a fetch() / fetchAndActivate().
  • Sube el intervalo mínimo de refresco a un valor razonable (12 horas por defecto, salvo casos justificados como experimentos en tiempo real).
  • Consulta tu consumo actual en la consola de Google Cloud, filtrando por firebaseremoteconfig.googleapis.com.
  • Configura alertas de uso para que te avisen si te acercas a las 100.000 peticiones diarias.
  • Si tu proyecto ya roza o supera ese umbral, valora pasar a Blaze con margen, en lugar de esperar a que se agote el periodo de gracia de 30 días.

Ninguno de estos pasos lleva más de media hora, y te evita cualquier sorpresa cuando llegue septiembre.

Recursos

Etiquetas:

También te podría gustar...