Thanks, checking it out right now.
It would be nice to have MDG input on this.
I currently run my Meteor application on Galaxy. I recently had a situation where I had huge swings in user load (10 users increased to several hundred in a matter of minutes). This went on for a few days. Having to manually scale up and down the number of containers was less than ideal. I either had complaints that the app was running slowly (or not able to load due to maxed out CPUs), or I had to increase my container count to something that would be way too much to pay on a monthly basis for my needs. I love how easy it is to deploy to Galaxy and all of the current features. But not having autoscaling is cost prohibitive for my business and I’m seriously looking into switching to AWS EC2 just to have this feature. +1 for autoscaling. Please and thank you!
3 Likes
In the last Transmission video (is this the name?) they said they may have the future somewhat ready, and that auto scaling is hard.
So it would be really good for them to jump in the discussion with their input.
With this, now it looks like autoscaling can be more of a built in service. https://aws.amazon.com/blogs/aws/aws-auto-scaling-unified-scaling-for-your-cloud-applications/
This is what Galaxy support told me:
“I’m afraid I can’t share an ETA for when you might be able to schedule servos to start/stop, or auto-scale based on load. This isn’t in our roadmap, and while I understand this would be useful in your situation, we haven’t committed to implementing this feature.”
My guess is not supporting autoscaling is an economic decision.
Autoscaling saving you money === Galaxy losing money
2 Likes
Whoops, responded to wrong comment.
Where’s my downvote button 
Yes. But we are having problems deploying it with it. We’ve opened an issue.