You’re right that Machines are very different to the current v1 Apps (even if they’re beholden to the existing systems Fly has built for v1 Apps). For one, all VM instances of v1 Apps are homogeneous (the exact same RAM, CPU, fly-configuration, docker image etc). Machines, otoh, let you run a heterogeneous VM setup behind a single app (different docker images, RAM, CPU, fly-configuration, etc).
Machines, in addition, can also be stopped and started at will (or in response to incoming requests). I’d imagine, we’d soon be able to pause / resume them too. That said, this flexibility with Machines is at odds with the rigidity of how Fly’s load balancer works (today). And in a sense, Machines are too low-level and easy to get wrong, but that’s exactly what makes them that much more powerful. I mostly like them for their potential cost savings and the fact that they’re not beholden to Fly’s Nomad orchestration layer like v1 Apps.
Well, Fly themselves built Machines for running Postgres. It is prudent to assume that Machine expose the right primitives for anyone to build database services, but if given a choice I’d rather reach for a managed database solution like Xata, TileDB, NeonTech, PlanetScale, AuroraServerless2, AlloyDB, Cloudflare KV / DO etc
Hi @claudio_biale. I believe you can use fly machines clone MACHINE_ID command to spawn more instances of your machine, similarly to how you could do it in V1 with fly scale count 3.
You can view a list of your machines to find an id by running fly machines list