Sub-12ms Hardware-Isolated MicroVMs with Scale-to-Zero

1. Does the sub-12ms claim represent a fresh VM boot or snapshot restoration?

Snapshot restoration with on-demand memory paging. A fresh, cold microVM creation (compiling guest kernel boot parameters, attaching block devices, and initializing guest systemd) takes approximately 110ms to 140ms. The sub-12ms metric (typically 7.42ms) represents restoring a pre-initialized microVM memory snapshot using userfaultfd (uffd) on-demand memory paging. When incoming traffic hits a dormant instance, Thanaton loads the guest execution state into KVM and resumes execution in single-digit milliseconds. We report both numbers transparently: 120ms cold boot vs 7.42ms snapshot wake-up.

2. What virtualization hypervisor powers Thanaton?

Thanaton is powered by AWS Firecracker running directly on Linux KVM (Kernel-based Virtual Machine) with hardware-assisted virtualization (Intel VT-x, AMD-V, and ARM64 EL2). Each microVM instance is managed by a dedicated Go daemon that interacts with Firecracker's REST API over an isolated Unix domain socket (/run/firecracker/<vm_id>.sock). Guests run minimal Linux kernels with stripped drivers, unneeded subsystem code removed, and device trees optimized for near-instant boot.

3. How does Scale-to-Zero work, and what is actually free when idle?

When an application experiences zero incoming traffic for its configured idle window (default: 60 seconds), the Thanaton engine issues a pause command to the hypervisor (/vm {"state":"Paused"}), serializes the guest vCPU state, and dumps memory pages to local NVMe storage. 100% of physical host RAM is immediately reclaimed and returned to the OS.

The Billing Guarantee: You pay $0.00 for idle guest vCPU and $0.00 for idle guest RAM. The only fee incurred during extended dormancy is standard raw block storage for persistent disk partitions (e.g. $0.08/GB-month on NVMe). If your workload is ephemeral, total idle compute cost is strictly zero.

4. How do incoming HTTP requests wake a sleeping microVM?

Thanaton features a kernel-level connection-holding reverse proxy (EdgeProxy). When an incoming HTTP request or TCP SYN arrives for a sleeping tenant:

1. The proxy holds the client TCP socket in memory without terminating the connection.
2. The proxy acquires a tenant-specific wake lock (wLock.Lock()) to prevent race conditions from concurrent traffic spikes.
3. The orchestrator restores the Firecracker microVM snapshot in 7.42ms and configures tap device networking.
4. The proxy dials the guest IP (192.168.x.x:3000) with resilient 25ms micro-backoffs and transparently forwards the held HTTP payload.

5. How are WebSockets, Server-Sent Events (SSE), and long-running connections handled?

Active TCP connections (including WebSockets, long-polling HTTP, and SSE streams) register an active lease reference on the reverse proxy. As long as at least one client WebSocket is connected, the auto-sleep timer is completely inhibited. The microVM will never suspend while active real-time communication is underway. The instance only enters sleep mode after all active connections have gracefully closed and the post-disconnect inactivity timeout expires.

6. What are the security and hardware isolation guarantees against host escapes?

Unlike Docker containers or shared-kernel runtimes (which share the host kernel, syscall tables, and /proc), Thanaton microVMs execute behind hardware CPU/MMU virtualization boundaries.

• Hardware Isolation: Guest code runs in unprivileged guest mode; memory access is constrained by hardware Second Level Address Translation (SLAT / EPT). Even a full kernel panic or root exploit inside the guest cannot read host memory or inspect neighboring VMs.
• Host Defense in Depth: The host Firecracker process runs inside a restricted jailer jail enforcing a minimal chroot, dedicated cgroups v2 resource limits, dropped Linux capabilities, and seccomp-bpf filters that block ptrace, bpf, and raw socket creation.

7. How does persistent storage and disk write isolation work?

Thanaton utilizes copy-on-write (reflink) disk overlays:

• Base Rootfs: A shared, read-only root filesystem image containing the base Linux distribution and pre-installed language runtimes (Node 22, Python 3.11, etc.).
• Ephemeral Overlay: Any temporary files written by the application are stored in an ephemeral CoW scratch layer that is automatically discarded on snapshot rollback.
• Persistent Volumes: For stateful applications (e.g. SQLite databases, uploaded user assets), a dedicated persistent block volume is mounted to /data, surviving both sleep cycles and container upgrades.

8. How does Thanaton compare to Fly.io Machines, AWS Lambda, and Modal?

We respect our competitors: Fly.io supports auto-stopping and starting machines; AWS Lambda supports WebSockets via API Gateway; Modal provides excellent Python developer experience.

Thanaton's unique distinction:

• Sub-12ms Wake-Up: Faster than Fly.io's 300ms–800ms container start, allowing real-time synchronous user requests without visible UI lag.
• Full Linux Kernel: Unlike Lambda's restricted execution environment, Thanaton provides a complete Linux guest kernel (run custom daemons, eBPF, background threads, and raw TCP services).
• Zero Compute Markup: Deploy self-hosted on your own AWS/GCP nodes with 100% data sovereignty, paying raw cloud compute rates rather than 3x-5x managed sandbox markups.

9. How do I remotely connect, spawn a microVM, or integrate via MCP?

You can interact with Thanaton in three immediate ways:

A. Direct REST API (cURL):

curl -X POST "https://ciel.theeducode.com/v1/sandboxes/spawn" \
  -H "Authorization: Bearer esk_live_demo10k" \
  -H "Content-Type: application/json" \
  -d '{
    "runtime": "node22",
    "command": "node -e \"console.log('Thanaton MicroVM Ready');\"",
    "timeout_sec": 30,
    "memory_mb": 256
  }'

{
  "mcpServers": {
    "thanaton": {
      "command": "npx",
      "args": ["-y", "@thanaton/mcp-server"],
      "env": {
        "THANATON_API_KEY": "esk_live_demo10k",
        "THANATON_GATEWAY_URL": "https://ciel.theeducode.com"
      }
    }
  }
}

from ciel import ThanatonClient

client = ThanatonClient(api_key="esk_live_demo10k")
vm = client.spawn(runtime="python3.11", memory_mb=512)
result = vm.exec("python -c 'print(42)'")
print(f"Boot Latency: {result.latency_ms}ms | Output: {result.stdout}")
vm.sleep()  # Reclaims 100% host RAM in 7ms