Skip to main content
A vm instance is a whole Linux machine with its own kernel, not a sandbox. Everything on this reference works the same way: the same keys, the same endpoints, the same URLs, the same billing. What changes is what runs inside. Reach for it when your workload needs the kernel itself:
  • Docker, Compose, and buildx. Build and run containers, including ones that need privileged mode or their own networks.
  • Kubernetes. k3s runs with its node Ready and pod networking working.
  • Databases. Postgres, MySQL, Redis, anything with its own storage engine.
  • Android emulators. /dev/kvm is present inside the machine, so an AVD boots with hardware acceleration instead of crawling.
A default instance is the right choice for everything else, and it starts faster.

​
Create one

curl
agent37-ubuntu is Ubuntu 26.04 with Docker, Compose, and buildx installed and dockerd already running. It is built for this type, so it only runs as a vm and a create without "type": "vm" is a 400. Your own custom image works too: pass "type": "vm" with any template. Two things to know first:
  • A container runtime inside the machine must keep its data on your billed disk. The writable root is an overlay, and pulling an image onto one fails. Point Docker at $HOME with dockerd --data-root "$HOME/docker" (or /etc/docker/daemon.json), and k3s with --data-dir "$HOME/k3s". agent37-ubuntu already does this.
  • Your entrypoint is PID 1, and there is no init system. An image whose entrypoint is systemd is not supported, the same as on Docker. Run your processes from your entrypoint, or install them and start them over SSH.

​
Getting in

There is no routed web port by default: agent37-ubuntu serves nothing, so its default_port is null and the bare instance URL has nothing behind it. Use SSH for an interactive shell (one agent37 ssh setup first), or exec for one-off commands:
curl
Anything you do serve gets a URL like every other instance: {id}-{port}.agent37.app for your workspace’s keys, or a public port for an unauthenticated one.

​
Sizing and price

The same four shapes, and compute meters at 4x the default rate, like a Performance instance: a VM’s RAM is reserved for it alone and its vCPUs are its own. Disk is unchanged at $0.09 per GB per month. A funded workspace is required: add balance before the first create.

​
Lifecycle

stop, start, restart, update, and resize all work, and your billed disk survives every one of them. The machine cold-boots on start and on any resize, so in-memory state is lost: anything that has to outlive a restart belongs in a file under $HOME. Growing the disk extends it in place and your filesystem grows into the new space on the next boot, so the data is kept. Disk only grows, as on every instance.

​
Backups

Backups work exactly as they do on any other instance: a week of daily restore points plus one you take on demand, listed and restored by id, and a restore replaces the data it finds rather than merging into it. Two things are worth knowing on a VM. A backup is taken from the machine’s disks, so it captures what your programs have written to disk, not what they are still holding in memory: a database is backed up the way pulling the power cord would leave it, and recovers on the next start the same way. That is the same guarantee a VPS snapshot gives you, and it is why a backup that has to be exact should be taken with the machine stopped, or alongside your database’s own dump. And a restore cold-boots the machine, so in-memory state is lost either way.

​
What is not available yet

Everything else on this reference behaves identically: public ports, domains, SSH keys, logs, metrics, and exec. Crons post a prompt to an agent’s chat API, so they need a template that serves one: agent37-ubuntu does not and refuses them, while your own image takes them like any other instance.