bwm
Joined 15 years ago
Joined 15 years ago
`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.
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.
https://x.com/barnabymalet
YC Badge: 0x2c9e7942fe685aa4037b234c56a392831d1b8537