KasyKasy

Criar seu primeiro app

Crie o projeto pelo MCP ou com kasy new. Firebase, Supabase ou API REST.

Com a máquina preparada, escolha um caminho.

Ainda sem nome? Use um provisório e comece. Depois é só pedir "troca o nome do app" ao assistente (ou kasy rename), que o Kasy atualiza tudo. O ID do app (com.seuapp.app) também pode mudar, mas só até o primeiro envio para as lojas. Veja Nome do app.

Implementação

1. Caminho recomendado: MCP

Peça ao assistente:

Cria um projeto com o Kasy

Antes de qualquer pergunta, o assistente deve te oferecer a escolha: Rápido (aqui no chat — poucas perguntas, pacote completo menos Drive) ou Avançado (feature por feature, só no terminal com kasy new). Ele recomenda Rápido, mas nos dois caminhos dá pra adicionar ou remover feature depois (kasy add/kasy remove, ou add_feature/remove_feature no chat) — escolher Rápido não te trava em nada. Se você preferir Avançado, ele te diz pra abrir um terminal: o MCP não roda o modo interativo.

Escolhendo Rápido, ele pergunta nome e backend (Firebase, Supabase ou API REST) e usa create_project. Sem digitar no terminal.

Fluxo esperado do assistente:

  1. prepare_machine (máquina ok?)
  2. check_kasy_updates → upgrade_kasy + reiniciar o cliente se precisar
  3. configure_license se o usuário já tiver a chave (evita falha no meio do scaffold)
  4. AskQuestion: pasta, backend, região (Supabase/API), push (Supabase/API)
  5. create_project

No Supabase ou API, o assistente pergunta só push (não pergunta Google separado; Google vem ligado por padrão):

  • Push sim: push=true (push + projeto Firebase companion gratuito para FCM; Google OAuth pode ser configurado automaticamente nesse passo e registrado no Supabase Auth).
  • Push não: sem Firebase companion. Google continua no scaffold; Client ID/Secret + ativar o provedor no Console do Supabase: configure_google_login depois.

2. Caminho alternativo: terminal

Com a CLI global:

kasy new

A CLI pergunta:

  1. Nome do projeto (cria a pasta)
  2. Backend: Firebase, Supabase ou API REST
  3. Modo Rápido ou Passo a passo
  4. No Rápido + Supabase/API (terminal interativo): quer push? quer Google? (ver Autenticação e Backends). No MCP, Google vem ligado por padrão (independente do push); sem companion, credenciais depois com configure_google_login.
  5. No Rápido (Firebase ou Supabase), a CLI pergunta se conecta o backend agora ou depois. Depois gera o app em modo preview (navegável, sem contas reais) até você rodar kasy backend ou o MCP configure_backend. Ignorado no backend API (não há projeto remoto pra adiar).

Modo preview (configure later): no Device Preview com aba iPhone/Android/iPad e storage limpo (aba privada ou ?kasy_clear_storage=1), a primeira visita abre o onboarding. Na aba Desktop, vai direto pra Home (fluxo web SaaS). Login social mostra aviso até conectar o backend; email/senha navega com stubs.

  1. No Passo a passo: multiselect de features (pode ligar/desligar Auth, Settings, Push, etc.)

Depois dá pra adicionar ou remover com kasy add / kasy remove (ex.: kasy add notifications cria o companion FCM no Supabase/API; kasy remove notifications tira o módulo e deixa stubs NoOp). Projeto antigo não muda sozinho; só quando você roda add/remove/update.

3. Depois de criar (os dois caminhos)

Firebase: deploy separado, antes do primeiro boot:

cd nome_do_seu_app
kasy deploy
kasy run

No Firebase com login anônimo (padrão), rode kasy deploy antes do primeiro kasy run. Sem deploy, Auth e Functions não existem no servidor.

Pelo MCP, peça: "faz o deploy do Firebase e sobe o app". Ele usa deploy_backend e depois run_app (pergunta se é iOS, Android ou web).

Supabase: deploy já roda no new. Basta:

cd nome_do_seu_app
kasy run

API REST: sem deploy. Aponte BACKEND_URL no .vscode/launch.json:

cd nome_do_seu_app
kasy run

Próximo passo: rodar o app.

Informações

Modo Rápido vs Passo a passo

ModoPara quem
RápidoQuer tudo ligado e começar logo (é o que o MCP usa)
Passo a passoQuer escolher cada feature no terminal

Cada projeto trava sua própria versão do Flutter (kasy-cli ≥ 1.75.0)

Todo app criado pelo kasy new (ou pelo create_project do MCP) agora fixa a versão do Flutter usada só naquele projeto, via FVM. Isso evita o problema clássico: atualizar o Flutter pra um projeto novo e um projeto antigo parar de compilar.

Funciona sozinho, sem passo manual:

  1. Durante a preparação da máquina (kasy doctor / prepare_machine), o FVM é instalado se ainda não tiver.
  2. Ao criar o projeto, a CLI resolve a versão "stable" atual e grava um arquivo .fvmrc na raiz do projeto, travando aquele número exato.
  3. Todo comando que a CLI roda dentro daquele projeto (kasy run, kasy add/remove/update, builds de release, etc.) já usa a versão travada automaticamente.

Não precisa fazer nada diferente. flutter run, flutter pub get etc. digitados direto no terminal continuam indo pro Flutter global da sua máquina; use fvm flutter/fvm dart, ou os comandos kasy (que já sabem da versão travada), se quiser rodar exatamente o que está pinado.

Se o FVM não conseguir instalar ou travar a versão (sem internet, por exemplo), o projeto nasce sem .fvmrc e usa o Flutter global normalmente, do jeito que sempre funcionou. Não trava a criação do app.

Projetos criados antes dessa versão não ganham .fvmrc automaticamente: a versão travada só se aplica a projetos novos.

Atualizado em 03/11/2026

Preparar a máquina

Flutter, Node e CLIs de backend prontos. Pelo MCP ou pelo terminal, antes de criar o app.

Rodar o app

Use kasy run no dia a dia. Simulador, device físico, web na porta 5555 e kasy reset para testar do zero.

Nesta página

Implementação1. Caminho recomendado: MCP2. Caminho alternativo: terminal3. Depois de criar (os dois caminhos)InformaçõesModo Rápido vs Passo a passoCada projeto trava sua própria versão do Flutter (kasy-cli ≥ 1.75.0)