The pattern that's increasingly common is having a pilot or orchestrator agent sitting on top of the fleet that manages this.

The other thing is if you're running large workloads that span many machines (e.g. software factories, model training or RL environments), then over time you'll end up with orphaned artifacts that will need to be maintained (think security groups, volumes, elastic IPs etc).

Ultimately, most of our customers today just want to be able to spin up a powerful & reliable VM without worrying about DevOps or any other kind of maintenance :)

The other option is to define your entire environment as code using nix (we have native NixOS support). For example, you can use an agent to author code which declares everything on your machine: packages, libraries, shell, vim config... And then you can take that code and use it to rebuild a new VM on machine0 whenever you like (or somewhere else).

Docs here: https://docs.machine0.io/examples/nixos

This gives you the best of both worlds: agent native, CLI-first DX with the reliability and performance of a traditional cloud.

Demo: https://www.youtube.com/watch?v=gyllkZ0M04E

Agent workloads are moving from ephemeral to always-on. A coding agent working on a complex feature runs 6-8 hours. Agent orchestrated training & RL runs take days. OpenClaw & Hermes run 24/7. As you run more in parallel:

- Resources: a few agents on a large codebase saturate RAM and CPU. Model training and RL needs GPUs you don't have.

- Security: `--yolo` on your personal machine is one prompt injection away from exfiltrated credentials.

- Availability: close your laptop and the agent dies mid-task.

- Isolation: there's no clean line between you and the minimum your agent actually needs.

machine0 gives every agent its own computer. It's a CLI simple enough that both humans and agents use it without reading docs: `machine0 new mybox` creates an SSH-ready VM with a static IP and HTTPS endpoint. Always on (with 99.99% VM level uptime) until you switch it off.

- Billed by the minute. 1 vCPU / 1 GB at $0.013/hr up to 60 vCPU / 240 GB, plus GPUs from RTX 4000 Ada to 8×H200.

- Suspend, snapshot and resume. Making it easy to pause your work, and come back to it later. Or to make a golden master image to stamp out clones for a fleet.

- Block storage. Persistent volumes (from 10 GB to 16 TB) that you can manage with intuitive grammar: `--yolo` and attach to your VMs.

- Profiles. Bundles of credentials, MCP connections, prompts, and env vars, injected at VM creation. So each agent gets exactly the capabilities you choose, and nothing else.

- Agents self-serve. Hand the CLI or MCP server to Claude, Codex, or OpenCode and it manages its own fleet: spin up a box for a build, snapshot it, tear it down.

- Reproducible Builds. Using NixOS flakes or Ansible playbooks with Ubuntu.

How do people use it today?

- Agent fleets. People run a pilot agent that scopes work and delegates it to sub-agents, each on its own VM: shape a project with the pilot, and the workers implement it and open PRs. One customer runs hundreds of machines at once, spun up and torn down from the CLI.

- Model optimization & RL environments. ML teams use machine0 for agent-orchestrated RL environments and model optimization work. One customer runs RL environments on 60 vCPU machines that stay up for days at a time; another keeps a suspended H100 around and points an agent at it overnight to grind on inference-speed optimizations.

- Product infrastructure. One customer builds their product on top of machine0 rather than using it themselves: every user session gets a fresh XL machine from a versioned image of their own agent runtime. They've shipped hundreds of versions of that image and launched thousands of machines, most alive for two minutes.

What’s under the hood?

Every machine is a full KVM virtual machine, not a container or sandbox. You get the real GPU exposed to the guest with its actual driver, kernel-level access (load any module or driver you want), and no syscall-interception layer between you and the hardware. The stack itself is deliberately dull: TypeScript, Postgres, Redis. We weigh heavily towards security, reliability and performance making machine0 ideal for sustained compute intensive workloads. About me

I've been building cloud infrastructure for about 15 years. I dropped out of a PhD at Imperial College London on cloud resource allocation, later spent six years as co-founder and CTO of Upflow (YC W20), owning DevOps, infra and security personally the whole way to 7-figures in ARR because it was too high-stakes to delegate. machine0 started as a tool for me, I’m my own first user :) Asks

Would love you to try it out and give us your feedback (see below). Or if you’re a company looking for compute for software factories, model training or RL environments, feel free to reach out at barnaby@machine0.io

  # install machine0 
  $ curl -LsSf https://machine0.io/install.sh | sh

  # create a machine and ssh in
  $ machine0 new myvm
  $ machine0 ssh myvm

Comments URL: https://news.ycombinator.com/item?id=49348136

Points: 79

# Comments: 42

It'll click faster if you learn with an agent!

Just point your agent at a machine0 VM and say "make a machine that does X", then you get code you can use to build on any nix box and you'll always get the same result.

Once you experience this, it's hard to go back to a "traditional" OS, you'll want to nixify everything :)