HNHacker News
TopNewBestAskShowJobs

bwm

674 karma · joined March 18, 2011

Founder machine0 (YC S26). Previously CTPO Upflow (YC W20).

https://x.com/barnabymalet

YC Badge: 0x2c9e7942fe685aa4037b234c56a392831d1b8537

submissionscomments
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
No CRIU. Snapshots are at the disk layer, not RAM.

`machine0 suspend` takes a full disk snapshot and tears down the compute; you keep paying only for storage. `machine0 start` restores the disk and cold-boots the VM from it. So processes restart, they don't resume mid-execution. Practically: anything that survives a reboot survives a suspend.

bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Ohh nice catch! I'll update to the latest version and republish the base images tomorrow. But in the meantime, you can also just rebuild with the flakes: https://github.com/fdmtl/machine0-nixos
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Modal is an ephemeral sandbox, whereas machine0 is a persistent VM you own: root, your own driver/CUDA/kernel, GPU passed straight through, and a fixed GPU per size.
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Hi! OAuth token refresh is handled within the profile, and will automatically get picked up by agents using it. If you actually want to pull or rotate a credential, you can do that too and re-inject.

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

bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Hi! No not for every tool call. People are spinning up VMs for tasks that require sustained compute for hours or days. For example, they’ll deploy an agent with tools and a prompt to take an entire feature from spec to PR. Or an auto-research loop to improve the performance of an inference model.
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Hi! We're not the cheapest compute on the market. But we are cheaper than most sandbox providers / neoclouds. And customers are happy to pay for agent first DX coupled with the performance and reliability you expect from an established cloud.
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Hi! Sure: (1) running agent fleets for software factories, (2) Model training and RL environments orchestrated by agents and (3) as a backend for agentic products and platforms.
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Yes, we're building more tooling around fleets, starting with profiles that let you manage named sets of credentials and MCP tools outside of the VM. We're also looking to support more backends and also BYOC.
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Hi! You get GPUs, much bigger machines and full control of the VM down to the drivers, kernel etc. It's also a lot cheaper, especially for compute intensive workloads. Also, if you're running agents in the VMs, you get native support for credential and MCP tool injection via profiles. We support NixOS too!
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
You can totally ask an agent to orchestrate an existing cloud. But their APIs weren't designed for agentic orchestration, so it'll be more expensive in terms of context / turns (machine0 grammar is simple: new, ls, rm...).

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 :)

bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Hi! Yes that's right. Sorry if it wasn't clear, but you do pay for storage. Cost is nominal compared to compute ($0.078/GB/month).

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

bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
I have a payments background. So maintaining a very high bar on security, reliability and performance as usage scales is super important.
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Their machines are good & they have a partnership program that's fast and compatible with the model.
bwm··on Launch HN: machine0 (YC S26) – Persistent CPU and GPU VMs from the CLI
Hi! It sits on top of DigitalOcean. We also have BYOC on the roadmap.

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

bwm··on Launch HN: Context.dev (YC S26) – API to get structured data from any website
Awesome! Been great watching this product improve so quickly, can't wait for what's next :)
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
You retain the IP as long as you keep the VM. If you delete it, you'll loose the IP.
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
Yes, it's ideal for this!
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
You could start here: https://github.com/fdmtl/machine0-nixos

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

bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
Yea, I totally get it. The thing is agents change the game. You no longer need to worry about the learning curve or how best to implement.

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 :)

bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
Thanks! I'm so happy to be building this :)
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
Soon!
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
It's funny, because my homelab is exactly where this started :)
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
Would love to join the next one!
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
I'm also a big fan of proxmox! Would be happy to help you extend machine0 though :) Happy to chat about your requirements over email: barnaby@machine0.io
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
You could point your agent at the machine0 CLI and ask it to :)
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
It's not possible to modify the VM outside of the flake :)
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
Thank you!
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
Always happy to meet others that are working with NixOS :) I've just added the License - it's MIT.
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
Been great having you :)
bwm··on Show HN: machine0 – Persistent NixOS VMs You Control from the CLI
Thanks! Yup, one of the benefits of defining your VMs as code using Nix, is that you can take that code to any supplier, and you're guaranteed exactly the same build.
Page 1 of 3Next →