Pular para o conteúdo principal

Cloud Runs (VS Code)

O Cloud Runs deixa os usuários da extensão do VS Code executarem runs do agente no servidor — em um ambiente de execução dedicado por usuário — em vez de rodar localmente na máquina deles. É útil quando o run é longo ou pesado e você quer tirá-lo do laptop do usuário.

O recurso vem desligado por padrão: nada roda no servidor até você habilitá-lo explicitamente para a organização. Esta página é o lado do administrador. Para a experiência de quem usa, veja Cloud Runs no VS Code (uso).

Cada usuário, seu ambiente

Quando habilitado, cada usuário autorizado recebe um ambiente de execução dedicado da classe power (1 vCPU / 2 GB). Ele é reusado entre os runs do mesmo usuário e recolhido automaticamente quando fica ocioso.

Onde se configura​

A governança do Cloud Runs vive no /app, junto com as demais regras da organização, no card "VSCode Dev Studio". É lá que você liga o recurso, escolhe quem pode usar e define os limites.

A regra fundamental: fail-closed​

Um ambiente de execução só nasce quando TODAS as condições abaixo passam juntas, na mesma requisição:

  1. A superfície é o VS Code (a extensão).
  2. A organização tem o Cloud Runs habilitado.
  3. O usuário tem o papel cloud_run_user ou cloud_run_admin — e ele está na lista de allowed_roles.
  4. Houve confirmação do usuário (quando exigida).
  5. Houve aprovação de admin (quando exigida).
  6. O workspace/repositório está na lista permitida.
  7. A quota de concorrência não estourou.
Qualquer negativa bloqueia o run

A avaliação é fail-closed. Se qualquer uma dessas condições falhar, nada é provisionado no servidor — o run é recusado. O default de fábrica é tudo desligado: sem nenhuma configuração, ninguém executa no servidor.

Campos da governança​

No card "VSCode Dev Studio" você controla:

CampoPadrãoO que faz
enabled (superfície) + cloud_runs.enabled (sub-bloco)OFFOs dois precisam estar ON para o Cloud Runs valer. A superfície liga o VSCode Dev Studio; o sub-bloco liga especificamente os Cloud Runs.
allowed_rolesvazioQuais papéis podem usar: cloud_run_user, cloud_run_admin. Vazio = ninguém (fail-closed).
require_confirmationtrueA extensão exige um modal de confirmação antes de disparar um run no servidor.
require_admin_approvalfalseExige aprovação de um admin antes do run rodar.
warm.idle_ttl_minutes30 (faixa 5–240)Por quanto tempo o ambiente fica quente e ocioso antes de ser recolhido.
resourcesclasse power (1 vCPU / 2 GB)Classe de recursos do ambiente. Somente-leitura — é a única classe disponível nesta fase.
limits.max_duration_minutes60 (faixa 5–480)Teto real de duração de um run (veja o aviso abaixo).
limits.max_parallel_runs_per_user1Quantos runs simultâneos um mesmo usuário pode ter.
limits.max_parallel_runs_per_org5Quantos runs simultâneos a organização inteira pode ter.
workspaces / repositories—Listas allow/deny de workspaces e repositórios. Deny vence.
max_duration_minutes é um teto que encerra o run

Não é só um alvo: passado o máximo (mais uma folga curta), o run é encerrado mesmo em andamento. Dimensione com margem para não cortar trabalhos legítimos — e use-o como teto de custo.

Papéis​

Atribua um dos dois papéis aos usuários autorizados, em Usuários & papéis:

PapelPermite
cloud_run_userUsar o Cloud Runs (disparar runs no servidor).
cloud_run_adminUsar e editar esta governança (o card "VSCode Dev Studio").

O papel, por si só, não basta: ele também precisa estar em allowed_roles. Um usuário sem o papel (ou fora de allowed_roles) tem o run recusado.

Ciclo de vida do ambiente​

O ambiente não é criado e destruído a cada run — ele é reusado pelo mesmo usuário entre runs. Ele é recolhido automaticamente quando:

  • fica ocioso além do warm.idle_ttl_minutes;
  • o run passa de limits.max_duration_minutes;
  • você desliga a governança — desligar o Cloud Runs para a organização encerra os ambientes dela.
Desligar é imediato e limpa tudo

Colocar cloud_runs.enabled (ou a superfície) em OFF não só bloqueia novos runs: encerra os ambientes existentes daquela organização. Use isso se precisar cortar a execução no servidor rapidamente.

Boas práticas​

Comece conservador
  • Mantenha require_confirmation=true — o usuário sempre confirma antes de gastar servidor.
  • Conceda cloud_run_user/cloud_run_admin só a quem realmente precisa.
  • Use max_duration_minutes e os limites de concorrência (max_parallel_runs_per_user / per_org) como teto de custo.
  • Lembre: allowed_roles vazio bloqueia todo mundo — é o comportamento fail-closed esperado.

Veja também​