Cursor Cloud Agents agora pode executar ferramentas em infraestrutura controlada pelo cliente usando Cloudflare, Self-Hosted Machines e um modelo oficial de Workers.
Essa frase precisa de um esclarecimento 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 a 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 é executado?
O changelog do Cloudflare de 2 de setembro de 2026 dá uma arquitetura concreta a essa pergunta.
O que Cloudflare publicou para Cursor Cloud Agents?
Cloudflare publicou uma rota oficial para executar Cursor Cloud Agents através de Cursor Self-Hosted Machines em Cloudflare Containers.
O tutorial do Cloudflare Sandbox descreve um modelo implementável baseado em Workers, Durable Objects, Cloudflare Containers, R2 e um acionador cron. O modelo público fica em anysphere/cloudflare-workers, e isso importa porque não estamos diante de um anúncio de parceria sem artefato ou uma promessa de roadmap.
A implementação documentada cria:
- Um Cloudflare Worker como controlador.
- Um namespace de Durable Objects.
- Uma aplicação Cloudflare Containers.
- Uma vinculação R2 para snapshots opcionais de repositórios.
- Um acionador cron que verifica sessões pendentes de Cursor.
Cada sessão atribuída de Cursor é executada em seu próprio Cloudflare Container isolado. Cursor continua 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 chamadas de ferramenta que Cursor envia por essa conexão.
Esse modelo somente de saída é importante. O worker não precisa de uma porta de entrada ou IP público para que Cursor entre no ambiente do cliente.
Como o Cursor Cloud Agents funciona no Cloudflare?
O padrão separa orquestração de execução.
Um usuário inicia um Cursor Cloud Agent e seleciona um pool de equipe self-hosted. Cursor registra uma solicitação pendente para esse pool. O Worker do Cloudflare atua como controlador: em cada execução programada, lista solicitações pendentes para o pool configurado, mantém aberto um fluxo 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 desse diretório.
A documentação do Cloudflare mostra esse comando:
agent worker --worker-dir "$HOME/workspaces/repo-0" --pool "$CURSOR_POOL" start --verbose
Para agentes de qualquer repositório, a sessão é roteada pelo nome do pool de equipe. O container inicia com um diretório de trabalho vazio e sem remoto 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 repositório, mas um cache miss cai para um git clone normal e não impede que o agente seja iniciado.
Esse é 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 no 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 chamadas de ferramenta.
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 registros 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 de 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 de execução híbrida.
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 não é mais apenas uma pergunta sobre qualidade de código.
É uma pergunta sobre modelo operacional.
Um agente que apenas sugere preenchimento automático 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 rapidamente:
- Onde fica o checkout do repositório?
- Onde ficam os outputs de build e caches?
- Quais serviços internos o worker pode alcançar?
- Quais segredos estão disponíveis para o runtime do agente?
- Quem controla a imagem do worker?
- Quem escala a capacidade?
- O que acontece quando um rollout de container interrompe uma sessão ativa?
- Onde os logs do worker são retidos?
- Quais artefatos saem do ambiente e aparecem em dashboards do Cursor ou em PRs?
O modelo do Cloudflare não responde tudo para você. A própria documentação do Cursor é clara: as arquiteturas de referência não são plataformas gerenciadas de produção. O cliente é dono da imagem do worker, da infraestrutura, dos segredos, da política de escalabilidade e da validação produtiva.
Mas o modelo converte essas perguntas em decisões operacionais, não em debate abstrato.
Isso já é progresso.
Por que Cloudflare se encaixa como runtime para agentes?
Cloudflare não é o único lugar onde você pode executar Cursor Self-Hosted Machines. A documentação do Cursor menciona máquinas pessoais, hosts persistentes, containers, infraestrutura dinâmica, Kubernetes, Cloud Run e modelos de parceiros como AWS Lambda, Cloudflare, Namespace, Modal, Daytona, E2B, Vercel e Coder.
A rota do 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 acionador cron é executado a cada cinco minutos. Durante uma execução do controlador, o Worker lista solicitações pendentes, mantém aberto o fluxo de eventos do Cursor até a próxima execução programada, reclama sessões e inicia containers isolados através de um Durable Object.
O resultado é um controlador de pool com sabor serverless para execução de agentes.
Isso não elimina a complexidade. Move para lugares que as equipes de plataforma podem raciocinar: wrangler.jsonc, segredos 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 é familiar.
Também se conecta bem com uma linha que yoDEV já vem seguindo: 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.
Quais são os requisitos do Cursor Cloud Agents no Cloudflare?
No momento da publicação desta nota, 3 de setembro de 2026, isso não é uma receita casual para usuários individuais.
O tutorial do Cloudflare exige:
- Um plano Cursor Enterprise com Self-Hosted Machines habilitado.
- Uma chave 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 Docker ativo para implementação e desenvolvimento local.
A configuração também espera Wrangler, um pool de equipe Cursor, um CURSOR_POOL configurado e segredos de Worker como CURSOR_API_KEY. Se os agentes precisarem de repositórios privados, a documentação do Cloudflare mostra GIT_USERNAME e GIT_TOKEN como segredos de Worker; para GitHub, GIT_USERNAME deve ser x-access-token.
A concorrência também é explícita. A implementação usa containers[].max_instances, e Cloudflare indica que deve ser ajustada ao máximo de solicitações concorrentes que a implementação precisa suportar.
Essa é uma decisão de capacidade, não uma caixa de seleção.
Há outro detalhe operacional: Cloudflare avisa que um rollout de nova imagem de container interrompe containers 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.
O que uma equipe de segurança deveria verificar?
O ponto de segurança mais importante é quase entediante, o que geralmente é sinal de que é real.
Executar o worker dentro de sua infraestrutura não torna o agente seguro por padrão.
Torna a fronteira mais clara.
O worker pode ficar mais perto de repositórios privados, registros de pacotes, APIs de staging, segredos 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:
- Quais repositórios o worker pode clonar.
- Quais tokens recebe.
- A quais registros de pacotes pode acessar.
- Quais hosts internos pode alcançar.
- Quais hooks são executados antes ou durante o trabalho do agente.
- Quais artefatos podem ser enviados de volta para Cursor.
- Quais logs permanecem no Cloudflare.
- Quais pools correspondem a quais níveis de risco, equipes, repositórios ou ambientes.
Os Team Pools do Cursor ajudam nesse ponto porque funcionam como destinos de roteamento. Um pool pode representar uma equipe, 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 rótulos para rotear trabalho, e os administradores podem permitir que os usuários optem por execuções self-hosted ou exigir que as execuções do Cloud Agent vão para workers self-hosted.
Aí isso deixa de ser encanamento de implementação e se torna arquitetura de governança.
O que uma empresa deveria testar antes de adotá-lo?
Um teste útil não deveria começar com um 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 equipe dedicado do Cursor.
- Uma implementação do Cloudflare com
max_instancesconservador. - Uma chave de conta de serviço com escopo para autenticar workers do pool.
- Credenciais Git mínimas para o repositório de teste.
- Uma imagem de container com apenas as ferramentas necessárias para o workflow.
- Um caminho de build ou teste que toque uma dependência interna.
- Logs revisados por plataforma e segurança.
- Um rollout de imagem planejado após o término das sessões ativas.
A condição de sucesso não é “o agente fez uma mudança”.
A condição de sucesso é que a equipe entenda o que acontece quando algo falha: falta de capacidade, credenciais Git incorretas, segredos ausentes, clones frios, cache miss em R2, instalação quebrada de ferramentas, rollouts interrompidos e conectividade de saída falhada.
A infraestrutura de agentes é infraestrutura. Merece testes de falha.
Qual é o sinal mais importante?
O sinal mais importante é que os agentes de código estão se tornando arquitetura de runtime.
Para desenvolvedores individuais, a pergunta geralmente soa como “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 equipes enterprise, a pergunta está se tornando outra: onde o trabalho do agente é executado e sob quais 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 geralmente ocorre precisamente nesse tipo de camada intermediária: nem cloud puro, nem self-hosted puro, mas uma fronteira que permite a plataforma, segurança e engenharia dizerem que sim sem fingir que o risco desapareceu.
Por que isso 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.
As equipes que adotarem agentes em profundidade precisarão de respostas sobre localização do código-fonte, execução de comandos, alcance de rede, segredos, logs, artefatos, imagens de workers e auditoria. O modelo do Cloudflare para Cursor é um dos exemplos públicos mais claros dessa arquitetura se tornando real.
A pergunta não é mais apenas se um agente pode escrever código útil.
A pergunta é qual parte do agente você está disposto a executar onde.