---
title: "Cloud managed Sandbox"
description: "Appaloft Cloud managed Execution Sandbox isolation model, credential boundary, and available capabilities."
---

> Documentation Index
> Fetch the complete documentation index at: https://docs.appaloft.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cloud managed Sandbox

{/* appaloft-cloud-docs-injected: cloud-sandbox-managed/v1 */}

<span className="inline-flex items-center rounded-full border border-blue-500/30 bg-blue-500/10 px-2 py-0.5 text-xs font-bold text-blue-700">Cloud</span>

# 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.

Source: https://docs.appaloft.com/en/cloud/sandbox-managed/index.mdx