If you’re running WebSocket servers with autostop on Fly.io, we’ve got a quality-of-life improvement for you.
fly-proxy will now send a WebSocket GoAway close frame to all open WebSocket connections before a Machine is stopped or suspended. This gives clients a signal to reconnect elsewhere rather than being left hanging.
Before this change, auto-suspending a Machine with active WebSocket connections wasn’t a nice experience: connections didn’t receive any close signal, so clients had no idea anything had happened. From their perspective the connection just hung, until the failing TCP keep-alives eventually caused the connection to be torn down.
For apps with auto_stop_machines=stop configuration the situation was already more manageable. Because the app received SIGTERM before being killed, it could catch that signal and close its connections gracefully itself. And even if the app didn’t handle SIGTERM, the kernel running in the Machine would’ve quickly terminated TCP connections anyway.
Normal HTTP requests were largely unaffected because of how the proxy handles the shutdown sequence: when a stop or suspend is triggered, fly-proxy soft-cordons the Machine first and then waits a brief period before actually issuing the stop/suspend command. By that point, any in-flight short-lived HTTP requests have likely already completed.
Now auto_stop_machines=suspend should work much better with WebSocket apps, allowing more apps to benefit from automatic scaling and fast Machine suspend/resume operations.