Skip to main content
Instances are created one call at a time, and CreateInstance returns while the machine boots. That makes fan-out a client-side concern: launch the calls concurrently, bound how many are in flight, and destroy what you created. This is the shape behind sharded test runs and one-sandbox-per-task agent workloads.
1

Bound the concurrency

Do not launch an unbounded number of creations. A workspace has concurrency limits, and exceeding them fails calls that a bounded pool would have completed.
Every instance counts against your workspace concurrency limit while it exists, and each one bills for its lifetime, not for the work it did. Keep the deadline short and destroy instances explicitly rather than leaving them to expire.
2

Do the work on each instance

One unit of work is a create, an exec, and a record of the instance id so it can be destroyed later. Going straight from CreateInstance to RunCommandSync avoids a separate readiness wait, as described in run a command in an instance.
Pass labels on the create request if you want to find these instances later. ListInstances filters on them with labelFilter.
3

Destroy the instances

Destroy concurrently as well. Use a context that is not already cancelled, so a cancelled run still cleans up after itself.

Source

go/benchmark in github.com/namespacelabs/examples runs this pattern over 100 instances and reports percentile timings for the create and exec phases. It also sets experimental.privateFeature, which is gated by the Namespace team and not available by default; the pattern above does not need it. See resource limits for workspace concurrency limits.
Last modified on October 2, 2026