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).
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:
- A superfície é o VS Code (a extensão).
- A organização tem o Cloud Runs habilitado.
- O usuário tem o papel
cloud_run_useroucloud_run_admin— e ele está na lista deallowed_roles. - Houve confirmação do usuário (quando exigida).
- Houve aprovação de admin (quando exigida).
- O workspace/repositório está na lista permitida.
- A quota de concorrência não estourou.
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:
| Campo | Padrão | O que faz |
|---|---|---|
enabled (superfície) + cloud_runs.enabled (sub-bloco) | OFF | Os 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_roles | vazio | Quais papéis podem usar: cloud_run_user, cloud_run_admin. Vazio = ninguém (fail-closed). |
require_confirmation | true | A extensão exige um modal de confirmação antes de disparar um run no servidor. |
require_admin_approval | false | Exige aprovação de um admin antes do run rodar. |
warm.idle_ttl_minutes | 30 (faixa 5–240) | Por quanto tempo o ambiente fica quente e ocioso antes de ser recolhido. |
resources | classe power (1 vCPU / 2 GB) | Classe de recursos do ambiente. Somente-leitura — é a única classe disponível nesta fase. |
limits.max_duration_minutes | 60 (faixa 5–480) | Teto real de duração de um run (veja o aviso abaixo). |
limits.max_parallel_runs_per_user | 1 | Quantos runs simultâneos um mesmo usuário pode ter. |
limits.max_parallel_runs_per_org | 5 | Quantos 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 runNã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:
| Papel | Permite |
|---|---|
cloud_run_user | Usar o Cloud Runs (disparar runs no servidor). |
cloud_run_admin | Usar 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.
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
- Mantenha
require_confirmation=true— o usuário sempre confirma antes de gastar servidor. - Conceda
cloud_run_user/cloud_run_adminsó a quem realmente precisa. - Use
max_duration_minutese os limites de concorrência (max_parallel_runs_per_user/per_org) como teto de custo. - Lembre:
allowed_rolesvazio bloqueia todo mundo — é o comportamento fail-closed esperado.
Veja também
Esta página ajudou?
Reportar um problema nesta páginaNão envie senhas, chaves, tokens ou dados de clientes.