The Problem
Running thousands of isolated agent sandboxes (Firecracker micro‑VMs) on a cluster is hard to orchestrate, especially when you need fast start‑up, snapshot‑based pause/resume and cheap idle‑state handling. Without a dedicated platform you end up writing ad‑hoc scripts, duplicating image‑caching logic, and exposing the host to privilege‑escalation risks.
What This Does
AgentENV (AENV) is a self‑contained suite that supplies a server, a CLI, and supporting libraries to launch, snapshot, fork and cache OCI‑based environments at scale.
- The server binary lives in
adev/src/main.rsand is built with Cargo (cargo build --release). It wires the HTTP API (E2B‑compatible) to the sandbox manager (src/api/proxy.rs). - The CLI (
aenvcommand) is incrates/aenv/src/commands/*and talks to the server via the client impl incrates/aenv/src/client/mod.rs. - Image handling, overlay‑bd caching and Firecracker orchestration live under
src/image/andsrc/sandbox/, while persistent state is stored via S3‑compatible object storage (crates/object-store-operator).
Key files: src/api/generated/src/models.rs (data model), src/orchestrator/store/in_memory.rs (in‑memory store), src/image/oci_image.rs (OCI fetch & conversion), deploy/docker-compose.yml (container deployment).
How It Is Wired
Execution starts at adev/src/main.rs:27 (fn main). The function creates a tracing subscriber (setup_tracing) and then launches the server (run). The call chain is:
main → setup_tracing → std::fs::OpenOptions::new() (creates log file)
main → run → create_sandbox (src/api/impls/sandbox.rs)
create_sandbox → context (src/orchestrator/tests.rs) // 399 functions reachable
create_sandbox → setup_tracing → filesystem
The most‑used internal symbols are context, map, path, Err, and is_empty, each called >100 times throughout the codebase, indicating they are hot spots for change impact.
File‑level responsibilities (most‑used routes):
src/api/generated/src/models.rs– 228 functions, defines validation helpers (from_validation_error,check_xss_*).src/api/generated/src/types.rs– 42 functions, core (de)serialization (validate,from_str).crates/warm-pool/src/lib.rs– pool lifecycle (new,is_shutting_down).src/image/mod.rs– image error handling (ImageError,ImageResult).src/image/oci_image.rs– OCI manifest fetch, external command execution, network I/O.
No circular import edges were detected; the internal call graph is a tree‑like hierarchy, which keeps change propagation predictable. The repository’s external touch points are limited to filesystem writes (e.g., log files, overlay caches), outbound HTTP/S3 calls (via reqwest in src/image/oci_image.rs), and a few DB writes (src/logging.rs → configuration client).
How To Use It
# Clone the repo
git clone https://github.com/moses-y/AgentENV
cd AgentENV
# Build the server and CLI (requires Rust toolchain)
cargo build --release # produces ./target/release/adev and ./target/release/aenv
# Quick‑start single node (matches README)
# Option A – install script (Ubuntu 24.04)
curl -fsSL https://raw.githubusercontent.com/kvcache-ai/AgentENV/main/scripts/install.sh | sudo bash
sudo systemctl start aenv
# Option B – Docker compose
docker compose -f deploy/docker-compose.yml up -d # uses privileged mode (see health notes)
# Authenticate the CLI
./target/release/aenv auth
# Follow prompts (default URL http://127.0.0.1:8000, API key “dummy”)
# Pull a template and start a sandbox
./target/release/aenv pull ubuntu:22.04 --name ubuntu
./target/release/aenv start ubuntu
Configuration files live under config/ (default.toml, deps_manifest.toml). Environment variables for the server are documented in README.rst and the deployment docs (docs/deployment/manual-compile.html).
Real‑World Use
A training orchestrator can call the aenv start <name> CLI from a job scheduler. Each call creates a Firecracker micro‑VM, snapshots it after initialization, and stores the snapshot in an S3 bucket. The orchestrator then forks the snapshot for parallel agents, achieving sub‑50 ms start‑up while keeping host memory pressure low.
Code Health & Issues
- High – Pin GitHub Actions to commit SHA –
.github/workflows/*uses tag refs (@v4). Replace with 40‑char SHAs. - High – Upgrade vulnerable dependencies –
tokio@1,regex@1,tar@0.4,zip@2have published CVEs. Update to fixed releases and commit the lockfile. - High – Drop privileged mode & host networking –
deploy/docker-compose.ymlsetsprivileged: true. Grant only required caps (cap_add) and publish ports explicitly. - Medium – Declare least‑privilege
GITHUB_TOKEN–.github/workflows/ci.ymllacks apermissions:block. Addcontents: read. - Medium – Enable Dependabot/Renovate – No bot configured despite 20 manifest files. Add
.github/dependabot.yml. - Medium – Pin Docker base images by digest –
Dockerfile.agentenvuses mutable tags (rust:1-bookworm). Use@sha256:digests. - Medium – Add dependency‑vulnerability scan – No scan step in CI; integrate
dependency-review-actionorosv-scanner. - Medium – Set
persist-credentials: falseon checkout –integration-tests.ymlkeeps token in.git/config. Adjust checkout step. - Medium – Add non‑root
USERto image – Dockerfile lacksUSER. Create a low‑privilege user andchownneeded paths. - Low – Set
timeout-minuteson workflow jobs – CI jobs have no timeouts; add reasonable limits.
Additional static findings: deep nesting (max indent depth 9 in src/api/impls/sandbox.rs), duplicated 6‑line blocks across 143 files, and oversized files (e.g., src/api/impls/sandbox.rs ≈ 2 k LOC). These affect readability and maintainability.
The Bottom Line
AgentENV delivers a complete, Rust‑centric stack for high‑throughput, snapshot‑based micro‑VM agents, with a usable CLI and Docker/K8s deployment paths. The codebase is functional but suffers from privilege‑heavy container defaults, several known vulnerable dependencies, and maintainability concerns (deep nesting, duplicated logic). It is suitable for teams that need a proven sandbox platform and are willing to address the highlighted security and hygiene issues before production rollout.