How Figma manages sandboxes at scale

Figma built Nimbus to manage the tens of thousands of isolated environments its AI products need to run generated or otherwise untrusted code. The platform gives product teams a simple, provider-independent interface: teams describe a sandbox’s image, resources, health checks, security rules, and warm-pool limits in a namespace, while Nimbus selects infrastructure, provisions the environment, and manages its lifecycle through create-or-reuse, retrieve, and delete APIs. A shared base image and sandbox daemon provide consistent setup, process supervision, health checks, and CPU, memory, and network monitoring across cloud providers. This division lets product teams specify what they need while the platform handles allocation, security, reliability, and changes to underlying providers.

Nimbus’s security model goes beyond container isolation by controlling outbound traffic. Workloads can freely communicate with explicitly trusted hosts; elsewhere, they may make only body-free GET, HEAD, or OPTIONS requests, supporting web search and browsing while blocking arbitrary data uploads. Credentials are encrypted inside sandboxes and revealed only when a request goes to its intended destination. Nimbus enforces these policies using provider-native controls or a proxy sidecar, and fails closed if enforcement or credential handling is unavailable. To reduce delays and withstand provider outages, it keeps pre-provisioned warm sandboxes and automatically selects providers. Warm pools cut provisioning latency by 90% and raised availability from 99% to 99.95%; the reported p99 readiness time fell from about six seconds to two.