Of all the products in this comparison series, boxd.sh is the closest to Jilebi philosophically: persistent KVM microVMs, forkable in milliseconds, pausable to near-zero cost, reachable over SSH with public HTTPS URLs. If you like Jilebi’s pitch, you will like boxd’s — so the differences are worth spelling out precisely.
TL;DR
| Dimension | Jilebi | boxd.sh |
|---|---|---|
| Price model | ~$0.009/vCPU-hr + ~$0.009/GB-hr running, disk-only paused | Credit-based ≈ €0.049/vCPU-hr + €0.015/GiB-hr RAM + €0.0001/GiB-hr disk; default 2 vCPU / 8 GiB ≈ €0.22/hr running |
| Unit economics | Lower per-unit running rates | Sleep-to-zero (suspend/hibernate) pricing ladder is more granular |
| Performance | ~50ms boot, auto-sleep/wake; 1–16 vCPU / 1–16 GB / 30–65 GB NVMe per machine on bare metal | Default 2 vCPU / 8 GiB / 100 GB per VM; ~50ms cold boot, ~100–200ms fork, sub-ms suspend resume |
| Ease of use | Web console + SSH + software catalog | CLI/gRPC-first (boxd machine new/fork/exec), SSH, per-VM public URLs |
| Technology | Cloud Hypervisor microVMs, btrfs snapshots, proxy networking | KVM microVMs (own kernel), checkpoints/snapshots, hibernate-to-disk, EU-hosted, self-hostable single Rust binary |
Rates from public pricing pages at the time of writing (September 2026); boxd has iterated pricing (flat €20/mo tiers → credit-based) so verify current numbers.
Price
- boxd.sh rate card: ≈ €0.049 per vCPU-hour while running, €0.015 per GiB-hour of RAM while running or suspended, €0.0001 per GiB-hour of disk actually used. A default 2 vCPU / 8 GiB machine runs ≈ €0.22/hr; suspended (memory warm) ≈ €0.12/hr; hibernated (memory to disk) ≈ disk-only. €30 in starting credits, then credit top-ups. No per-seat fee; quota ~50 machines per org.
- Jilebi: ≈ $0.009 per vCPU-hour + $0.009 per GB-hour while running (≈ $0.108/hr for 4 vCPU / 8 GB; ≈ $0.036/hr for 2 vCPU / 2 GB), disk-only while asleep.
Per running hour, Jilebi’s unit rates are lower (roughly 3–5x on CPU depending on EUR/USD). On lifecycle both sleep automatically: boxd offers a three-state ladder (running / suspended-to-RAM / hibernated-to-disk) with auto-hibernate on idle, while Jilebi auto-sleeps idle VMs to disk-only billing and wakes them on use. boxd’s suspended tier keeps memory warm for sub-millisecond resume at RAM rates; Jilebi’s sleep is disk-only, so you trade warm-memory resume for a simpler two-state bill. Compare with your own duty cycle: steady running favors Jilebi’s rates; workloads that need warm-memory resume favor boxd’s suspend tier.
Performance
Both are hardware-isolated KVM microVMs — a shared-kernel container CVE stops at the guest boundary on either platform. Published figures:
- boxd: ~50ms cold boot, ~100–200ms fork of a running machine (disk + memory inherited), sub-millisecond resume from suspend, ~85ms from hibernate. Fixed default shape (2 vCPU / 8 GiB / 100 GB CoW disk); larger shapes by request.
- Jilebi: ~50ms boot for new machines, free choice of 1–16 vCPUs, 1–16 GB RAM, 30–65 GB NVMe per machine on bare-metal hosts with local NVMe. Idle machines auto-sleep to disk-only billing and wake on use; snapshots capture state explicitly.
So boxd optimizes fork/boot latency at a fixed shape (perfect for “fork fifty sandboxes in parallel”), while Jilebi optimizes per-machine sizing and sustained compute (perfect for “give this compile 16 cores and 60 GB of NVMe”). Neither publishes GPUs today.
Ease of use
boxd is CLI-first and agent-native: boxd machine new, boxd machine fork, boxd machine exec, with the CLI pre-authenticated inside VMs so agents can mint siblings themselves. Every VM gets a public HTTPS URL (https://name.boxd.sh). Fork-before-risky-ops and fan-out patterns are first-class documented workflows.
Jilebi is console-first with a human onboarding path: visual machine creation, SSH keys at setup, software catalog (nix, opencode, claude code, codex, docker), expose-ports-to-*.jilebi.dev when you want them public; idle machines auto-sleep and wake when you return. Private-by-default posture is stricter (no public IP unless you expose a port); boxd leans toward URL-per-VM openness.
Developers who live in terminals and hand agents CLIs will feel at home on boxd. Developers who want a visual console and curated setup will onboard faster on Jilebi.
Technology
| Aspect | Jilebi | boxd.sh |
|---|---|---|
| Hypervisor | Cloud Hypervisor microVMs on bare metal | KVM microVMs, own kernel per VM |
| Storage | Per-machine NVMe, btrfs, snapshots | 100 GB CoW disk per VM, checkpoints + snapshots, fork inherits disk+memory |
| Power states | Running / auto-sleep (disk-only billing), wake on use | Running / suspended (RAM+disk) / hibernated (disk-only), auto-hibernate on idle |
| Networking | No public IP; proxy SSH + selective TLS exposure | SSH + public HTTPS URL per VM; EU data residency |
| Self-host | Managed-first | Single Rust binary self-host; BYOC/on-prem enterprise tier |
| Interface | Console + SSH | CLI + gRPC API + SSH, agent-usable from inside VMs |
boxd’s standout architectural choices are the self-hostable single binary (strong story for EU sovereignty / DORA / NIS2 reviews) and the suspend/hibernate ladder. Jilebi’s are bare-metal placement with per-machine sizing freedom and the AI software catalog.
Pros and cons
Jilebi — pros
- Lower per-unit running rates; simple two-state billing (running vs disk-only sleep)
- Auto-sleep on idle with wake on use — no manual pausing
- Free per-machine sizing (1–16 vCPU / 1–16 GB / 30–65 GB NVMe) for heavy builds
- Private by default; exposure is explicit per port
- Software catalog gets AI tooling installed at creation
- Simple console UX for humans onboarding quickly
Jilebi — cons
- No self-hosted tier; managed-only, fewer regions
- Single sleep state (disk-only) — no warm-memory suspend tier, so no sub-millisecond resume option
- Fixed-shape fork latency not published; fan-out ergonomics less documented
- Smaller docs corpus for agent-loop patterns (fork-retry, fan-out-judge)
boxd.sh — pros
- Blazing fork/boot/resume latencies with documented agent patterns
- Suspend/hibernate ladder with auto-hibernate: genuine sleep-to-zero pricing
- Self-hostable single binary; EU residency and sovereignty story
- CLI + gRPC API usable by agents from inside VMs; URL per VM
- Generous disk default (100 GB CoW) and starting credits
boxd.sh — cons
- Higher per-unit running rates (≈ €0.22/hr for the default shape)
- Fixed default VM shape; bigger machines need a sales conversation
- URL-per-VM openness requires care for sensitive workloads
- Pricing has changed shape before (flat tiers → credits); verify current terms
- No GPUs either
Which should you pick?
- Pick boxd.sh if millisecond fork fan-out, warm-memory suspend/resume, EU hosting, or self-hosting on your own metal are requirements.
- Pick Jilebi if you want lower per-hour running rates, free-form machine sizing up to 16 vCPU with big NVMe, private-by-default networking, and a console-led setup with AI tooling preinstalled.
Honestly, these two agree on the important thing — agents deserve real computers with hardware isolation — and compete on packaging. If that packaging sounds right, try ours at jilebi.ai.