> For the complete documentation index, see [llms.txt](https://docs.tryorchard.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tryorchard.dev/cli/remote-cloud-sandboxes/remote.md). # remote: cloud sandboxes `orchard remote` drives **cloud** sandboxes (e2b / daytona / modal), as opposed to node-hosted devices. Remote sandboxes are addressed by their **record id** or their **name** (not a uuid). Everything here is gated by the `platform.remote` feature on your org. ## Credentials A provider credential (an API key, per workspace) must be stored before you can create sandboxes. For Modal the key is `token_id:token_secret`. ```bash orchard remote cred add modal "tok_id:tok_secret" --label mine orchard remote cred ls orchard remote cred rm 3 ``` ## Lifecycle ```bash orchard remote create modal box --image python:3.12-slim --cpu 2 --ttl 60 orchard remote ls orchard remote get box orchard remote stop box orchard remote rm box orchard remote sync # adopt sandboxes launched on the provider ``` `--ttl ` auto-terminates the sandbox; `--image`, `--cpu`, `--memory` and `--region` are passed through to the provider (and counted against your org's quota). Every verb takes the sandbox's **name** (unique in the workspace) or its **uuid**; the examples use names. `sync` adopts any sandbox launched straight on Modal/Daytona/E2B so it shows up here, across every stored credential. ## Interact ```bash orchard remote shell box # interactive shell orchard remote push box ./data.json /root/data.json orchard remote pull box /root/out.json -o ./out.json orchard remote logs box # stream logs (Ctrl-C to stop) orchard remote metrics box # cpu / mem / uptime ``` `logs` streams the sandbox's main-process output; a sandbox created with no long-running entrypoint is usually quiet there, so run a command in `shell` to see its output. `metrics` is sampled from inside the guest, since the providers expose no first-class per-sandbox telemetry. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.tryorchard.dev/cli/remote-cloud-sandboxes/remote.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.