Home Features Docs SDKs Get Started

System design

How Isolon creates, manages, and destroys secure sandboxes. From a single node to a distributed cluster with resource-aware scheduling.

Standalone mode

One process handles everything: HTTP API, VM lifecycle, networking, image management, and the React dashboard. The Machine Provider boots each VM through a hardened VMM process. Perfect for development and small deployments.

Client
SDK / CLI / Browser
→
isolon-server
API Router · Auth · Control Plane
Network Manager
IP allocation · TAP · NAT
Image Manager
OCI pull · ext4 conversion · cache
↓
Firecracker + Jailer
Privilege drop · chroot · seccomp · namespaces · cgroups
↓
MicroVM
isolon-agent guest daemon · virtio devices

Request flow: Create Sandbox

01
Client sends POST /workspaces

Auth middleware validates API key or session cookie. Control plane validates the request and resolves the image through the five-tier resolution system.

02
Image preparation

If the image is remote, the Image Manager pulls it and converts to a bootable ext4 rootfs. Cached images are reused for sub-second boots. The rootfs is prepared as a copy-on-write overlay or full copy.

03
Network allocation

The Network Manager allocates an IP from the configured range, creates a virtual network interface for the VM, and configures NAT for outbound traffic.

04
VM boot via Jailer

The Machine Provider invokes Firecracker's Jailer which drops privileges to the configured UID/GID, enters a chroot, applies seccomp-bpf filters with a tightly restricted syscall whitelist, and isolates the VMM with PID/NET/IPC/MNT namespaces and cgroups. Only then does the MicroVM boot with its kernel, rootfs, network config, and bootstrap metadata.

05
Agent connection

The control plane connects to the guest agent through a fast host-guest channel or over the virtual network, marks the workspace as ready, and returns the ID to the client.

06
Lifecycle event

If webhooks are configured, the Webhook Sender fires a workspace.created event with HMAC signature to all subscribed endpoints.

Communication paths

PathProtocolPurpose
Host → GuestFast host-guest channel or TCPCommand execution, file I/O, terminal, process management
Guest → HostMetadata serviceBootstrap metadata: IP, gateway, DNS, environment variables
External → WorkspaceHTTP proxyPreview URLs reverse-proxied through isolon-server

Commander / Worker cluster

Scale horizontally by separating the API gateway from compute. The Commander routes requests, schedules workloads, and monitors health. Workers run VMs and report statistics.

Client
SDK / CLI / Dashboard
→
Commander
Scheduler · Registry · Proxy
↔
Worker 1
VM execution · Heartbeats
Worker N
VM execution · Heartbeats
Coordinator

Commander

Lightweight HTTP server. No VMs. Routes API requests to workers via scheduling, maintains worker registry, and serves the React dashboard. Needs only SQLite and auth store.

Compute

Worker

Runs VMs and registers with Commander on startup. Auto-calculates capacity from host resources. Heartbeat loop with exponential backoff re-registration on failures.

Security

Cluster Token + HMAC

Internal traffic uses a shared cluster token in the Authorization header, plus HMAC-SHA256 request signing. Workers validate Commander origin; Commander validates worker heartbeats.

Scheduling strategies

StrategyDescriptionBest for
resource-aware defaultConsiders VM count, free memory, and CPU usage across all healthy workersGeneral purpose, heterogeneous hardware
least-loadedPicks the worker with the fewest running VMsUniform hardware, simple distribution
round-robinCycles through workers evenly regardless of loadTesting, predictable distribution

Worker states

StateDescriptionAccepts new work?
healthyNormal operation, heartbeats arriving on scheduleYes
suspectMissed heartbeats for worker_timeout_seconds (default 30s)Yes (with caution)
offlineMissed heartbeats for 2x timeout (default 60s)No
drainingAdmin-initiated drain, worker finishing existing VMsNo

Request routing

When a client creates a workspace, the Commander selects a healthy worker, forwards the POST /workspaces request, and stores the workspace-to-worker mapping. Subsequent requests (exec, files, terminal) are proxied to the correct worker.

01
Location cache

Workspace-to-worker mappings are cached in memory (default TTL: 5 minutes) to avoid repeated database lookups for hot paths.

02
Circuit breaker

Per-worker circuit breakers trip after 3 consecutive proxy failures. Requests fast-fail for 15 seconds before a half-open probe retry.

03
Heartbeat recovery

Workers include their active workspace list in heartbeats. If the Commander restarts, it rebuilds location mappings from the next heartbeat round.

Inside the MicroVM

A lightweight agent runs inside every MicroVM, enabling command execution, file operations, terminal sessions, and telemetry without exposing the host.

Command execution

Run commands with streaming stdout/stderr, interactive PTY sessions over WebSocket, and background process management with signal support.

File operations

Read, write, delete, and rename files. Upload and download directories as tar archives. Watch directories for changes in real time.

Git & telemetry

Clone, commit, push, and pull repositories. Monitor CPU, memory, disk, and network usage from inside the sandbox.

Fast host-guest channel (Linux, preferred)

Direct host-to-guest communication without network stack overhead. Fast, secure, and bypasses the virtual network entirely. Requires Linux with vsock support.

TCP fallback

Host connects to the guest agent over TCP through the virtual network bridge. Used on macOS development or when the fast channel is unavailable.