Preços da Configuração remota

A partir de 1º de setembro de 2026, o Remote Config vai oferecer uma estrutura de preços flexível projetada para acomodar projetos de todos os tamanhos, com um plano sem custo financeiro e um nível de pagamento por uso escalonável com base no seu uso diário.

Somente as solicitações de busca invocadas diretamente pelo serviço Remote Config (por SDKs de cliente ou APIs REST) contribuem para o uso faturado. Operações de busca, chamadas de rede ou métricas geradas internamente por outros serviços do Firebase não são contabilizadas nas cotas ou no faturamento do Remote Config.

A tabela a seguir mostra o uso por projeto para os planos Spark e Blaze:

Detalhes Sem custo financeiro (plano Spark) Pagamento por uso (plano Blaze)
Solicitações de busca Até 100.000 por dia Sem custo financeiro até 100.000 por dia.

Depois, siga estas instruções:

  • US$ 0,000006 por solicitação (US$ 0,06 / 10 mil solicitações) para uso entre 100.001 e 10.000.000 por dia.
  • US$ 0,000001 por solicitação (US$ 0,01 / 10 mil solicitações) para uso acima de 10.000.000 por dia.
Todos os recursos Inclui personalização, lançamentos e integração com o A/B Testing Inclui personalização, lançamentos e integração com o A/B Testing
Cotas e limites Consulte Cotas e limites. Consulte Cotas e limites.

Períodos de carência de transição para projetos atuais

Esse período de carência de transição é relevante para projetos que têm o Remote Config ativado antes de 1º de setembro de 2026. Para garantir uma transição tranquila para o preço de pagamento por uso, os projetos atuais recebem os seguintes períodos de carência estendidos antes do início da aplicação do faturamento:

Plano de faturamento atual Período de carência da transição Início do faturamento padrão Ação necessária / Observações
Plano Spark (sem custo financeiro) 3 meses 1º de dezembro de 2026 Ação recomendada:configure o Cloud Billing e faça upgrade para o plano Blaze.

Bônus:se você fizer o upgrade antes de 15 de novembro de 2026, seu período de carência será estendido para 5 meses (o faturamento começa em 1º de fevereiro de 2027).

Plano Blaze (pagamento por uso) 5 meses 1º de fevereiro de 2027 Nenhuma ação é necessária. Os projetos vão passar automaticamente para o preço padrão em 1º de fevereiro de 2027.

Períodos de carência padrão

Esse período de carência é relevante para projetos que têm o Remote Config ativado a partir de 1º de setembro de 2026. Isso inclui projetos atuais com o Remote Config ativado (criados antes de 1º de setembro de 2026) em que o período de carência da transição expirou. Se um projeto exceder 100.000 solicitações de busca por dia, as seguintes ações precisarão ser seguidas:

Plano / Condição Período de carência Resultado após o período de carência Ação necessária / Observações
Plano Spark (sem custo financeiro) 30 dias (aplicável quando o projeto excede o limite diário pela primeira vez) A limitação começa no 31º dia Os projetos têm serviço ininterrupto por 30 dias após o limite diário ser excedido pela primeira vez. Para evitar a limitação no dia 31 ou depois, faça upgrade para o plano Blaze.
Plano Blaze (pagamento por uso) N/A (sem limitação) Faturamento por solicitação de busca O uso acima de 100.000 buscas é cobrado. Nenhuma limitação é aplicada.

Práticas recomendadas para otimizar o uso

Para otimizar o uso, siga um destes procedimentos:

  • Intervalos de busca do cliente: evite definir intervalos de busca mínimos muito baixos (por exemplo, setMinimumFetchIntervalInSeconds) em builds de produção. O intervalo padrão recomendado é de 12 horas.
  • Armazenamento em cache para parâmetros não críticos: para valores de configuração estáveis que raramente mudam, considere aumentar setMinimumFetchIntervalInSeconds do padrão de 12 horas para 24 ou 48 horas.
  • Loops de busca na inicialização do app: verifique se o app não aciona uma busca remota em cada transição de tela, retomada de atividade ou renderização de componente. Use estratégias de carregamento, como Buscar e ativar no carregamento ou Ativar por trás da tela de carregamento, de forma responsável.
  • Auditoria de buscas em segundo plano e inativas: revise jobs de worker em segundo plano, serviços ou módulos de apps legados para remover chamadas de busca redundantes ("buscas fantasmas") que são acionadas quando o app está em segundo plano ou inativo.
  • Monitoramento: use os painéis de preços e uso do console do Google Cloud e do Firebase para configurar alertas de faturamento automatizados quando os volumes de busca diários se aproximarem de 100.000 solicitações.

Perguntas frequentes e solução de problemas