My understanding is, if I use machines in a similar way I’ll end up with a lot of idle machines accrued over time.
A single instance of a machine app (one that’s
stopped but not
destroyed) can continue to serve multiple requests over its lifetime, even concurrently if required (see
I like to think of machine apps as Amazon API Gateway + AWS Lambda.
My workflow is: After creating a Fly machine app, I
flyctl deploy the docker image (to which ever regions), and then send
tcp requests to it (unsure if machines support
udp should work), after having allocated it
v6 public ips. I am not really sure if machines work with Flycast IPs (it’d be cool, if they did).
When a machine app isn’t serving any requests, it is free to
stop itself (or can be stopped with
flyctl m stop <machine-id>. Fly guarantees that
stopped machines will be woken up whenever a request comes in (typical cold starts:
This Fly blog post has a nice rundown of deploying a machine with
flyctl (which is what I prefer using over Fly’s GraphQL / REST API).
if I use machines in a similar way I’ll end up with a lot of idle machines accrued over time. Is that correct?
If I am not wrong, if one keeps destroying but also recreating more machines, I don’t think they’ll accrue a collection of them. Destroyed machines are relegated to the dustbins of history, never to be seen again (except for in that month’s invoice).
My understanding of machine apps is just from fiddling with it for the past few hours, so that’s one disclaimer. And for the next one: I do not know anything about Heroku, so I can’t really answer your question of what’s the Fly equivalent of