Loading…
Boxcompute
Give your AI agent a computer of its own. A secure, persistent workspace to build, test, and explore.
- 5 posts summarised
- latest
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
From their blog
Latest articles
Your sandbox can now serve requests
Sandboxes have traditionally been outbound-only machines, unable to receive inbound connections because they sit behind NAT with no public IP or open ports. BoxCompute now enables sandboxes to serve requests by using Tailcat, an open-source library from Tailscale that performs NAT traversal. Tailcat establishes a direct peer-to-peer WireGuard-encrypted path between the client and sandbox, using a DERP relay only for the initial handshake. This approach avoids the latency and bandwidth bottlenecks of relay-based tools like ngrok or Cloudflare Tunnel, and keeps the relay out of the data path. The feature is rolling out as an early preview with scoped, short-lived grants for selected TCP ports.
Full Linux VMs for your agents
BoxCompute VM Sandboxes are now the default runtime for every account, giving agents a full Linux virtual machine rather than a shared-kernel gVisor container. Each disposable VM boots its own kernel and provides root access, outbound internet with public IPv4 and DNS, and a unified approximately 10 GiB filesystem covering / and /workspace, while preserving the existing create, execute, file-transfer, and delete API. The CLI or HTTP API can create a VM, and users can opt out with vmSandbox: false or disable networking with blockNetwork: true. VMs remain billable until explicitly deleted and currently use a fixed profile of 0.5 CPU, 1 GiB memory, and a minimal Ubuntu image. The beta does not include inbound ports, SSH, custom images, or volumes.
I got frustrated with AWS, so we built our own sandbox
At a healthcare startup, an agent workflow built with LangGraph was constrained by context length and by the limited tools exposed to it for data analysis. Changing one node gave the agent access to Amazon Bedrock AgentCore Code Interpreter, allowing it to use pandas and other available data-science libraries in a sandbox. It could inspect files and outputs, write and run code, and adjust its analysis iteratively while keeping working data and intermediate artifacts in the workspace rather than sending every row through the conversation. Although the experiment demonstrated the usefulness of this controlled autonomy, regional availability forced the author to use a US region from Malaysia, motivating BoxCompute, an infrastructure project intended to provide agent workspaces with control over execution, resources, output collection, and cleanup.
KubeVirt, VSOCK, and eBPF: who does what?
KubeVirt, VSOCK, and eBPF address different layers, so none replaces the others. KubeVirt adds virtual-machine lifecycle management to Kubernetes, running QEMU in a launcher Pod while KVM uses hardware virtualization features to execute guest code; it does not replace either component. VSOCK provides host–guest communication through a CID-and-port socket address, independently of guest IP networking, but attaching virtio-vsock does not define permitted applications or provide authentication and authorization. For host-enforced control, BPF LSM can use the socket_listen hook to deny unapproved host-side VSOCK listeners before creation, whereas ordinary XDP and TC filters on VM network interfaces do not see VSOCK traffic; this still leaves existing listeners, per-guest permissions, kernel attack surface, policy lifetime, and other virtual devices to address.
Why we chose KubeVirt for our VM sandboxes
BoxCompute chose KubeVirt for its VM sandboxes because workloads need a real Linux machine with a guest kernel, systemd, and machine-level workflows that process-oriented environments do not fully provide. KubeVirt adds VM resource types and controllers to Kubernetes, while launcher Pods run QEMU/KVM and the guest on a worker. The arrangement keeps placement, lifecycle, permissions, storage, and cleanup within the Kubernetes model, avoiding a separate VM management platform, although resource accounting and readiness still require sandbox-specific work. The post stresses that full virtualization does not automatically provide security: the platform still needs deliberate controls for host access, guest traffic, credentials, persistence, and cleanup after failures.
Topics they write about
All topics →Weekly digest
The best engineering reads, once a week.