Como a Figma sustenta dezenas de milhares de sandboxes para seus produtos de IA
Aprofundamento CEVIU
Aprofundamento
O ponto central do texto da Figma é a separação de responsabilidades. O produto (o agente, o Figma Make) entrega um arquivo de configuração chamado namespace, e o plano de controle do Nimbus escolhe o provedor, aloca recursos, aplica regras de rede e segurança e cuida do ciclo de vida. A API tem só três chamadas: GetOrCreate, Get e Delete. Cada sandbox sobe a partir da imagem base sandbox-base e roda o daemon sandboxd, que supervisiona processos, faz health checks e reporta CPU, memória e rede.
Na segurança, a Figma diz que isolar o container não basta. Em vez de uma allowlist rígida, o Nimbus trata leitura e escrita de forma diferente: hosts confiáveis liberam leitura e envio, e os demais só aceitam GET, HEAD ou OPTIONS sem corpo. As credenciais entram criptografadas e só são trocadas pelo valor real na saída, quando o destino é o correto. Com a política igual em todos os provedores, o Nimbus mantém warm pools, que cortaram a latência de provisionamento em cerca de 90%. Somados à seleção automatizada de provedores, elevaram a disponibilidade de 99% para 99,95%. A Figma conta que o Nimbus está em uso interno desde novembro de 2025.
O que mudou
A cobertura anterior do CEVIU mostra o lado de produto desses agentes. Em 1 de setembro de 2026, o CEVIU noticiou "Figma revoluciona a ponte entre design e código com Agentes de IA", sobre servidor MCP e Code Connect. Em 24 de setembro de 2026, veio "Figma revoluciona design com IA que cria plugins sob demanda". Agora a Figma mostra a infraestrutura que executa código gerado por esses agentes. Em 10 de agosto de 2026, o CEVIU também havia tratado da segurança interna da empresa com agentes. O texto atual não liga esses temas de forma explícita, então a conexão é de contexto, não de causa comprovada.
Por que isso importa
Para quem desenha com IA, a leitura é que recursos como gerar plugins ou protótipos dependem de infraestrutura que o usuário nunca vê. Latência de provisionamento e disponibilidade viram experiência: se a sandbox demora, o fluxo no canvas trava. Para quem projeta produtos com agentes, o desenho de permissões (ler a web sim, enviar dados não) é um exemplo concreto de equilibrar utilidade e segurança.
Linha do tempo
Nimbus começa a operar internamente na Figma (novembro de 2025).
CEVIU noticia a abordagem da Figma de segurança baseada em agentes.
CEVIU noticia a ponte entre design e código com agentes de IA, MCP e Code Connect.
CEVIU noticia o agente de IA que cria plugins sob demanda.
Figma detalha como o Nimbus sustenta dezenas de milhares de sandboxes.
Perguntas frequentes
O que é o Nimbus da Figma?
É a plataforma interna que provisiona, monitora e roteia sandboxes entre provedores de nuvem. Os times de produto pedem uma sandbox por uma API simples e o Nimbus cuida dos detalhes de cada provedor. Ele atende produtos como o agente da Figma e o Figma Make.
Por que a Figma precisa de tantas sandboxes?
Os produtos de IA executam código gerado ou não confiável, e isso precisa ficar isolado dos servidores da empresa. A Figma estimou que gerenciaria dezenas de milhares de sandboxes, com exigências diferentes de memória e rede.
O que são warm pools e qual o ganho?
São conjuntos de sandboxes já em execução e ainda não atribuídas, mantidos por namespace. Segundo a Figma, reduziram a latência de provisionamento em cerca de 90%. Junto com a seleção automatizada de provedores, subiram a disponibilidade de 99% para 99,95%.
Como o Nimbus evita vazamento de dados pela rede?
Hosts confiáveis têm acesso total. Para os demais, só passam requisições de leitura sem corpo (GET, HEAD, OPTIONS), e POST ou PUT ficam bloqueados. As credenciais seguem criptografadas dentro da sandbox e só viram o valor real ao sair para o destino correto.
Fontes
- figma.comfonte original
- Categoria
- CEVIU Design
- Publicado
- 06 de novembro de 2026
- Editoria
- CEVIU Design

