AIREITERA maior parte dos apps criados com IA não passa do localhost. O Build Live Apps, lançado pelo Cursor em 5 de novembro, quer resolver justamente essa etapa. Depois de consultar o changelog, a documentação e as primeiras dúvidas de usuários, a conclusão é clara: ele é uma boa opção para ferramentas internas e protótipos protegidos pelo SSO do Cursor, mas ainda não substitui uma infraestrutura de produção para backends complexos ou sujeitos a requisitos de compliance.
O que o Build Live Apps entrega na prática
O Build Live Apps é um fluxo com agente na nuvem que transforma uma solicitação em linguagem natural em um app web publicado. O Cursor anunciou o recurso em seu changelog em 5 de novembro de 2026, e a documentação do Apps descreve a mesma sequência: você pede o app ao agente, visualiza uma prévia em uma bandeja, escolhe uma URL, passa pelas verificações de segurança e publica um link ativo.
O pedido precisa ser direto. Segundo a documentação do Cursor, o prompt deve instruir o agente a criar um app. É possível começar do zero no Cursor Origin, que gera um novo repositório, ou partir de um repositório existente no GitHub, que será implantado pelo Cursor. Apenas agentes na nuvem podem criar apps.
Quando há necessidade de persistência, o Cursor provisiona um banco PostgreSQL. A hospedagem fica em uma conta isolada e dedicada para cada usuário ou equipe. Nos apps de equipe, a autenticação é feita pelo Cursor SSO: quem recebe o link precisa entrar no Cursor antes de acessar o app. Usuários de planos individuais também podem publicar apps públicos, sem exigir login.
Há restrições importantes desde o início. O suporte ao GitLab está planejado, mas ainda não existe. Domínios personalizados também não foram confirmados. O Cursor informa que quem publica escolhe um domínio exclusivo, e a documentação diz que a URL pode ser alterada depois, mas nenhuma das páginas apresenta um fluxo para domínio próprio.
Nenhuma página informa frameworks, runtimes, regiões, versão do Postgres, backups, comportamento de escalabilidade, cotas de banda ou SLA. A hospedagem é juridicamente separada dos serviços do Cursor e é oferecida "no estado em que se encontra" e "conforme disponível"; o Cursor também reserva o direito de revogar ou suspender um subdomínio ou app.
Publicação exige 4 verificações obrigatórias, além da análise por IA
Nada fica público sem uma ação explícita do usuário. Preparar o app não o expõe automaticamente. Toda publicação executa quatro verificações obrigatórias, que continuam ativas mesmo quando a equipe desabilita a análise adicional por IA:
- Impedir a publicação se os arquivos do app contiverem uma chave de API ou token de acesso.
- Bloquear arquivos de credenciais, como chaves privadas ou chaves de contas de serviço.
- Excluir arquivos
.envdo pacote publicado. - Remover source maps para que visitantes não consigam reconstruir o código-fonte original pelo navegador.
Se uma verificação falhar, o Cursor mostra o problema, e o usuário pode pedir que o agente faça a correção antes de tentar publicar novamente.
A análise de segurança adicional por IA lê os arquivos da aplicação e pode bloquear problemas graves antes da publicação. Administradores de equipe podem acrescentar instruções específicas da organização ao prompt dessa análise. Essas instruções adicionam regras, mas não podem remover nem enfraquecer as verificações nativas do Cursor. Administradores podem ignorar alguns bloqueios de publicação, mas não conseguem ignorar bloqueios relacionados a código malicioso, segredos codificados diretamente no código ou credenciais expostas. Alterações nessas configurações aparecem no log de auditoria da equipe.
Mais importante do que o que essa barreira detecta é o que ela não consegue comprovar:
"O ponto é: passar nas verificações de segurança não prova que seu app concede o acesso certo às pessoas certas." — @0node0, usuário real
O Cursor cita segredos e credenciais expostas como exemplos. Mas não afirma que cada app receba testes de autorização, permissões em nível de linha, cobertura contra injeção SQL, análise de dependências ou revisão de lógica de negócio. A análise da TechRepublic de 6 de novembro chega ao mesmo alerta: teste com várias contas e níveis de permissão diferentes, pois não há indicação de que o caso de um usuário autenticado ler os registros de outro esteja coberto.
Preço, Vercel e segredos: as dúvidas mais comuns
A hospedagem tem custo extra? O Cursor não publicou um preço separado para hospedagem ou banco de dados. O Build Live Apps não tem assinatura própria: ele está incluído em planos pagos com acesso a agentes na nuvem. Os números concretos disponíveis vêm da tabela de planos da TechRepublic, e não das páginas do recurso do Cursor:
| Plano | Preço listado | Acesso ao Build Live Apps |
|---|---|---|
| Plus | US$ 8/mês | Não, sem agentes na nuvem |
| Premium | US$ 30/mês | Sim, menor plano individual elegível |
| Super | US$ 100/mês | Sim, franquia de uso maior |
| Ultra | US$ 200/mês | Sim, maior franquia listada |
| Team | A partir de US$ 30/usuário/mês | Sim, adiciona controles administrativos |
| Enterprise | Personalizado | Sim, conforme a política |
O Cursor usa uma franquia semanal compartilhada de uso de IA (detalhamento de planos da TechRepublic), mas, nessas páginas, não divulga números de tokens, requisições ou computação por faixa. Modelos de terceiros podem gerar cobranças separadas (TechRepublic). Os limites de banco, armazenamento, tráfego e concorrência não foram informados. Encare os US$ 30 como o ingresso de entrada, não como o custo operacional total, e confirme as cotas antes de colocar uma carga voltada ao cliente na hospedagem integrada.
O Build Live Apps substitui a Vercel? Ainda não, para backends de produção complexos ou sensíveis a compliance. O caminho integrado atende bem a Postgres, SSO e um link para compartilhar. Já o fluxo tradicional, com GitHub e Vercel, Netlify, Railway, Render ou uma VPS, continua sendo o caminho para arquiteturas personalizadas e dados regulados; a tabela abaixo detalha a divisão por cenário. Em discussões sobre hospedagem no Reddit, o critério se repete: o nível de estado e de execução prolongada da carga define a plataforma mais adequada.
"A maioria das demos do Cursor que vejo na minha timeline se concentra na UI… e a maioria não está publicada para usuários pagantes reais." — @mayowaoshin, usuário real
Onde ficam os segredos? O agente consegue vê-los? A documentação do Cursor afirma que o agente de programação nunca vê os valores dos segredos. Apps que precisam de um data warehouse ou API externa solicitam esses segredos ao usuário. Em geral, os segredos de equipe são criados por um administrador no painel Apps ou adicionados posteriormente pelo mesmo painel.
Administradores de equipe conseguem ver todos os apps e segredos da equipe. Isso oferece governança, mas também representa uma fronteira de confiança a considerar antes de colar chaves de produção. Clientes automatizados, como scripts, jobs de CI e o Grok Bot, acessam apps protegidos com uma chave enviada em cabeçalho (x-cursor-app-token), e não com cookies ou parâmetros de query.
Quando usar o Live Apps e quando manter o deploy tradicional
| Situação | Live Apps integrado | Deploy tradicional (Vercel / Railway / VPS) |
|---|---|---|
| Painel interno, rastreador de inscrições ou portal de onboarding protegido por SSO | Melhor encaixe, caminho mais rápido até um link compartilhável | Exagero, salvo se o app ultrapassar as cotas |
| Microsite público de marketing com formulário de e-mail | Funciona em planos individuais com compartilhamento público | Use o caminho tradicional se precisar de domínio próprio, analytics ou cache de borda |
| App que exige Postgres, Cursor SSO e possibilidade administrativa de despublicar | Nativo, com conta de hospedagem isolada, publicação explícita e log de auditoria | Exige reconstruir manualmente autenticação, banco e barreiras de revisão |
| Autenticação própria, SAML/OIDC além do Cursor ou esquema Supabase intenso em RLS | Arriscado: o modelo de permissões não está comprovado e administradores veem segredos | Use o caminho tradicional e controle a camada de autenticação e dados |
| Backend de longa execução, workers, cron, WebSockets ou armazenamento não Postgres | Não documentado, sem especificação de runtime ou escalabilidade | Use o caminho tradicional se precisar de qualquer um desses itens |
| Código-fonte no GitLab, fluxo com agente local ou residência/SLA regulados | Bloqueado: apenas GitHub ou Origin, com agentes na nuvem e hospedagem no estado em que se encontra | Use o caminho tradicional |
| Pagamentos em produção, webhooks ou PII | Apenas piloto: passe pelas verificações e valide a autorização de forma independente | Use o caminho tradicional com staging, proteção de branches e chaves restritas |
O caminho tradicional mantém seu próprio trabalho de configuração: MCP, credenciais de hospedagem, variáveis de ambiente e endurecimento de RLS. É o que mostra a jornada de quatro semanas de um desenvolvedor, de uma landing page à Vercel e à autenticação do Supabase.
Checklist antes de compartilhar um app
As verificações do Cursor ajudam a evitar segredos vazados e arquivos de credenciais. Ainda restam riscos ligados a permissões, configuração de ambientes, efeitos assíncronos e código que ninguém revisou. Passe por esta lista antes do primeiro compartilhamento, mesmo em uma ferramenta interna.
- Faça um build limpo e revise o diff. Peça ao agente para executar o build real de produção, não apenas o servidor de desenvolvimento. Abra cada arquivo alterado relacionado a pagamentos, autenticação e gravação de dados. Se o projeto já cresceu a ponto de o diff não ser revisável, volte a um checkpoint e divida a tarefa, em vez de seguir empilhando prompts sobre a bagunça.
- Teste permissões com duas contas. Entre como administrador e como membro com acesso restrito. Crie um registro como usuário A e tente ler, editar e excluí-lo como usuário B. Um relatório de segurança aprovado não prova que a propriedade dos registros está correta.
- Audite os segredos de ponta a ponta. Confirme que nenhuma chave foi incluída no código de frontend, que nenhum
.envfoi publicado e que cada credencial externa tem o menor escopo que ainda permite seu funcionamento. Remova URLs diretas de bancos de produção do ambiente acessível ao agente. Um relato no r/cursor descreve o Cursor fazendo deploy diretamente no Supabase de produção, em vez de passar pelo GitHub. - Coloque os fluxos assíncronos à prova. Dispare um webhook real, repita a tentativa e interrompa-o no meio da execução. Verifique o comportamento do pool de conexões sob uso concorrente. Falhas silenciosas em webhooks e pools esgotados são problemas que usuários relatam descobrir apenas depois do lançamento.
- Defina atualização e rollback. Confirme quem pode publicar, quem pode ignorar um bloqueio de publicação, quem pode despublicar e para onde vai o log de auditoria. Documente como uma publicação problemática será revertida e como ocorrerá uma migração de esquema, pois a documentação fala de publicação, mas não de histórico de versões ou rollback.
"Quando um app sai do localhost, seus segredos vão junto." — @1PasswordDev, usuário real sobre isolamento de segredos por app
Se qualquer item acima não tiver resposta — por exemplo, não há projeto de staging, segunda conta de teste ou rollback — mantenha o app em um link restrito à equipe ou na stack tradicional até resolver a lacuna.
Perguntas frequentes
O Build Live Apps exige um plano pago do Cursor?
Sim. O Build Live Apps funciona apenas em planos pagos com agentes na nuvem habilitados. O Plus, de US$ 8/mês, não se qualifica. O Premium, de US$ 30/mês, é o plano individual elegível mais barato.
O Cursor pode criar um app a partir do meu repositório existente?
Sim, a partir de um repositório existente no GitHub ou do zero no Cursor Origin. O GitLab está planejado, mas indisponível, e agentes locais não podem criar apps.
Um app de equipe pode ser público?
Os planos Team e Enterprise desativam o compartilhamento público por padrão. Um administrador pode habilitá-lo no painel Apps. Planos individuais podem publicar apps públicos diretamente.
O Cursor aceita domínios personalizados?
O Cursor informa que quem publica escolhe um domínio exclusivo e pode alterá-lo depois, mas nem o changelog nem a documentação confirmam o mapeamento de domínio próprio. Considere que a URL será gerenciada pelo Cursor até que ele documente o contrário.
Como scripts ou bots acessam um app privado?
Crie uma chave de API do Cursor e envie-a em todas as requisições no cabeçalho x-cursor-app-token. Chaves pessoais abrem tudo o que o proprietário pode acessar. Chaves de equipe abrem apenas os apps de equipe aos quais receberam permissão explícita.
O que acontece quando eu despublico um app?
Administradores podem despublicar qualquer app de equipe, e desativar apps públicos faz os apps públicos existentes voltarem à visibilidade exclusiva da equipe. O Cursor não documenta retenção, backup ou exportação de dados após a despublicação.
O Build Live Apps elimina a configuração de hospedagem entre um protótipo funcional e um link utilizável. Ele não elimina a revisão, os testes de permissão e o trabalho de definir responsáveis, que determinam se outra pessoa poderá usar o resultado com segurança.
Leia também: Best LLM for Coding Agents 2026 · Cursor Projects Beta Review · Cursor Router Explained