Quick answer
Orchard Env is the shared execution layer beneath Microsoft Orchard. It exposes generic sandbox operations over HTTP and through synchronous and asynchronous Python clients. The official repository describes:
- sandbox create, execute, file, patch, and delete operations;
- Kubernetes-backed isolation and parallel lifecycle management;
- an in-pod agent for lower-latency execution;
- Redis-backed state and distributed locks for multiple orchestrator replicas;
- per-sandbox CPU, memory, timeout, and TTL controls;
- deny-egress-by-default network policy and API-key authentication.
Those are implementation features, not proof of secure deployment. Review the actual manifests and test isolation on the cluster you control.
Architecture boundary
| Component | Responsibility | Validation question |
|---|---|---|
| Orchestrator | Accepts lifecycle requests and tracks sandboxes | Who can call it, and how are requests authenticated and audited? |
| Kubernetes control plane | Schedules and removes isolated workloads | Which namespace, service account, quota, and admission rules apply? |
| In-pod agent | Executes commands and handles file operations | Can a task escape its intended filesystem or resource boundary? |
| Network policy | Restricts sandbox traffic | Is deny-egress actually enforced by the selected CNI? |
| Client or harness | Drives multi-turn interaction | Are retries, cancellations, and duplicate actions safe? |
The REST API is the stable contract; the Python SDK is a client over it. That makes non-Python trainers possible, but every client still needs timeout, idempotency, and cleanup behavior.
Pilot sequence
- Deploy to a non-production cluster and pin the Orchard commit and container digests.
- Use a minimal base image and a dedicated namespace and service account.
- Verify create, execute, files, patches, timeouts, deletion, and TTL cleanup.
- Test denied network access and explicitly allow only required destinations.
- Exercise concurrent rollouts, orchestrator restarts, Redis loss, and stale locks.
- Confirm secrets never enter images, trajectories, logs, or patches.
- Compare success, latency, and cost against your current sandbox on the same task set.
The repository includes AKS-oriented deployment scripts, but it also documents non-Azure Kubernetes configuration. A quickstart is not a production configuration review.
Decide whether Orchard Env fits
Use Orchard Env when several agent projects can share one execution contract and your team can operate Kubernetes. A managed sandbox may be more appropriate when the team cannot own cluster hardening, upgrades, observability, and capacity.
For how this layer supports code, browser, and assistant recipes, read the Orchard framework overview. For deployment-harness alignment, use the harness training guide.
Frequently asked questions
What does Orchard Env provide?
Orchard Env provides a Kubernetes-native service for sandbox lifecycle, command execution, file operations, patches, resource controls, and agent integration through a REST API and Python SDK.
Does Orchard Env require Python in every sandbox image?
The repository says its in-pod agent is injected by an init container with a self-contained Python interpreter, so the selected user image does not need to include Python.
Does Kubernetes make an Orchard sandbox secure by default?
No. You must still validate cluster boundaries, images, credentials, network policies, resource limits, API authentication, logging, cleanup, and incident response for your threat model.
Official sources
Source check: August 4, 2026. Verify the current manifests, supported Kubernetes environments, dependencies, limits, network implementation, and security guidance before deployment.