Thank you again for all your help — it’s truly appreciated.
I have a quick question regarding my app setup. I currently have two machines configured:
Machine A has a dedicated IP address attached and is used for serving my API.
Machine B is the second machine.
The issue I’m facing is that sometimes Machine A stops automatically, and Machine B starts in its place. This is causing problems, as I always want Machine A to run — since the IP address is attached to it. It seems like Machine B is acting as the default fallback, which is not what I want.
Could you please help me configure it so that only Machine A starts, and prevent Machine B from taking over automatically?
Hm… If you really never want Machine B to run, then you can just destroy it (fly m destroy).
The Fly.io platform is designed for ≥2 Machines, though, so you will get notably worse reliability in general. For example, when the underlying physical host that Machine A is on eventually fails, then your app will be offline until you can manually provision a replacement.
Likewise, you will typically be offline for a few seconds each deploy.
It would be better to pay for a second static egress IP—and whitelist that one, too.
Standby machines can be used for failover; processes can be used if you want a second machine that is intended to serve a different purpose than serving requests (for example, to handle background jobs).
I haven’t been able to get this to trigger, in tests, actually. Even with fly m destroy --force on the original Machine, the standby never starts (on its own).
Absolutely true for ingress, but I’m pretty sure OP means the static egress IP from the previous thread.
(It would be convenient if those too could be shared across an entire application, without additional proxying, etc., of course, .)
ah, an important note: standby machines are only started when the host goes down, not whenever the primary machine is stopped.
I agree! there is a decent amount of technical work behind such a feature though, so it is unlikely to happen anytime soon, unfortunately.
(there is also some UX work to do: it is not possible to use the same egress IP across regions, so would need to decide on UX for scaling up to new regions, etc…)
I think I found solution. I deleted Machine B and assigned new machine with region far from what machine A have, So now machine A is always works as priority.
While creating second machine I have cloned machine A and it looks like static IP of machine A works with new Machine created using clone. I will do more testing for this and come back here to post.
.)