Firexport / Blog

Desde 1º de setembro de 2026, o preço do Firebase Remote Config depende de quantas vezes os apps fazem fetch da configuração. Os primeiros 100.000 fetches por dia são gratuitos em todos os planos. Acima disso, os projetos no Blaze pagam por fetch e os projetos no Spark acabam limitados. A maioria dos apps fica abaixo do limite. Se o seu fica ou não depende menos de quantos usuários você tem do que de uma configuração no seu código: o intervalo mínimo de fetch.

Os preços

• Os 100.000 são por projeto. Um app Android, um app iOS e um site no mesmo projeto dividem esse total.
• São por dia, e um dia tranquilo não compensa um dia movimentado. Um dia de lançamento com um milhão de fetches custa US$ 5,40 mesmo que o resto do mês fique abaixo de 100.000.
• Você não precisa mudar o código nem a versão do SDK. O Firebase mede os fetches do lado dele, nos dois planos.

Quando o novo preço chega ao seu projeto

Os projetos que ativaram o Remote Config antes de 1º de setembro de 2026 têm primeiro um período de transição. Qual deles depende do plano em que o projeto está:

A página de preços não diz o que acontece com um projeto no Spark que faça upgrade entre 15 de novembro e 1º de dezembro. Se esse é o seu plano, conte com a cobrança a partir de 1º de dezembro.

Vale a pena fazer upgrade antes de 15 de novembro?

• Se o seu projeto faz menos de 100.000 fetches por dia, não. O Spark continua funcionando como antes, e o Blaze também.
• Se faz mais, ou está perto disso, fazer upgrade antes de 15 de novembro dá dois meses, dezembro e janeiro, para reduzir os fetches antes de qualquer cobrança. A alternativa no Spark é a limitação, que para a maioria dos apps é pior do que alguns dólares.
• O Blaze vincula o projeto a uma conta do Cloud Billing e não tem limite de gastos. Os outros produtos mantêm o uso sem custo, e você paga só o que passar dele. Configure um alerta de orçamento ao fazer upgrade (abaixo).

O que significa a limitação no Spark

O primeiro dia em que um projeto no Spark passa de 100.000 fetches inicia um período de carência de 30 dias, durante o qual todo fetch continua sendo atendido. A contagem não pausa nem recomeça se o uso voltar a ficar abaixo do limite nesse meio-tempo. A partir do dia 31, os fetches de cada dia que passarem de 100.000 são recusados. O app continua funcionando, mas um dispositivo cujo fetch é recusado fica com os valores que já tem, ou com os valores padrão do app: um lançamento, um teste A/B ou uma chave de emergência (kill switch) não chega até ele. Os administradores do projeto recebem e-mails e veem um banner no console conforme o uso se aproxima do limite, então um aviso na sua caixa de entrada é a hora de dar uma olhada.

Conte seus fetches

Um fetch é uma solicitação que chega ao servidor do Remote Config:

Chamadas que outros produtos do Firebase fazem internamente também não contam. Para ver quantos fetches seu projeto faz:

• Console do Firebase: Uso e faturamento (Usage and billing), seção Remote Config. No Spark, o cartão de progresso da cota mostra os fetches do dia em relação aos 100.000. No Blaze, um gráfico de barras divide cada dia entre as faixas de preço.
• Console do Google Cloud: IAM e administrador > Cotas e limites do sistema (IAM & Admin > Quotas & System Limits), filtrado por firebaseremoteconfig.googleapis.com, em qualquer um dos planos. No Blaze, os relatórios do Cloud Billing mostram as cobranças no SKU Fetch Requests: 37B1-4623-6F54 para projetos criados em 1º de setembro de 2026 ou depois, 598C-0184-404A para os mais antigos.

Depois divida os fetches de um dia típico pelos usuários ativos desse dia no Analytics. Com o intervalo padrão de 12 horas e sem listener em tempo real, um dispositivo não consegue fazer mais do que uns dois fetches por dia, então o resultado é 2 ou menos, um pouco mais se muitos usuários têm o app em vários dispositivos ou acessam seu site de vários navegadores. Bem acima de 2, algo no seu código pula o intervalo, e a seção sobre fetches extras mostra onde procurar.

Quanto o seu app vai pagar

Os fetches por dia são os usuários ativos por dia multiplicados pelos fetches por usuário por dia. Coloque seus próprios números, ou os que você espera depois de um lançamento:

Alguns tamanhos, no Blaze, para um mês de 30 dias iguais:

Com um milhão de usuários por dia, passar de 10 fetches por usuário para 2 economiza cerca de US$ 1.440 por mês. Pelo outro lado, veja quantos usuários por dia cabem nos 100.000 gratuitos:

De onde vêm os fetches extras, e como cortá-los

Todo método de fetch verifica primeiro o intervalo mínimo de fetch. Dentro dele, o SDK retorna os valores que já tem e nenhuma solicitação é feita. Então os fetches que um app faz dependem de como esse intervalo está configurado, e das poucas coisas que passam por cima dele. Comece encontrando todos os lugares em que seu código configura ou pula o intervalo:

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

1. Um intervalo de fetch curto esquecido em produção

O padrão é 12 horas no Android, nas plataformas da Apple, na web e no Flutter. Valores menores vêm de configurações de desenvolvimento e de exemplos: o próprio código de primeiros passos do Firebase para Flutter define uma hora “para permitir atualizações frequentes”, e muitos tutoriais copiam isso. Se for publicado assim, um intervalo de uma hora deixa cada dispositivo fazer um fetch por sessão que comece uma hora depois do último fetch, até 24 vezes por dia. Deixe os valores curtos só para os builds de depuração:

// 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 mudam pouco, o Firebase sugere ir além, para 24 ou 48 horas. Se você encurtou o intervalo para que as mudanças cheguem rápido aos usuários, as atualizações em tempo real (4) fazem isso com um fetch por mudança em vez de um por sessão.

2. Um fetch(0) vindo de uma correção para “Remote Config não atualiza”

Uma resposta comum para “meus novos valores não aparecem” é passar um intervalo de zero para a chamada de fetch. No Android e nas plataformas da Apple, esse argumento tem prioridade sobre as configurações, então a chamada vai ao servidor toda vez, seja qual for o intervalo configurado:

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

Remova o argumento e deixe o intervalo configurado valer. Os valores que um usuário vê continuam se atualizando em até 12 horas, ou na hora com um listener em tempo real.

3. Fazer fetch em cada tela, retomada ou despertar em segundo plano

Um fetch na inicialização de cada tela, em cada onResume, em cada montagem de componente, ou em Application.onCreate, que também roda quando uma mensagem push ou uma tarefa em segundo plano acorda o app, multiplica o que o intervalo permitir. Com 12 horas, isso acrescenta pouco, já que a maioria dessas chamadas é respondida no dispositivo. Com um intervalo curto ou fetch(0), é daí que vêm os números grandes. Faça fetch uma vez, quando o app abre em primeiro plano, e leia os valores com os getters no resto do app. O Firebase chama os de segundo plano de “fetches fantasmas” (ghost fetches) e os coloca entre as primeiras coisas a auditar.

4. Atualizações em tempo real e publicações frequentes

Um listener em tempo real mantém uma conexão aberta enquanto o app está em primeiro plano, e a conexão é gratuita. Quando você publica uma nova versão do modelo, todo dispositivo que está escutando faz o download dela, e cada download é um fetch que ignora o intervalo. Um dispositivo que abre o app mais tarde com uma versão anterior a recebe do mesmo jeito. Então cada publicação, mude o que mudar, custa até um fetch por dispositivo que rode seu app antes da próxima.

200.000 dispositivos em um dia com 10 publicações são até 2 milhões de fetches só do tempo real, cerca de US$ 12 nesse dia a US$ 0,06 por 10.000. Junte as edições em uma única publicação em vez de várias pequenas, e adicione o listener só onde uma mudança instantânea importa, como em uma chave de emergência.

5. Carregar o modelo a cada solicitação no servidor

O Remote Config do lado do servidor, ainda em fase de prévia, baixa o modelo inteiro com um Admin SDK, e cada download é um fetch. Chamar getServerTemplate() dentro de uma Cloud Function ou de um handler do Cloud Run faz um por solicitação, então um endpoint movimentado sozinho pode passar de 100.000 por dia. Carregue o modelo uma vez por instância do servidor e atualize-o com um 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();
}

Atualizar a cada 10 minutos dá 144 fetches por dia para cada instância em execução, seja qual for o tráfego. Scripts e jobs de CI que leem o modelo pela API REST também contam, embora raramente o bastante para fazer diferença.

Configure um alerta de orçamento ao fazer upgrade para o Blaze

O Blaze não tem um teto rígido. No console do Google Cloud, abra Faturamento (Billing) > Orçamentos e alertas (Budgets & alerts) e crie um orçamento para o projeto, perto do valor que a calculadora acima dá. Por padrão, ele envia e-mails aos administradores de faturamento em 50%, 90% e 100% do valor. Ele não interrompe os gastos, então trate o primeiro e-mail como o sinal para olhar o gráfico do Remote Config na página Uso e faturamento (Usage and billing).

Perguntas frequentes

O Firebase Remote Config ainda é gratuito?

Até 100.000 fetches por dia por projeto, no Spark e no Blaze. Ler valores no dispositivo, A/B Testing, lançamentos e personalização não custam nada a mais. Acima de 100.000 por dia, os projetos no Blaze pagam US$ 0,06 por 10.000 fetches e os projetos no Spark são limitados após um período de carência de 30 dias.

Quando os projetos existentes começam a pagar?

Os projetos no Blaze, em 1º de fevereiro de 2027. Os projetos no Spark não são cobrados: o limite de 100.000 vale para eles a partir de 1º de dezembro de 2026, a menos que façam upgrade para o Blaze antes de 15 de novembro de 2026, caso em que a cobrança começa em 1º de fevereiro de 2027.

O limite de 100.000 é por app ou por projeto?

Por projeto. Todos os apps registrados em um projeto do Firebase compartilham esse limite.

Preciso mudar meu código ou atualizar o SDK?

Não. A medição acontece nos servidores do Firebase, e trocar entre Spark e Blaze não exige nenhuma mudança no app. Mudar o código só importa se você quiser menos fetches.

O Remote Config em tempo real custa mais?

A conexão aberta não conta. Cada download de uma nova versão do modelo depois que você publica conta, um por dispositivo, e ignora o intervalo mínimo de fetch.

Por que meus usuários não recebem os novos valores do Remote Config?

Normalmente é o intervalo mínimo de fetch: por padrão, um dispositivo mantém seus valores por até 12 horas, e os valores buscados só valem depois de activate(). Com o novo preço, um projeto no Spark também pode ser limitado depois de passar mais de 30 dias acima de 100.000 fetches por dia. Confira a seção Remote Config de Uso e faturamento (Usage and billing) antes de encurtar o intervalo, o que pioraria a limitação.

Fontes

• Preços do Remote Config: preços, datas de transição, o que conta como fetch, onde ver o uso
• Limitação do Remote Config e estratégias de carregamento: o padrão de 12 horas e o que passa por cima dele
• Remote Config em tempo real: como as atualizações são baixadas
• Remote Config do lado do servidor
• Orçamentos e alertas do Cloud Billing