Autoscaling is not triggered on a pure websocket application

Ah, I think I understand what you are looking for now (instances to scale up in the specific region where soft limit has been reached). Indeed, the existing documentation did describe this kind of region-aware behavior:

  • Standard: Instances of the application, up to the minimum count, are evenly distributed among the regions in the pool. They are not relocated in response to traffic. New instances are added where there is demand, up to the maximum count.

I dug into this recently, and found that our current (nomad-based) autoscaler implementation was deployed around Sept 2021, but this documentation was originally written for an earlier system that had somewhat different behavior. Most notably, there’s only one ‘mode’ in the current autoscaling system (and I believe the scaling action is a simple adjustment of the total instance count), so setting ‘balanced’ mode no longer has any effect.

Apologies for the confusion our quite out-of-date documentation has caused on this. I’ve prepared some updates to the documentation and flyctl that should clarify the current behavior a bit better moving forward.

That said, it does look like the current autoscaler is not quite capable of what you’re looking for. Our current efforts have been focused on adding features to Machines to help manage more advanced scaling requirements like this. Autoscaling apps on machines isn’t quite ready yet, but it’s something we’re actively working on and should eventually be able to better handle your use-case.

1 Like