Which Galaxy auto-scaling threshold balances instance savings against per-scale-event charges for a steady low-traffic Meteor workload?

A low-traffic Meteor deployment on Galaxy leverages auto-scaling to adjust Node.js instance count based on real-time CPU and memory metrics. The precise goal is to identify an auto-scaling configuration that minimizes monthly cost while avoiding excessive scale-events that incur per-instance-hour or per-scale-event charges. A key uncertainty is how the scaling thresholds respond when traffic remains consistently below the typical wake-up rate: whether the system maintains a single lightweight instance, oscillates between states, or delays scale-down due to minimum uptime windows. Additionally, the trade-off between Galaxy's managed service convenience and the potential savings from a self-contained production build on a more affordable hosting platform remains unresolved for workloads with predictable off-peak patterns.

Does the auto-scaler enforce a minimum instance uptime before considering scale-down, and how does that affect cost for steady low traffic? How do per-scale-event fees compare to sustained instance-hour charges under these conditions? What is the effective cost floor for a single-instance Galaxy deployment when traffic never exceeds the scaling-up threshold?