
O que o Cursor lançou O Cursor lançou em 5 de novembro de 2026 o Build Live Apps, recurso que transforma um prompt em um app web publicado. Até agora, o Cursor escrevia o código e o desenvolvedor cuidava do resto: subir o servidor, criar o banco de dados, configurar o login e publicar. Com o Build Live Apps, um agente em nuvem faz todo esse caminho: monta o app, cria o banco de dados se for preciso, configura o login e provisiona a hospedagem, e devolve um link com o domínio escolhido por você. É a diferença entre receber o código pronto e receber o app no ar. O anúncio saiu no changelog oficial do Cursor, com documentação completa na página de Apps, e vale para todos os planos pagos com agentes em nuvem.
Do prompt ao link publicado O uso começa com uma descrição do que você quer construir. O Cursor sugere prompts de exemplo: um app que mostra as inscrições semanais em um dashboard, com gráfico e tabela filtrável por plano; um app interno para a equipe enviar relatórios de erro e acompanhar o status; um microsite para o lançamento de um produto, com formulário que coleta e-mails; ou simplesmente pedir para publicar um repositório existente como app. Quando o agente termina de preparar o app, ele mostra uma bandeja com a prévia e a publicação. Na hora de publicar, você escolhe a URL do app, que pode ser mudada depois, e o Cursor roda uma série de checagens de segurança. Se tudo passar, ele devolve o link ao vivo. Se alguma checagem falhar, ele lista o que precisa ser corrigido, você pede ao agente para corrigir e publica de novo. Nada vai ao ar antes de você escolher publicar. A demonstração oficial mostra o fluxo completo com um app de mapa de assentos para novos contratados, do pedido ao botão Publish.
Banco de dados, login e hospedagem Cada app é publicado em uma conta de hospedagem dedicada, criada para a sua equipe ou para você, no plano individual, e isolada de todas as outras equipes e usuários. Se o app precisa de banco de dados, o Cursor provisiona um banco Postgres automaticamente. O login usa o Cursor SSO: apps privados e de equipe ficam atrás do login do Cursor, então só quem você compartilhou consegue abrir. Usuários de planos individuais podem compartilhar apps publicamente, sem exigir login do Cursor. O compartilhamento público vem desativado por padrão para Teams e Enterprise, e um administrador pode ligar o recurso no Apps dashboard. Quando o app precisa usar recursos próprios ou se conectar a outros sistemas, como um data warehouse, o Cursor pede os segredos necessários, e o agente nunca vê os valores.
Segurança antes de publicar Antes de cada publicação, rodam quatro checagens que estão sempre ligadas, mesmo quando a revisão de segurança está desligada: bloquear segredos escritos nos arquivos do app, bloquear arquivos de credencial, nunca publicar arquivos .env e nunca publicar source maps. Por cima dessas checagens, uma revisão de segurança por IA lê os arquivos do app e bloqueia problemas graves antes de o app ir ao ar. Administradores de equipe podem acrescentar as próprias instruções ao prompt da revisão, mas não podem remover as checagens embutidas do Cursor. O desenho é claro: a barreira de segurança não depende da atenção de quem publica, e o erro mais comum de quem sobe app na pressa, que é vazar uma chave ou um arquivo de credencial, é travado antes de chegar à internet.
O que o administrador controla O Apps dashboard lista os apps que você criou e os que foram compartilhados com você. O administrador da equipe vê todos os apps e todos os segredos da equipe, e pode despublicar qualquer app. Ele também pode ligar ou desligar o Apps para a equipe, permitir ou bloquear apps públicos, permitir ou bloquear o uso de apps por chaves de API, e aprovar publicações que a revisão bloqueou, exceto nos casos de código malicioso, segredos fixos no código ou credenciais expostas. Quando o administrador bloqueia os apps públicos, os apps públicos existentes voltam para a visibilidade de equipe. Todas as mudanças nessas configurações ficam registradas no log de auditoria da equipe. É o tipo de controle que uma empresa precisa para deixar todo mundo criando apps sem perder a governança.
De onde o app pode nascer O app pode nascer do zero, a partir de um prompt, e nesse caso o Cursor cria um novo repositório no Cursor Origin. Ou pode nascer de um repositório existente do GitHub, que o agente publica como app. O suporte a GitLab está a caminho, segundo o Cursor. Um detalhe importante: o recurso só funciona com agente em nuvem e não tem suporte local, ou seja, é preciso usar o agente em nuvem para construir e publicar o app. As chaves de API também entram no fluxo: uma chave de API do Cursor permite que ferramentas, scripts e trabalhos de integração usem um app do mesmo jeito que um usuário logado usaria. A chave vai no cabeçalho x-cursor-app-token de cada requisição, sem parâmetro na URL e sem cookie, e os pedidos feitos com chave são marcados como automatizados e identificam a chave, nunca uma pessoa.
Exemplos de uso O Cursor cita cinco tipos de uso para o recurso: ferramentas internas de operações, apresentações multimídia, treinamento e onboarding, dashboards de vendas e portais de engenharia. São os apps que quase toda empresa precisa, mas que quase nunca entram na fila de desenvolvimento porque o time de engenharia está ocupado com o produto principal. Com o Build Live Apps, esses apps deixam de depender de uma sprint e passam a nascer de um prompt. O exemplo da demonstração oficial é um mapa de assentos para organizar onde sentam os novos contratados, um app pequeno, útil e que ninguém priorizaria no backlog. É esse tipo de ferramenta interna que o recurso quer destravar.
Preço e disponibilidade O Build Live Apps está disponível em todos os planos pagos com agentes em nuvem. O Cursor não anunciou um plano separado nem um preço avulso para o recurso: ele faz parte dos planos pagos que já incluem agentes em nuvem. Nos termos do recurso, o Cursor deixa claro que só fornece a tecnologia para você usar, sem garantias, e que a publicação de um app não é um endosso do Cursor. Um subdomínio, uma conta associada ou um app publicado pode ser revogado, encerrado ou removido se violar os termos de uso, a política de uso aceitável ou por motivos comerciais ou legais. É a ressalva padrão de quem hospeda conteúdo de terceiros, e vale lembrar dela antes de publicar qualquer coisa com dados sensíveis.
Por que isso importa O Build Live Apps muda o que significa pedir um app a uma IA. Até aqui, os assistentes de código entregavam código, e o caminho até o app no ar continuava sendo trabalho de desenvolvedor: servidor, banco, login, deploy. O Cursor fecha esse caminho e entrega o link. Para equipes pequenas e para quem não programa, isso tira o maior obstáculo entre a ideia e o app funcionando. Para empresas, o valor está no outro lado da moeda: as checagens de segurança automáticas, o controle do administrador e o log de auditoria deixam a criação de apps por qualquer pessoa da equipe acontecer sem virar um risco de vazamento. O risco real passa a ser outro, e mais sutil: publicar rápido demais, sem pensar se o app deveria existir. A tecnologia resolveu o como. O quê e o porquê continuam sendo decisão de quem pede.
Glossário Agente em nuvem: agente de IA que trabalha nos servidores do Cursor, e não no seu computador, e que consegue construir e publicar apps. Cursor Origin: plataforma do Cursor onde novos repositórios são criados quando um app nasce do zero. Postgres: sistema de banco de dados relacional de código aberto, usado para guardar os dados do app. SSO: sigla de single sign-on, o login único que permite entrar com a conta do Cursor em vários serviços. Source map: arquivo que liga o código publicado ao código original, e que pode expor o código-fonte se for publicado junto. Arquivo .env: arquivo que guarda segredos como chaves de API e senhas, e que nunca deve ir para o ar. Log de auditoria: registro de quem mudou o quê nas configurações, usado para acompanhar e investigar alterações. Microsite: site pequeno e focado, feito para um único assunto, como o lançamento de um produto.


