KasyKasy

Backends

Firebase, Supabase e API REST. Quando usar cada um, o que a CLI faz e o que você precisa fazer manualmente.

Na hora do kasy new, você escolhe um backend. A interface do app é a mesma, só a camada de dados muda. Depois dá para migrar com esforço, mas o ideal é decidir cedo.

Comparativo rápido

FirebaseSupabaseAPI REST
Conta externaGoogle Cloud com plano Blaze ativosupabase.com (free serve)Nenhuma
Banco de dadosFirestore (NoSQL)PostgresO seu
Backend serverlessCloud FunctionsEdge FunctionsNão, você implementa
Deploy automáticokasy deploy (manual)Automático no kasy newNão tem
Login anônimoAutomático (ative no console)Automático (config.toml)Não suportado nativamente
Push notificationSem chave (usa ADC)Precisa de chave JSON do FirebasePrecisa de chave JSON do Firebase
Para quemQuer começar rápido com GoogleQuer SQL e open sourceJá tem servidor próprio

API REST é mais trabalho. A UI é igual aos outros, mas você implementa todos os endpoints (auth, webhooks de Stripe/RevenueCat, push, admin). Se é seu primeiro app, considere Firebase ou Supabase.


Firebase

O que a CLI faz no kasy new

  • Cria o projeto Google Cloud (precisa do plano Blaze, exigido pelas Cloud Functions; é pague-pelo-uso, não assinatura, veja Preparar a máquina)
  • Configura Firebase Auth, Firestore, Cloud Storage
  • Adiciona o SHA-1 do debug keystore automaticamente
  • Baixa google-services.json e GoogleService-Info.plist

O que você faz manualmente

Após o kasy new, abra o Firebase Console:

  1. Authentication → Sign-in method → ative Anônimo (obrigatório no modo padrão)
  2. Cloud Messaging → Apple app config → upload da APNs Key .p8 (para push iOS, veja Push)
  3. Se for usar atualização forçada: Remote Config → crie app_latest_version e app_min_version (veja Atualização do app)

Depois:

kasy deploy   # sobe functions + regras Firestore + regras Storage
kasy run      # inicia o app

No Firebase com login anônimo (padrão), kasy deploy antes do primeiro kasy run. Sem deploy, Auth Triggers não existem no servidor: o app cria a conta anônima mas a função que cria o perfil não roda.


Supabase

Pré-requisito

Faça login uma vez antes do kasy new:

supabase login

Sem isso o kasy new falha no momento do deploy (linka projeto, sobe migrations e Edge Functions).

O que a CLI faz no kasy new

  • Cria o projeto Supabase (ou linka num existente)
  • Modo Rápido (terminal interativo): pergunta se quer push e se quer Google. MCP / kasy new --yes: só push no Supabase/API; Google vem ligado por padrão (independente do push). Sem companion: Google no scaffold e provedor Enabled no Supabase Auth (como Apple); Client ID/Secret depois com kasy google / configure_google_login
  • Avançado com push (ou kasy add notifications depois): cria/vincula companion Firebase só para FCM
  • Roda migrations Postgres + RLS só das features selecionadas (base + módulos do preset ou da sua escolha no Avançado). Sem Drive no modo Rápido; push só se você aceitar na pergunta (ou --push / MCP). Detalhes em Schema do banco (Supabase · Firebase).
  • Faz deploy automático das Edge Functions das mesmas features (Stripe, RevenueCat, push se ligado, IA, admin, etc.)
  • Ativa login anônimo no config.toml (enable_anonymous_sign_ins = true)
  • Desabilita confirmação por e-mail (necessário para o fluxo anônimo → vincular conta)

O que você faz manualmente

  • Google Sign-In: sem push, criar OAuth Web no Console e kasy google (e client Android só se for nativo sem companion). Com push + Google no Rápido, a CLI automatiza OAuth + SHA-1 no companion (sem client Android manual)
  • Para push notifications: aceitar na pergunta do Rápido (--push / MCP), Advanced, ou kasy add notifications; companion Firebase FCM; cadastrar a chave JSON do Service Account se a CLI não gerar (veja Push)
  • Para upgrade de planos no Stripe: cadastrar STRIPE_* secrets (a CLI pede durante o kasy new se você optar por configurar agora)

Diferenças importantes do Firebase

TemaFirebaseSupabase
Habilitar login anônimoConsole manualAutomático (config.toml)
Push notification (FCM)Sem chave (ADC)Precisa do Service Account JSON do Firebase
Alterar secretsfirebase functions:secrets:setsupabase secrets set
Banco de dadosFirestore (NoSQL)Postgres + RLS

RLS (Row Level Security): o Supabase ativa proteção em todas as tabelas. A query SELECT * FROM users só devolve o seu próprio registro, não todos os usuários. Isso é por design e protege contra escalation. Para listar tudo (no admin), use a Edge Function admin-list-users.


API REST

Você implementa o backend

O Kasy te dá o app Flutter completo, mas o backend é seu. O kit documenta todos os contratos que o app espera.

O que a CLI faz no kasy new

  • Gera o Flutter com a camada de dados apontando para REST
  • Cria o BACKEND_URL no .vscode/launch.json (você troca pelo seu)
  • Gera um README.md no projeto com todos os endpoints obrigatórios

O que você implementa

CategoriaEndpoints obrigatórios
AuthPOST /auth/signup, POST /auth/signin, POST /auth/refresh, POST /auth/social
UsuárioGET /users/{id}, PATCH /users/{id}, DELETE /users/{id}
Pushrecebe device tokens, dispara FCM (usa a chave JSON do Firebase)
Stripe (se ligado)POST /webhooks/stripe, POST /stripe/checkout-session, POST /stripe/portal-session, GET /stripe/list-prices
RevenueCat (se ligado)POST /webhooks/revenuecat
NotificaçõesGET/POST /users/{id}/notifications
Admin (se ligado)GET /admin/users, PATCH /admin/feature-requests/{id}
AdMob SSV (se ligado)GET /ads/verify-reward
Chat IA (se ligado)POST /ai/chat

Lista completa com payloads no README.md gerado dentro do seu projeto.

Limitações

  • Login anônimo não funciona nativamente. O kit lança erro se você tentar. Duas saídas:
    • Mude authenticationMode para authRequired em lib/environments.dart (recomendado)
    • Ou implemente POST /auth/guest que cria sessão temporária
  • kasy deploy é no-op no API REST: você sobe o servidor onde quiser
  • kasy check valida só config local: não testa seu backend

Autenticação (Bearer token)

O app envia Authorization: Bearer <jwt> em todas as chamadas. Seu servidor:

  1. Valida a assinatura do JWT
  2. Extrai o sub (user ID) do payload
  3. Aplica permissões a partir daí

Veja o README.md gerado para o esquema completo do token e dos refresh tokens.

Todas as features (push, ads, admin, paywall) funcionam nos três backends. A diferença é só onde os dados ficam e quem implementa o servidor.

Atualizado em 03/11/2026