███████  ██        ██████   ██████
██    ██ ██       ██    ██ ██
███████  ██       ██    ██ ██  ████
██    ██ ██       ██    ██ ██    ██
███████  ████████  ██████   ██████

New Features for April 8th, 2026

April 8, 2026 · ← All posts

Two important upgrades are live today: Cloud Hypervisor boxes with nested virtualization, and a stable JSON interface for scripting and automation.

Cloud Hypervisor via --ch

Firecracker remains the default backend for new boxes because it has the fastest snapshot/resume path. But now, when you need nested virtualization, you can create a box on Cloud Hypervisor with --ch.

# create a box on Cloud Hypervisor
$ ssh shellbox.dev create nestedbox --ch

Creating box...

Box 'nestedbox' created successfully (x1)
URL:   https://nestedbox-a1b2c3d4.shellbox.dev
Email: nestedbox-a1b2c3d4@in.shellbox.dev

Connect with: ssh nestedbox@shellbox.dev

Inside a CH-backed box, /dev/kvm is available. That means you can run KVM workloads inside your shellbox box — Firecracker, QEMU, or other virtualization-based tools — as long as the host supports nested KVM.

$ ssh nestedbox@shellbox.dev
root@nestedbox:~# ls -l /dev/kvm

This is especially useful for CI jobs, low-level systems work, sandboxing hypervisors, kernel experiments, and anything else that needs real virtualization inside the guest.

No migration, no surprise backend switch

Backend choice is per box. Existing boxes keep using the backend they were created with. Firecracker boxes stay on Firecracker. CH boxes stay on Cloud Hypervisor. Nothing is silently migrated underneath you.

In practice, that means you can keep using the default Firecracker path for fast snapshots and create CH boxes only when you need nested virt:

# default backend
$ ssh shellbox.dev create fastbox

# nested virtualization backend
$ ssh shellbox.dev create kvmbox --ch

--json for automations

shellbox commands now have a machine-readable mode built for scripts, CI, agents, and automation tooling. Add --json and you get structured output instead of human-formatted text.

# create a box and capture its metadata
$ ssh shellbox.dev create api-box --json
{
  "name": "api-box",
  "id": "a1b2c3d4-...",
  "size": 1,
  "backend": "fc",
  "url": "https://api-box-a1b2c3d4.shellbox.dev",
  "connect": "ssh api-box@shellbox.dev"
}

# list boxes and filter with jq
$ ssh shellbox.dev list --json | jq '.boxes[] | {name, state, backend}'

# delete when done
$ ssh shellbox.dev delete api-box --json

You can use this from shell scripts, Python, GitHub Actions, CI runners, or AI agents without scraping terminal text.

Backward compatibility guarantee

The JSON output is intended to be stable over time. Fields may be added, but existing fields are not removed or renamed, and existing types do not change. If a breaking change is ever necessary, it will ship under a new flag such as --json-v2 rather than changing the meaning of --json.

That means you can build automation against today's output and expect it to keep working as shellbox grows.

Full schema reference

The command-by-command JSON schema reference is live at /ssh-api.html. You can also inspect the current interface directly from the CLI:

$ ssh shellbox.dev help --json

Try it

# fast default box
$ ssh shellbox.dev create dev1

# Cloud Hypervisor box with nested virt support
$ ssh shellbox.dev create dev-kvm --ch

# automation-friendly output
$ ssh shellbox.dev show dev-kvm --json
$ ssh shellbox.dev list --json | jq '.boxes[] | select(.backend=="ch")'

Questions or issues? Open an issue or email support@shellbox.dev.