Make sandbox selection a platform decision
Evaluate sandbox selection as a Polyaxon platform decision covering execution contracts, identity, scheduling, state, evidence, and operational ownership.
Selecting a sandbox changes more than where an agent runs code. It affects identity, data access, scheduling, artifact retention, debugging, and the team's response when execution fails.
Treat the decision as part of the ML platform architecture. Polyaxon provides a useful common context for these concerns, whether the execution is a native sandbox-enabled service or an external backend called by your application.
Follow the workload beyond the first command
Map a representative task from authenticated request to reviewed output. Include repository preparation, dependency loading, tool calls, evaluation, and cleanup.
Then ask what information survives each handoff. Can the team connect a patch to its input dataset and image revision? Can an interrupted session be reconstructed? Can an administrator identify the owner of an idle service?
A command API demo rarely answers these questions. A production decision should.
Define the integration contract
Keep the application's execution interface independent of provider-specific convenience methods where practical. It should express authorized inputs, deadlines, completion semantics, and output references.
For Polyaxon sandboxes, the adapter manages a service run and uses process and filesystem access. For an external execution backend, the adapter must also record that backend's identity and lifecycle.
Do not assume external execution automatically inherits Polyaxon permissions or storage behavior. The controller needs to preserve those relationships explicitly.
Compare the operational surface
| Area | Decision to document |
|---|---|
| Identity | How caller permissions map to execution access |
| Scheduling | Who allocates capacity and handles contention |
| State | Which files survive and how they are reconstructed |
| Credentials | Which component receives each external permission |
| Evidence | Where receipts, metrics, and reports are retained |
| Recovery | Who reconciles interrupted or uncertain work |
| Maintenance | Who patches images, runtime, and surrounding infrastructure |
Use connections, reviewed components, and tracking to standardize the parts your Polyaxon platform owns.
Where available, queues can align execution with project capacity and placement policy. That can reduce operational fragmentation, but it does not remove cluster administration.
Prototype the hard cases before committing
Run a small authorized evaluation covering a normal task, an oversized output, a denied data request, a client disconnect, and service replacement. Include the expected cleanup and artifact retention behavior.
Measure time to a usable result, not only startup. Compare the effort needed to investigate a failure and reconstruct a session. Use synthetic data for boundary checks.
Keep the configuration and benchmark evidence in Polyaxon so the decision can be revisited after an image or infrastructure change.
Make migration part of the selection
Define how to export useful artifacts and durable task state without preserving unnecessary credentials or caches. Keep code and dependency definitions outside an individual workspace.
A platform decision should identify the conditions that would trigger a change: unmet isolation requirements, excessive queueing, an unsupported dependency, or operational cost that no longer fits the workload.
The strongest sandbox choice is the one that fits the complete execution and evidence model. It should make agent work easier to operate alongside the rest of the ML platform, not create an untraceable second system.