Como limitar os gastos do Firebase no plano Blaze

Não para o projeto inteiro. No plano Blaze você paga pelo que usa, e o orçamento que você define ao fazer upgrade é um alerta: o Firebase diz que os alertas de orçamento "do not cap your usage or charges" ("não limitam seu uso nem suas cobranças") (planos de preços). O que você pode fazer é combinar vários limites, cada um cobrindo parte do risco. Aqui estão eles, do mais barato ao mais forte.

Ele não interrompe nada, mas é o sinal do qual todo o resto depende. Os padrões do Google são 50%, 90% e 100% do gasto real; o Firebase sugere "50% and 100% of Actual as well as 150% of Forecasted" ("50% e 100% do gasto real, além de 150% do previsto") (alertas de orçamento). Lembre-se de que a primeira notificação pode levar várias horas para chegar.

Os limites de gastos do Firebase (Preview) pausam um serviço pelo resto do mês quando ele atinge seu orçamento. Eles cobrem apenas Firebase AI Logic, App Hosting, Cloud Functions for Firebase e Extensions, e o Google observa que eles "not 'hard caps'" ("não são limites rígidos"): excedentes durante o atraso do relatório continuam sendo cobrados.

Uma função descontrolada custa mais quanto mais instâncias recebe. Defina um máximo: o Firebase chama isso de uma forma "to control your costs" ("de controlar seus custos") (gerenciar funções). No limite, as requisições HTTP extras ficam na fila por até 30 segundos e depois recebem um 429.

import { onRequest } from "firebase-functions/v2/https";

export const api = onRequest({ maxInstances: 10 }, async (req, res) => {
  // ...
});

A maioria das APIs do Google permite definir uma cota de requisições por dia ou por minuto. O Google as descreve como limites de "requests per day, requests per minute, or requests per minute per user" ("requisições por dia, requisições por minuto ou requisições por minuto por usuário") (limitar o uso de APIs) e deixa claro que elas regulam volume, não dinheiro, e entram em vigor com alguma latência. Útil para APIs de IA, em que uma única chave vazada pode gerar milhares de requisições.

As regras de segurança e o App Check impedem que estranhos leiam seu banco de dados ou chamem suas funções callable com a sua fatura. Eles são abordados em detalhes em ataques de negação de carteira.

A única coisa que transforma um orçamento em um limite é algo que aja com base nele. Você pode conectar uma função ao tópico do Pub/Sub do orçamento que desative o faturamento (guia passo a passo faça você mesmo) ou usar o FireShield, que faz isso por você com um passo mais suave antes: um webhook assinado que permite ao seu app se degradar antes que o faturamento seja cortado.

• Projeto pessoal: orçamento + máximo de instâncias nas funções + um Hard Kill automático em 100%. Perder um dia de disponibilidade é melhor do que uma fatura inesperada.
• Produto com usuários: tudo o que foi citado acima, um Soft Kill em um limite mais baixo para que o app se degrade em vez de cair, e detecção de picos nos serviços que podem sair do controle mais rápido.