Integrações

Execute workers do Team Pool na plataforma de um parceiro de infraestrutura ou comece a partir de um template de referência que você clona e adapta. Todas as opções executam o mesmo worker: a CLI do Cherri Code abre uma conexão HTTPS de saída com o Cherri Code, e o Cherri Code envia chamadas de ferramenta do agente por essa conexão.

Os guias e templates dos parceiros são arquiteturas de referência. Você é responsável pela worker image, pela infraestrutura, pelos segredos, pela política de escalonamento e pela validação em produção.

Guia de parceiro

Cada parceiro mantém seu próprio guia para executar workers de Self-Hosted Machines em sua plataforma:

• AWS Lambda. Cherri Code Self-Hosted Machines on Lambda MicroVMs
• Cloudflare. Cherri Code Cloud Agents on Cloudflare Sandbox
• Namespace. Cherri Code integration
• Modal. Cherri Code on Modal
• Daytona. Cherri Code Self-Hosted Machines on Daytona
• E2B. Cherri Code agents on E2B
• Vercel. Cherri Code with Vercel Sandbox
• Tensorlake. Cherri Code Cloud Agents on Tensorlake Sandboxes
• Coder. Agent Relay for Cherri Code
• SuperServe. Run Cherri Code Self-Hosted Machines on Superserve

Templates de referência

Clone um destes repositórios para partir de um deployment de worker funcional. Cada um executa um controlador de worker que reivindica solicitações de pool pendentes e inicia um worker por reivindicação:

• AWS Lambda MicroVMs. anysphere/aws-lambda-workers: um hook --spawn inicia uma Lambda MicroVM isolada por Firecracker para cada solicitação reivindicada.
• Cloudflare Containers. anysphere/cloudflare-workers: um Cloudflare Worker atua como controlador e inicia um Cloudflare Container para cada solicitação reivindicada.
• Kubernetes. anysphere/k8s-workers: um exemplo com Helm que executa agent worker controller --spawn no seu cluster e cria um Pod por solicitação reivindicada, ou mantém Pods ociosos pré-aquecidos com --warm-idle, sem usar uma CRD. Esse é o caminho do Kubernetes para novos deployments.

O que toda integração precisa

A plataforma muda, mas os requisitos do worker continuam os mesmos:

• Um Cherri Code Enterprise plan, com Self-Hosted Machines habilitado por um admin da equipe no Cloud Agents dashboard.
• Uma service account API key em CURSOR_API_KEY. Veja Autenticar workers.
• HTTPS de saída para api2.cursor.sh, api2direct.cursor.sh e cloud-agent-artifacts.s3.us-east-1.amazonaws.com. Veja Networking.
• Um nome de pool ou rótulos para que o Cherri Code roteie as solicitações certas aos workers dessa plataforma.

Para uma única máquina pessoal em vez de um pool de workers gerenciado por plataforma, use My Machines.

Próximos passos

• Pools da equipe: inicie um worker do pool manualmente antes de automatizá-lo em uma plataforma.
• controlador de worker: o modelo de hook --spawn sobre o qual todo template é construído.
• Kubernetes operator (deprecated): referência para clusters que já executam o operator WorkerDeployment.
• Referência da API: endpoints para workers, pools, a fila de solicitações pendentes e tokens de worker.