You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello, I'm using imgproxy on Fly.io. Right now, I'm using Fly's standard application platform which keeps servers running 24/7. I'd like to take advantage of Fly's Machines API which boots up full VMs on demand. It would be great to see some sort of application timeout setting which sends SIGTERM to exit the application after the specified time – the SIGTERM will also cause Fly to automatically suspend the machine into a state where the user only pays for image storage and not CPU/RAM.
The text was updated successfully, but these errors were encountered:
Hey @bwhli!
It doesn't look like this should be implemented on the imgproxy's level. Also, I can't find anything about SIGTERM handling in the blog post you've shared
So here’s how we modeled this: when you use Fly.io machines to run apps that need to scale down, make your process exit when it’s idle. That’s it. You’ve exited the container, effectively stopping the machine, but it’s intact to pick up a future start request from a clean slate.
This works because your in-machine process has a strongly-consistent view of local activity and can confidently detect “idle”.
Hello, I'm using imgproxy on Fly.io. Right now, I'm using Fly's standard application platform which keeps servers running 24/7. I'd like to take advantage of Fly's Machines API which boots up full VMs on demand. It would be great to see some sort of application timeout setting which sends SIGTERM to exit the application after the specified time – the SIGTERM will also cause Fly to automatically suspend the machine into a state where the user only pays for image storage and not CPU/RAM.
The text was updated successfully, but these errors were encountered: