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
| Firebase | Supabase | API REST | |
|---|---|---|---|
| Conta externa | Google Cloud com plano Blaze ativo | supabase.com (free serve) | Nenhuma |
| Banco de dados | Firestore (NoSQL) | Postgres | O seu |
| Backend serverless | Cloud Functions | Edge Functions | Não, você implementa |
| Deploy automático | kasy deploy (manual) | Automático no kasy new | Não tem |
| Login anônimo | Automático (ative no console) | Automático (config.toml) | Não suportado nativamente |
| Push notification | Sem chave (usa ADC) | Precisa de chave JSON do Firebase | Precisa de chave JSON do Firebase |
| Para quem | Quer começar rápido com Google | Quer SQL e open source | Já 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.jsoneGoogleService-Info.plist
O que você faz manualmente
Após o kasy new, abra o Firebase Console:
- Authentication → Sign-in method → ative Anônimo (obrigatório no modo padrão)
- Cloud Messaging → Apple app config → upload da APNs Key
.p8(para push iOS, veja Push) - Se for usar atualização forçada: Remote Config → crie
app_latest_versioneapp_min_version(veja Atualização do app)
Depois:
kasy deploy # sobe functions + regras Firestore + regras Storage
kasy run # inicia o appNo 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 loginSem 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 comkasy google/configure_google_login - Avançado com push (ou
kasy add notificationsdepois): 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, oukasy 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 okasy newse você optar por configurar agora)
Diferenças importantes do Firebase
| Tema | Firebase | Supabase |
|---|---|---|
| Habilitar login anônimo | Console manual | Automático (config.toml) |
| Push notification (FCM) | Sem chave (ADC) | Precisa do Service Account JSON do Firebase |
| Alterar secrets | firebase functions:secrets:set | supabase secrets set |
| Banco de dados | Firestore (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_URLno.vscode/launch.json(você troca pelo seu) - Gera um
README.mdno projeto com todos os endpoints obrigatórios
O que você implementa
| Categoria | Endpoints obrigatórios |
|---|---|
| Auth | POST /auth/signup, POST /auth/signin, POST /auth/refresh, POST /auth/social |
| Usuário | GET /users/{id}, PATCH /users/{id}, DELETE /users/{id} |
| Push | recebe 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ções | GET/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
authenticationModeparaauthRequiredemlib/environments.dart(recomendado) - Ou implemente
POST /auth/guestque cria sessão temporária
- Mude
kasy deployé no-op no API REST: você sobe o servidor onde quiserkasy checkvalida só config local: não testa seu backend
Autenticação (Bearer token)
O app envia Authorization: Bearer <jwt> em todas as chamadas. Seu servidor:
- Valida a assinatura do JWT
- Extrai o
sub(user ID) do payload - 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

