Machines

Lifecycle states

State	Billed?	Has IP?	Notes
`CREATING`	No	No	Provisioning (1-3 min, longer for large images). Billing starts once it’s running.
`RUNNING`	Yes	Yes	Ready for SSH
`STOPPED`	Yes	Yes	Resources reserved. Still billed at full rate.
`SUSPENDING`	—	—	Snapshotting in progress
`SUSPENDED`	Image storage only	No	Cloud instance deleted. ~$0.078/GB/mo.
`UNAVAILABLE`	No (snapshot storage, if any)	No	Couldn’t start or resume (provider out of capacity). No running VM, so no machine billing; a retained snapshot bills storage. Recovers automatically (see below); `machine0 start` retries immediately.
`ORDERED`	No	No	A standing order placed with `machine0 order`: the size was out of stock, and the VM is created automatically as soon as capacity appears (checked every minute) — you get an email when it’s running. Expires if capacity never appears before the order’s deadline (also emailed). `machine0 start` tries to fill it immediately; destroy cancels the order.
`ERRORED`	Yes, if the VM ever started	—	Something went wrong creating or operating the VM. `machine0 get` shows a `Status Info` row explaining what happened and how to recover: if the cloud instance is still running it’s checked automatically within a few minutes and recovered if possible (billing continues meanwhile); otherwise `machine0 start` retries. A failed create that never started bills nothing. A failed resume keeps your data safe in the suspend snapshot — retry with `machine0 start`; destroying the machine also deletes the snapshot. If it stays `ERRORED` with no snapshot, destroy it and create a new machine.
Destroyed	No	—	Gone. Irreversible.

Out-of-capacity (`UNAVAILABLE`)

When the cloud provider has no capacity for a VM’s size (mostly GPU sizes), the create or resume lands in UNAVAILABLE. machine0 get explains what happened, and recovery is automatic:

A resume that failed returns to SUSPENDED within about ten minutes. Your data is safe in the suspend snapshot the whole time.
A brand-new VM that never started is removed automatically about 30 minutes after the failure.

machine0 start <name> retries right away in either case — it fails fast with a clear error if the size is still out of stock. Rather than retrying by hand, you can place a standing order with machine0 order: the VM sits in ORDERED (unbilled) and is created automatically the moment capacity appears, with an email when it’s up.

Stopped VMs bill at full rate because cloud resources stay reserved. Suspend or destroy to stop machine billing.

Suspend vs stop vs destroy

Stop keeps the cloud instance alive. Resources stay reserved, billing continues, IP is retained. Use when you need the VM back quickly with the same IP. Suspend snapshots the VM, deletes the cloud instance, and stops machine billing. You pay only image storage (~$1.95/mo for a 25 GB boot disk). Disks attached to the VM keep billing while it is suspended and are re-attached on resume. Resume later with machine0 start — the VM gets a new IP. The snapshot (named suspended-<machine>-<date>-<time>) is the suspended VM’s only copy of its disk: deleting it with machine0 images rm also destroys the suspended machine. Destroy deletes everything permanently.

HTTPS proxy

Every VM gets authenticated HTTPS at https://<name>.mac0.io, proxying to port 80. No DNS or TLS setup needed. Renaming a VM updates the endpoint. A running machine’s detail panel has a Web tab that renders this proxied URL right in the dashboard, with a reload button and an open-in-new-tab link in its toolbar. Stopped machines show a hint to start first. See Networking → HTTPS proxy for the embedding rules (apps with their own login may need the new-tab link).

In-browser terminal

VMs created with a managed key get an in-browser shell from the web dashboard, right inside the machine’s detail panel. See SSH → In-browser terminal.

Metrics

Opt-in, per machine, off by default. When enabled, machine0 connects to the VM over SSH every 2 minutes and reads guest-level metrics straight from the OS: CPU, load averages (1/5/15 min), memory, disk I/O throughput, network in/out, root-disk usage, and GPU utilization (on GPU sizes). The machine’s detail panel in the web dashboard graphs CPU %, Load (1/5/15), Memory %, and Disk I/O (read/write) with 1h / 24h / 7d ranges and a synchronized crosshair — hovering one chart shows the value tooltip on all of them at the same timestamp. Samples are kept for 7 days.

machine0 new my-vm --metrics true     # enable at create
machine0 update my-vm --metrics true  # or later
machine0 update my-vm --metrics false # turn off

You can also enable it from the dashboard: on a machine with a managed key, the detail panel’s Metrics tab shows an Enable metrics button (with a confirmation step) instead of empty charts. Notes:

Requires a managed SSH key (the server must be able to SSH in — the same constraint as the in-browser terminal and profiles deploy). Enabling with your own public key fails with a clear error.
Collection is passive and fail-soft: a missed sample (VM busy, network blip) is a gap in the chart, never an error on the machine.
Sampling pauses automatically while the VM isn’t RUNNING and resumes when it is. After a reboot or resume-from-suspend the charts show a brief gap where the OS counters reset.
The only lifecycle consumer of metrics is opt-in idle detection below; with it off, metrics can never affect the machine’s lifecycle or billing.

Idle detection

Opt-in, per machine, off by default. When enabled, machine0 watches the machine’s metrics and suspends or destroys it after a sustained window of inactivity — useful for dev boxes and agent sandboxes you forget to turn off.

machine0 new my-vm --on-idle suspend                        # default 30-minute window
machine0 new my-vm --on-idle destroy --idle-timeout-minutes 120
machine0 update my-vm --on-idle suspend                     # enable later
machine0 update my-vm --on-idle none                        # disable

A machine counts as idle only when, for every ~2-minute interval across the entire timeout window, all of these hold:

CPU below 10% and below half a core busy (so a fully-loaded single core on a big VM still counts as active)
Disk I/O below 1 MB/s (catches I/O-bound jobs the CPU test can’t see)
Network below 30 KB/s in+out (the metrics sampler’s own SSH traffic is ~100× below this, so it never counts as activity)
GPU below 20% on GPU sizes — and if GPU telemetry is missing on a GPU size, the machine is treated as busy, never idle

Missing data never counts as idle. The decision needs an unbroken run of samples covering the whole window: a sampling gap, a counter reset (reboot), or stale data all reset the clock. Enabling idle detection — and every start, resume, or reboot — also starts a fresh observation window, so a machine is never actioned on old history. In practice a machine becomes eligible roughly timeout + a few minutes of sampling after it last did real work. Notes:

Enabling --on-idle turns on --metrics automatically and has the same managed SSH key requirement. Turning metrics off while idle detection is active is an error — set --on-idle none first.
Not yet available on AMD GPU sizes (gpu-mi*): GPU telemetry on that hardware isn’t supported, so a policy there could never fire — enabling is rejected with a clear error.
--on-idle suspend behaves exactly like machine0 suspend: the disk is snapshotted and you can resume later with machine0 start.
--on-idle destroy behaves exactly like machine0 rm: the VM and its data are permanently deleted, with no snapshot. The CLI asks for confirmation when you set it from a terminal (skip with -y).
--idle-timeout-minutes accepts 10–2880 (default 30).
Idle detection only evaluates RUNNING machines: a machine you stop keeps billing and is never idle-actioned — suspend or destroy it yourself when you’re done with it. For a standing order, the idle clock starts when the order fills, not when you place it — an unattended fill gets suspended/destroyed about one timeout after boot, so prefer suspend on orders.
Known limitations: a very quiet interactive SSH session (an idle shell, or slow typing in an editor) can fall under the activity thresholds and be treated as idle; GPU utilization is read as an instantaneous gauge every ~2 minutes, so heavily duty-cycled GPU bursts between samples may not register as activity; and network activity counts inbound traffic as delivered to the VM — sustained unsolicited traffic at the machine’s public IP (even to closed ports) keeps it looking active and delays the idle action. If any of these patterns fits your workload, prefer --on-idle suspend over destroy.

Commands

See CLI reference and MCP reference. The web dashboard’s Update action covers name, default SSH username, metrics, and idle policy; the legacy SSH client initial command is editable only via the CLI and MCP.

Introduction

Examples

Platform

Reference

Lifecycle states

Out-of-capacity (`UNAVAILABLE`)

Suspend vs stop vs destroy

HTTPS proxy

In-browser terminal

Metrics

Idle detection

Commands

​Lifecycle states

​Out-of-capacity (UNAVAILABLE)

​Suspend vs stop vs destroy

​HTTPS proxy

​In-browser terminal

​Metrics

​Idle detection

​Commands

Lifecycle states

Out-of-capacity (`UNAVAILABLE`)

Suspend vs stop vs destroy

HTTPS proxy

In-browser terminal

Metrics

Idle detection

Commands