We launched jilebi a few weeks ago and whenever I try to pitch it to potential customers I always get a lot of questions about what a jilebi machine is, what it can do and why you would want to use one over other sandbox providers, a generic VPS or your mac mini. I thought it would be a good idea to write about what I think is possible with jilebi, how I use it and the problems I’m hoping to solve for customers.

The Problem to solve

Initially I wanted multiple environments to build plugins for my extensible mcp - jilebi-mcp. When I saw a MCP I found interesting, I wanted to convert it into a plugin which an AI agent can do pretty easily. This is hard when your local machine sits at home behind a private network and is turned off.

Professionally I use a macbook pro M2 with 16GB of RAM and a 512GB disk. I work on multiple open source and closed source projects that are in rust (Jilebi is written in rust BTW) and haskell; with tasks that can be done by AI agents with some feedback/review. These are pretty large and take a good amount of resources to compile. Some of them are also nixified, which adds to disk usage. Breakdown of my problems:

• git worktrees aren’t really an option for parallelization in my case, even if I use kache for build artifacts
• when running multiple agents and compiling projects via opencode, I eventually run in to the famous spinning beach volleyball of doom due to resource constraints
• agents sometimes want to do some wacky stuff on /tmp like clone linux, I don’t want this to happen on my mac
• PR reviewers - both PMs and Engineers are hesitant to review, since they’d like to run and play with changes before reviewing the code (this makes code review way easier)
• even before a review, getting feedback means getting on a huddle with someone and showing them a demo. “Syncing” up takes time
• I don’t like AI agents having access to sensitive/personal files on my local machine
• my mac would run out of battery
• my mac would go to sleep during execution
• I can’t access my coding agents when AFK

Thinking more on this, I listed down the things I would need to actually maximize my productivity:

• the capability to extend my dev machine with isolated sandboxes
• the sandbox needs to be performant and secure
• setup the sandbox quickly with the software I need, should be under 5s
• be able to clone the machine and start hacking on the cloned version (git branch, worktree alternative)
• expose apps from my sandbox to the internet
• be able to share these apps easily with colleagues and only them
• go to sleep only when I’m not using them so I get billed less
• should be easy to use with no additional tooling

Achieving the things I wanted with containers/k8s/VPS/existing sandboxes needs a lot of work and software from me. I also live in India, and the dollars I would have to shell out to current sandbox providers/VPSs to get what I wanted would not work out economically. I could just build something I needed and wanted, and that is a fantastic excuse to start a side project.

Meet the result of my efforts - Jilebi Machines.

What is a Jilebi Machine?

Jilebi machines are fundamentally microVMs that

• run on powerful bare metal servers
• have persistent nvme disks with a btrfs file system
• can be snapshotted and restored
• can be paused and resumed
• are fully monitored
• get a subdomain with TLS at *.jilebi.dev

They are allocated, managed, and monitored with custom software written around Cloud Hypervisor called agorc and trace. A control plane exists to start/pause these machines, manage different nodes that run agorc + trace and provide a UI called console for users to provision microVMs.

I chose bare metal servers over running microVMs on KVM enabled VPSs because of the performance, flexibility with allocations and cost benefits. Jilebi lets you allocate machines with

• 1 - 16 vCPUs
• 1 - 16 GB RAM
• 30 - 65 GB of nvme storage

In any configuration you want. The OS is an ubuntu minimal image pre-installed with git, curl, fzf, batcat, etc. During setup, you can install nix, opencode, claude code, codex, docker and other programs in the software catalog.

The networking around jilebi machines is also simple - no jilebi machine is exposed to the internet by default. It doesn’t have a public IP address. So how do you access it? Another application called proxy lets you

• ssh into your machine with your keys that you set during creation of the machine
• expose ports from your machine for applications to be accessed from the internet

How I use jilebi machines now

• I run opencode web and when away from my machine I can use their awesome web interface
• I won access to chatGPT pro during vibecon India, so I exposed codex over ttyd
• Now I run btop till I expose metrics for a jilebi machine
• I host plane to track my tasks
• I host open web UI for chatting with models
• I expose apps like the one you’re on right now so I can test and verify changes

I think I’ve solved the problems I faced, and I’m hoping that jilebi solves your problems too (If not let me know). Now I’m solving harder problems that popped up from what I started like programmability of jilebi, efficient hardware use, cheaper jilebi machines, orchestration and getting bare metal servers near customers without going bankrupt (cheers OVH and Hetzner). Join me along on this journey to build a sandbox provider/cloud. I say cloud because David Crawshaw’s post on working on exe.dev really resonated with me, and I’d like to also build a cloud that I would like to use.

If you’ve liked what you’ve read about Jilebi machines, give them a try at jilebi.ai