Sandbox supplies execution isolation and runtime lifecycle; iCommerce supplies commerce
state and policy-controlled operations. A selected runtime does not itself authorize a
refund, protect every credential, or prove physical containment on your deployment.
Prepare the runtime
Use a trusted image with compatible Node/native packages and @stateset/cli@1.39.0 installed.
Confirm runtime availability, network/secret access and capability checks through
Sandbox runtime selection.
Choose a bounded lifetime and persist original create/execution request identities.
A local SQLite file belongs to that runtime’s filesystem. Confirm durable workspace and
termination semantics before using it as a business store. A temporary worker is not a
backup, and pausing does not preserve arbitrary memory or running processes.
Verify observation first
Inside the provisioned worker, read an explicitly configured store:
An empty result may mean the wrong database. Verify a known identity before allowing work.
Model-assisted commands additionally need their provider configuration; native inspection
and isolated simulations do not require a hosted commerce account.
Execute under separate authority
Use operator-owned policy, principal and store scope for
governed execution. Sandbox credentials and commerce
credentials serve different systems. Model text and --apply do not grant policy authority.
Persist original keys, payloads, receipts and external observations outside disposable output.
Use Sandbox execution recovery after a disconnect.
A successful HTTP response or zero exit does not prove the commerce action completed.
Inspect the governed receipt and native/provider outcome before another attempt.
Stop deliberately and verify cleanup through the
Sandbox quickstart. Export required
artifacts before termination; verify storage retention and billing against the deployment. Last modified on October 20, 2026
