Cloud Managed Sandbox

Appaloft Cloud provides a ready-to-use managed Execution Sandbox: create, connect to, run commands, files, and processes in, and clean up a Sandbox without registering your own server. It uses the exact same Sandbox operations and SDK as self-hosted Appaloft; Cloud only adds a managed worker, isolation policy, and credential broker so you don’t have to operate the underlying machine.

Relationship To Self-Hosted Sandbox

Sandbox itself is a public Appaloft capability: create, pause/resume, exec, file transfer, process/port management, snapshot, and cleanup all go through the same CLI/HTTP/API/SDK regardless of who hosts it. The only difference for Cloud managed Sandbox is who provides the underlying machine:

• Self-hosted: the Sandbox runs on a server you registered with Appaloft; you own that machine’s availability and cost.
• Cloud managed: the Sandbox runs on a worker Appaloft Cloud provides or manages; you receive only a scoped Sandbox handle and never need to see or manage the underlying VPS/SSH/Docker details.

If your organization has already registered its own servers with Appaloft Cloud, Cloud can also place a Sandbox on one of those registered servers. The behavior matches the “Cloud managed worker” case; only the underlying machine changes to your own registered server.

Isolation Model

The first available isolation tier for Cloud managed Sandbox is honestly labeled container-trusted: a real container boundary, without a claim of hostile-multi-tenant-grade isolation. Stronger isolation tiers (for example a gVisor-backed runtime) roll out progressively once available and verified; this page is updated when the isolation tier changes rather than silently marketing container-trusted as fully isolated.

High-risk or anomalous Sandbox creation requests may be denied by admission policy, or required to use a stronger isolation tier.

Credential And Network Boundary

• Cloud never exposes underlying VPS, SSH, Docker, or server credential fields to callers; you always receive a scoped Sandbox handle and an Appaloft-issued token, never a credential that can connect directly to the underlying machine.
• When a Sandbox needs to reach an external service (for example a model API or Git credentials), Cloud issues a short-lived, purpose-bound credential grant. Long-lived secrets are never injected in plaintext into Sandbox environment variables or logs; if the credential broker is unavailable, the request fails explicitly instead of falling back to plaintext injection.
• A Sandbox has no arbitrary outbound network access by default. Access to a specific external service is granted through an explicitly declared credential/network capability, not by opening the Sandbox’s entire outbound network.

Quota And Availability

Sandbox concurrency, time-to-live (TTL), and resource sizing are governed by your organization’s current entitlement. Requests that hit a quota limit return an explicit quota error instead of queueing or silently degrading. See your organization settings in Cloud Console for the current quota values; this page does not maintain specific numbers that change with pricing.

Common Questions

Is a Sandbox the same as a Deployment? No. A Deployment targets a long-running application; a Sandbox targets a short-lived, interactive, or agent-driven execution environment with its own pause/resume/snapshot/cleanup lifecycle. The two can coexist, but a Sandbox should not be used as a deployment target.

How is a Cloud managed Sandbox different from a plain Docker container? A Cloud managed Sandbox adds tenant isolation, admission policy, a credential broker, and audit on top of the container boundary; a bare container provides none of those guarantees.

Related Tasks

• The Agent Workspace page under Agent 与 Sandbox / Agents: how Agent Workspace uses a Sandbox to host its runtime.
• CLI/HTTP/API reference: full command and field reference for the sandboxes operation.