Skip to main content
The CLI groups three related actions for sizing a sandbox: CPU follows memory per the platform’s tier table; you don’t pick CPU separately. For the underlying concepts and how these three modes interact, see the Elasticity guide.

​
oc sandbox autoscale <id>

Configure or inspect per-sandbox autoscale. HTTP API → Run with no flags to print the current configuration:
Enable with bounds:
Disable:
When enabled, the platform watches memory pressure and resizes the sandbox between --min and --max:
  • Scale up on a single 1-min sample above 75 % memory utilization. Cooldown 60 s between up-scales.
  • Scale down only when the 1-min, 5-min, AND 15-min averages all sit below 25 %. Cooldown 5 min between down-scales.
The asymmetry is deliberate: rapid response when the user notices lag, conservative shrink after sustained idle. Flags Errors
  • scaling_locked — the sandbox has a scaling lock active. Run oc sandbox unlock <id> first.
  • 402 Payment Required — --max exceeds your plan cap.

​
oc sandbox scale <id> <memory-mb>

Manually resize a sandbox to a specific memory tier. HTTP API →
A manual scale disables autoscale on this sandbox as a side effect — explicit intent overrides the loop. Re-enable with oc sandbox autoscale --on if you want size to track load again. Errors
  • scaling_locked — the sandbox has a scaling lock active. Run oc sandbox unlock <id> first.
  • 402 Payment Required — requested size exceeds your plan cap.

​
oc sandbox lock <id>

Pin a sandbox at its current size. HTTP API →
While locked:
  • oc sandbox scale is rejected with scaling_locked.
  • oc sandbox autoscale --on is rejected with scaling_locked.
  • The platform autoscaler skips the sandbox entirely.
Locking also disables autoscale (single knob — “I don’t want this scaling, period”). Unlocking does NOT re-enable autoscale; run oc sandbox autoscale --on explicitly if you want it back.

​
oc sandbox unlock <id>

Clear the scaling lock.

​
oc sandbox lock-status <id>

Print the current scaling-lock state.