Xolis is a Kubernetes-native sandbox service for AI agents that need to run untrusted workloads with strong isolation and fast provisioning.
Xolis combines the following components:
- Kubernetes Agent Sandbox for declarative sandbox lifecycle management.
- Kata Containers with the Rust runtime and Dragonball VMM for VM-level workload isolation.
- containerd for OCI image management, with the Nydus snapshotter as an optional lazy-loading optimization.
- An experimental PVM host path for x86 environments that do not expose hardware virtualization extensions.
- Optional Confidential Containers support for confidential-computing workloads.
The high-level architecture is described in Docs/General-Arch.md. The initial service decomposition, API boundary, and image plan are described in Docs/Initial-Sandbox-Service-Design.md. The consolidated implementation status, measured performance, availability boundary, and roadmap are described in Docs/Project-Status-and-Roadmap.md.
The current AWS lab includes OpenTofu infrastructure, a disposable test-cycle
tool, a custom Kata 4.0.0 runtime-rs and Dragonball AMI, Agent Sandbox v0.5.3,
and the Rust Xolis API with a bounded Python runtime. The automated service
acceptance test validates Kata placement, buffered and streaming commands,
interactive PTY sessions, file operations, tenant isolation, request limits,
network policy, deletion, and TTL cleanup. The Lab tool also automates
cold-versus-warm SandboxWarmPool measurements with structured JSON reports.
An independently selected Nydus path and Hermes Agent profile have passed
bounded single-node validation; ordinary OCI remains the default. See
Docs/AWS-Lab-Tooling.md for prerequisites and test
workflows.
The v0.3.0 PVM milestone builds and boots pinned Linux 6.12.33 host
and guest kernels on an AWS instance without vmx or svm. Kata 4.0.0
runtime-rs and upstream Dragonball have passed standalone containerd and CRI
tests with the dedicated xolis-kata-pvm handler, including one- and two-vCPU
boot, block rootfs, vsock, memory, inline virtio-fs, xattrs, exit propagation,
and repeated cleanup. The matched kernel and runtime artifacts are archived
with manifests and checksums, and a separate immutable PVM AMI pipeline now
installs, reboots, validates, and publishes that exact artifact set. An
isolated EKS PVM node pool and RuntimeClass/xolis-kata-pvm have also passed
node registration, guest boot, CNI, DNS, egress, NetworkPolicy, service restart,
and cold node replacement tests. The core Xolis API lifecycle, TTL cleanup,
cold and warm-pool claims, SSE streaming, and interactive PTY have passed on
PVM. The Hermes image and its CLI also start through the PVM PTY path, without
a model call. PVM node-loss recovery and the independent native-KVM lifecycle
regression have also passed. PVM is not yet a release path: a model-backed
Hermes workflow and broader failure-injection gates remain open.
A bounded five-sample comparison on one Ready c7i.xlarge PVM node measured
mean claim-to-Ready times of 8.806 seconds with a zero-replica pool and 1.385
seconds with one Ready warm sandbox. This small-cluster, sequential test shows
the expected warm-pool effect, but it is not a capacity, concurrency, tail
latency, or production-performance claim.
Current pre-scale development therefore has two parallel priorities: separate the provider-neutral lifecycle and capacity contract from the AWS adapter, and complete PVM platform integration. Large-cluster evaluation and Dragonfly distribution remain deliberately deferred. See Docs/Project-Status-and-Roadmap.md for the ordered plan and Docs/PVM-Development-and-Test-Plan.md for PVM qualification gates.
Xolis uses Rust for the service API, Python for the initial sandbox runtime and lab automation, and Shell for focused build and deployment tasks.
Licensed under the Apache License 2.0.