Autoscaling had spun up three new instances, but each one pulled the wrong branch. Half the fleet was running old code. The fix wasn’t a hot patch, it wasn’t a manual restart—it was a Git reset. On live infrastructure. While metrics tanked.
Autoscaling Git reset isn’t something you think about until it breaks. When it does, you need a clean, automated way to sync every instance, even while new ones spin up. If instances boot with code drift, no amount of orchestration will save you. The only way to get consistency is to build reset logic into the lifecycle of your autoscaling group.
The sequence is simple but unforgiving. On launch, each instance pulls a specific commit hash, not a branch. Then it runs a git reset --hard to guarantee a clean workspace. No leftover temp files. No half-pulled merges. This enforces a single source of truth across the cluster, whether you scale up or down.
Push this deeper into your automation. Use launch templates, user data scripts, or configuration management tools with built-in Git tasks. Always target a static commit hash in your environment config. This eliminates race conditions between deployment pipelines and autoscaling events. A new instance should either start at the exact same commit as the rest—or fail fast so you can see the problem in minutes, not hours.