Cursor Cloud Agents agora pode executar ferramentas em infraestrutura controlada pelo cliente usando Cloudflare, Self-Hosted Machines e um template oficial de Workers.
Essa frase precisa de uma precisão importante: isso não significa que Cursor se tornou completamente self-hosted.
Significa algo mais interessante para equipes enterprise.
Cursor continua executando o loop do agente, a inferência, o planejamento, a orquestração e a experiência do produto. Cloudflare executa a parte que normalmente incomoda plataforma e segurança: comandos, edições de arquivos, operações em repositórios, builds, ações de navegador e ferramentas locais dentro de infraestrutura controlada pelo cliente.
Essa é a notícia real.
Durante o último ano, boa parte da conversa sobre agentes de código ficou presa em modelos, integrações com IDEs, benchmarks e se os agentes já são “suficientemente bons” para confiar neles. A pergunta enterprise mais duradoura é outra:
Onde o agente realmente executa?
O changelog do Cloudflare de 2 de setembro de 2026 dá uma arquitetura concreta para essa pergunta.
O que Cloudflare publicou para Cursor Cloud Agents?
Cloudflare publicou uma rota oficial para executar Cursor Cloud Agents mediante Cursor Self-Hosted Machines em Cloudflare Containers.
O tutorial do Cloudflare Sandbox descreve um template implementável baseado em Workers, Durable Objects, Cloudflare Containers, R2 e um cron trigger. O template público vive em anysphere/cloudflare-workers, e isso importa porque não estamos diante de um anúncio de partnership sem artefato nem uma promessa de roadmap.
A implementação documentada cria:
- Um Cloudflare Worker como controlador.
- Um namespace de Durable Objects.
- Uma aplicação de Cloudflare Containers.
- Um binding de R2 para snapshots opcionais de repositórios.
- Um cron trigger que verifica sessões pendentes de Cursor.
Cada sessão atribuída de Cursor executa em seu próprio Cloudflare Container isolado. Cursor continua sendo responsável pela sessão do Cloud Agent e pela orquestração. O container abre uma conexão de saída para Cursor e executa as tool calls que Cursor envia por essa conexão.
Esse modelo apenas de saída é importante. O worker não precisa de uma porta de entrada nem de um IP público para que Cursor entre no ambiente do cliente.
Como Cursor Cloud Agents funciona em Cloudflare?
O padrão separa orquestração de execução.
Um usuário inicia um Cursor Cloud Agent e seleciona um pool self-hosted de equipe. Cursor registra uma solicitação pendente para esse pool. O Worker de Cloudflare atua como controlador: em cada execução agendada, lista solicitações pendentes para o pool configurado, mantém aberto um stream de eventos server-sent durante a janela do controlador, reclama sessões e inicia um container para cada solicitação reclamada.
Para agentes vinculados a um repositório, a solicitação inclui a URL do repositório. O container restaura ou clona esse repositório em $HOME/workspaces/repo-0 e depois inicia o worker de Cursor a partir desse diretório.
A documentação de Cloudflare mostra este comando:
agent worker --worker-dir "$HOME/workspaces/repo-0" --pool "$CURSOR_POOL" start --verbose
Para agentes any-repository, a sessão é roteada por nome do pool de equipe. O container inicia com um diretório de trabalho vazio e sem remoto de Git. O agente, ou um hook do projeto, pode clonar o que precisar durante a sessão.
R2 funciona como cache opcional, não como o centro do sistema. Snapshots de repositórios podem acelerar sessões vinculadas a repo, mas uma cache miss cai para um git clone normal e não impede que o agente inicie.
Este é um padrão prático de runtime: Cursor decide o que o agente tenta fazer; Cloudflare lhe dá um lugar controlado para fazê-lo.
O que fica em Cursor e o que se move para o cliente?
Cursor mantém o loop do agente, a inferência, o planejamento, o acesso ao modelo, o dashboard de Cloud Agents e a orquestração visível para o usuário.
O worker controlado pelo cliente executa as tool calls.
Isso inclui comandos de terminal, edições de arquivos, ações de navegador, operações em repositórios, hooks, ferramentas MCP locais quando disponíveis, acesso a sistemas de build, acesso a registries de pacotes e acesso a serviços internos que o worker possa alcançar.
Essa distinção importa porque “self-hosted” é uma palavra muito carregada.
Se sua política exige que todas as partes do agente, incluindo planejamento e inferência, executem dentro do seu próprio perímetro, esse padrão não atende a esse requisito. Cursor continua no loop.
Se sua política exige que checkouts de código-fonte, execução de comandos, artefatos de build, logs de ferramentas e acesso à rede interna permaneçam dentro de infraestrutura controlada pela empresa, então esse padrão é relevante.
Não é uma nuvem privada de Cursor.
É uma arquitetura híbrida de execução.
E mesmo assim, essa linha é muito significativa.
Por que isso importa para CTOs e CIOs?
Porque adotar agentes em organizações sérias de engenharia já não é apenas uma pergunta sobre qualidade de código.
É uma pergunta sobre modelo operacional.
Um agente que apenas sugere autocompletar representa um tipo de risco. Um agente cloud que clona repositórios privados, instala dependências, executa testes, toca serviços internos, edita arquivos, produz artefatos e comenta PRs representa outro.
As perguntas de governança aparecem rápido:
- Onde vive o checkout do repositório?
- Onde vivem os outputs de build e os caches?
- Que serviços internos o worker pode alcançar?
- Que secrets estão disponíveis para o runtime do agente?
- Quem controla a imagem do worker?
- Quem dimensiona a capacidade?
- O que acontece quando um rollout de container interrompe uma sessão ativa?
- Onde os logs do worker são retidos?
- Que artefatos saem do ambiente e aparecem em dashboards de Cursor ou em PRs?
O template de Cloudflare não responde tudo para você. A própria documentação de Cursor é clara: arquiteturas de referência não são plataformas administradas de produção. O cliente é dono da imagem do worker, da infraestrutura, dos secrets, da política de dimensionamento e da validação produtiva.
Mas o template transforma essas perguntas em decisões operáveis, não em debate abstrato.
Isso já é progresso.
Por que Cloudflare funciona como runtime para agentes?
Cloudflare não é o único lugar onde você pode executar Cursor Self-Hosted Machines. A documentação de Cursor menciona máquinas pessoais, hosts persistentes, containers, infraestrutura dinâmica, Kubernetes, Cloud Run e templates de parceiros como AWS Lambda, Cloudflare, Namespace, Modal, Daytona, E2B, Vercel e Coder.
A rota de Cloudflare é interessante porque o controlador também é um Worker.
Você não precisa manter um serviço tradicional de longa duração apenas para verificar se há sessões pendentes. O cron trigger executa a cada cinco minutos. Durante uma execução do controlador, o Worker lista solicitações pendentes, mantém aberto o stream de eventos de Cursor até a próxima execução agendada, reclama sessões e inicia containers isolados mediante um Durable Object.
O resultado é um controlador de pool com sabor serverless para execução agêntica.
Isso não elimina a complexidade. A move para lugares que os times de plataforma podem raciocinar: wrangler.jsonc, secrets de Workers, Durable Objects, limites de containers, snapshots em R2, rollouts de imagens, logs e política de rede de saída.
Para equipes que já usam Cloudflare como parte de sua borda, segurança ou plataforma de desenvolvimento, esse plano de controle resulta familiar.Também se conecta bem com uma linha que yoDEV já vem acompanhando: Cloudflare não está apenas expondo serviços de infraestrutura, também está convertendo peças como Browser Run em blocos programáveis para workflows de desenvolvimento. Essa leitura aparece em nossa análise de Cloudflare Browser Run.
Que requisitos tem Cursor Cloud Agents no Cloudflare?
No momento de publicar esta nota, 3 de setembro de 2026, isto não é uma receita casual para usuários individuais.
O tutorial do Cloudflare requer:
- Um plano Cursor Enterprise com Self-Hosted Machines habilitado.
- Uma chave de API de conta de serviço do Cursor com escopo de agente.
- Uma conta Cloudflare Workers Paid com acesso a Containers e R2.
- Node.js 20 ou posterior.
- Um daemon do Docker ativo para deployment e desenvolvimento local.
A configuração também espera Wrangler, um pool de time do Cursor, um CURSOR_POOL configurado e secrets de Worker como CURSOR_API_KEY. Se os agentes precisam de repositórios privados, a documentação do Cloudflare mostra GIT_USERNAME e GIT_TOKEN como secrets de Worker; para GitHub, GIT_USERNAME deve ser x-access-token.
A concorrência também é explícita. O deployment usa containers[].max_instances, e Cloudflare indica que deve ser ajustado ao máximo de requisições concorrentes que o deployment precisa suportar.
Isso é uma decisão de capacidade, não uma caixa de seleção.
Há outro detalhe operacional: Cloudflare adverte que um rollout de nova imagem de contêiner interrompe contêineres em execução. Se os agentes estão trabalhando em tarefas longas, os deployments precisam da mesma disciplina de mudança que você aplicaria a workers de CI ou automação produtiva.
Que deveria observar um time de segurança?
O ponto de segurança mais importante é quase entediante, o que costuma ser sinal de que é real.
Executar o worker dentro da sua infraestrutura não torna o agente seguro por padrão.
Torna a fronteira mais clara.
O worker pode ficar mais próximo de repositórios privados, registries de pacotes, APIs de staging, secrets de build, bancos de dados de teste, dashboards internos ou sistemas legados. Essa é exatamente a razão pela qual essa arquitetura é útil. Também é a razão pela qual o modelo de permissões importa.
Um teste sério deveria decidir:
- Que repositórios o worker pode clonar.
- Que tokens recebe.
- A que registries de pacotes pode acessar.
- Que hosts internos pode alcançar.
- Que hooks rodam antes ou durante o trabalho do agente.
- Que artefatos podem ser enviados de volta para Cursor.
- Que logs permanecem no Cloudflare.
- Que pools correspondem a que níveis de risco, times, repositórios ou ambientes.
Os Team Pools do Cursor ajudam neste ponto porque funcionam como targets de roteamento. Um pool pode representar um time, um grupo de repositórios, uma classe de hardware, um ambiente de staging ou um nível de risco. A documentação do Cursor descreve labels para rotear trabalho, e os administradores podem permitir que usuários optem por execuções self-hosted ou exigir que execuções de Cloud Agent vão para workers self-hosted.
Aí isto deixa de ser encanamento de deployment e se torna arquitetura de governança.
Que deveria testar uma empresa antes de adotá-lo?
Um teste útil não deveria começar com uma app de brinquedo.
Deveria começar com um workflow pequeno, real e dentro de um ambiente limitado.
Por exemplo:
- Um repositório privado com baixo raio de impacto.
- Um pool de time dedicado do Cursor.
- Um deployment do Cloudflare com
max_instancesconservador. - Uma service-account key com escopo para autenticar pool workers.
- Credenciais de Git mínimas para o repositório de teste.
- Uma imagem de contêiner com apenas as ferramentas necessárias para o workflow.
- Um caminho de build ou test que toque uma dependência interna.
- Logs revisados por plataforma e segurança.
- Um rollout de imagem planejado depois que as sessões ativas terminarem.
A condição de sucesso não é “o agente fez uma mudança”.
A condição de sucesso é que o time entenda o que acontece quando algo falha: falta de capacidade, credenciais de Git incorretas, secrets ausentes, clones frios, cache miss no R2, instalação quebrada de ferramentas, rollouts interrompidos e falha de conectividade de saída.
A infraestrutura de agentes é infraestrutura. Merece testes de falha.
Qual é o sinal maior?
O sinal maior é que agentes de código estão se tornando arquitetura de runtime.
Para desenvolvedores individuais, a pergunta costuma parecer “qual IDE tem o melhor agente”. Se você precisa desse marco mais básico, yoDEV já tem uma introdução sobre o que é Cursor e por que importa, além de uma comparação prática de Cursor vs VS Code.
Para times enterprise, a pergunta está se tornando outra: onde o trabalho do agente é executado e sob que controles.
Cloudflare e Cursor mostram uma resposta plausível: manter a experiência comercial do agente, mas mover a superfície de execução para infraestrutura controlada pelo cliente.
Não é independência local-first. Não é um substituto open source do Cursor. Não é uma solução universal de compliance.
É uma camada intermediária pragmática.
E a adoção enterprise de software costuma ocorrer precisamente nesse tipo de camada intermediária: não cloud puro, não self-hosted puro, mas uma fronteira que permite a plataforma, segurança e engenharia dizer que sim sem fingir que o risco desapareceu.
Por que importa agora?
A próxima fase dos agentes de código não será decidida apenas por qualidade de modelo.
Será decidida por fronteiras de execução.
Os times que adotarem agentes em profundidade precisarão de respostas sobre localização do código-fonte, execução de comandos, alcance de rede, secrets, logs, artefatos, imagens de workers e auditoria. O template do Cloudflare para Cursor é um dos exemplos públicos mais claros dessa arquitetura se tornando real.
A pergunta já não é apenas se um agente consegue escrever código útil.
A pergunta é que parte do agente você está disposto a executar onde.