Automatically starting/stopping Apps v2 instances

This is awesome!

One thing I had to figure out was how to enable auto start for a “private app”, and the flycast solution worked just fine.

One thing I can’t seem to get right is the auto stop feature. The app is a Livebook and even without anyone connected it seems to keep it running always and I have no clue what to do to debug it (the app name is moendy-livebook) so my current setup is to manually shut it down after using.

1 Like

I checked if it was working on our side with your app and it seems to be working fine. How long did it stay running for?

Hi, I’d just like to clarify a bit of confusion I have. Is it correct that auto_stop_machines = true is an alternative to having the process exit when idle, with the disadvantage of potentially less clean shutdown? Would it ever make sense to both have auto_stop_machines = true and and auto idle-exiting app, or should I pick one up front? I think it would help a lot to document these trade-offs in the documentation if possible.

Yes. If you’ve implemented a way to stop your machine when it is idle, then you won’t need auto_stop_machine.

This is true for now until we implement using the specified kill_timeout, kill_signal option when we autostop your machines.

It most likely won’t make sense to have both. auto_stop_machines is a convenient way to have your machines stopped for you that covers the most basic need – stop excess machines when your app isn’t receiving enough traffic volume to warrant running all of them. If you have any custom needs, then you’re better off implementing your own way of exiting a machine.

2 Likes

We just added support for this: Autostop Now Respects Kill Signal and Timeout

3 Likes

This is a nice feature as it saves money depending how used is your application. The only thing that is a bit annoying is when we want to access the console via SSH using fly ssh console -C bash for example. If the instance is not running, I am not able to connect it (it make sense), so I need to open the browser in the application, just to be able to connect there.

I don’t know if this is doable or not, but perhaps calling fly console would also start the instance again automatically? It is not a big issue, but it will be a bit less annoying :slight_smile:

1 Like

What is the difference between:

auto_stop_machines = false

And:

min_machines_running = 1

Surely, both, keep your machines, running all the time, if you only have one machine, but I guess this would also apply if the total amount of machines equals the min_machines_running value?

min_machines_running only matters if auto_stop_machines = true. It’s used to configure how many machines to keep running iff you’ve enabled automatically stopping machines.

@senyo There is rly one missing feature that would make this one amazing and rly scalable, min_machines_running PER REGION. Then you can set up it as 1 = no cold starts + instances will always scale up and scale down nicely, each region will have it’s own running one. Do you think this one is possible to see in the future?

2 Likes

At the moment, we don’t have plans to support this. For now, I’d suggest taking a look at GitHub - superfly/fly-autoscaler: A metrics-based autoscaler for Fly.io and tweaking it to support your use case.