I’ve seen it mentioned that there are some features not (yet) supported on machines apps, but I can’t find an actual breakdown of why or when to pick nomad vs machines.
I’ve got a nomad app but which will need some kind of scheduled worker for which scheduled machines would be ideal. I’m also not sure how to convert the app as I don’t want to loose all the secrets or change the name so would need a way to migrate runtimes seamlessly.
Anyone able to share a comprehensive comparison of the two runtimes?
Machines are basically “v2” of the apps platform, and will some day be the apps platform.
- Has an API
- Will stop the VM if the main process stops at
- Will start/awaken the VM on network access (if a service is defined for a port)
- Are ephemeral (stop / start puts it back into a “fresh” state, data doesn’t persist)
- this makes them re-usable, you don’t necessarily need to destroy/re-create a machine
- You can create multiple machines within an app.
- If multiple machines are listening on the same port (defined in the
services config) within an app, Fly’s proxy will load balance between those machines for any given network request to that port.
Right now you can’t migrate a Nomad app to a Machine app. You can destroy an app and recreate it as a machine app, or create a new app for the purpose of using the scheduler feature.
This would unfortunately mean re-setting your env vars and secrets.
Machines has an API, but you can use
flyctl to manage machines as well. When you hear us say “some features are not yet supported by machines”, that’s purely true in some cases I think (trying to remember what they might be…maybe defining multiple processes is an example).
But what we’re mostly staying is that
flyctl is in need of changes to manage some aspect of machines so it’s on par with the Nomad-based app experience.
You can do most things yourself with Fly’s APIs
Let me know if I’m not filling in any details you wish I did! This could turn into some documentation.
The list doesn’t mention the memory/cpu limits that machines currently incur. 4096 is pretty low compared to the nomad v1 platform.
Ah, let me see if I can get that documented. It’s actually something in flux.
Rumor has it that the shared CPU type can get up to 16gb of ram right now.
Yeah @fideloper-fly, please add a section to docs about scaling/sizes at some point there was only „shared“, so no there is „dedicated“? And „shared“ can use 16gb ram? I’m a bit confused with the current state.
I’m working on deploying a machine via the Terraform provider. It appears that release commands are only supported via flyctl.
Any workarounds or plans for this? My use case is running database migrations for my Phoenix application.
Yes I’ve noticed that trying to deploy an app with a release command fails stating that it required the nomad platform and doesn’t work on machines.
I think the docs site should have a comparison of the two runtimes and what’s available where so we can choose the best option for a given app.
Same. On the other hand, the docs site is open for community edits, btw.
release_command is the same runc / docker image exec’ing but a different
CMD but on a single machine? If so, I can see how this can be built in a ephemeral one-box / canary style setup?
After a bunch of time , docs are updated for Machines:
- Pricing: Fly App Pricing · Fly Docs
- Machine specific stuff: Fly Machines · Fly Docs
- Specific docs on sizing a machine: Machine Sizing · Fly Docs