Show HN: SpotVortex helps SRE teams push more Kubernetes capacity onto Spot
github.comI built SpotVortex for a simple reason: most teams want more Spot savings, but they do not want to compromise service safety to get them.
SpotVortex runs inside the cluster and controls Spot at the node-pool level. It watches market risk and pool health, then decides when a pool should grow, spot, hold, freeze, or move back toward On-Demand.
A few concrete details about the shipped runtime:
* The deterministic mode is the active path * The control cadence is 10 minutes * Decisions stay at the node-pool level, not the pod level * Workload data stays in-cluster.
The controller also looks at pool blast radius, not just price. It tracks things like:
* PDB Slack under node loss * How much critical workload is sitting on the Spot restart and recovery time * Stateful workload mix * zone spread * evictability * available On-Demand headroom * Current AWS support is explicit. The shipped model scope covers 60 instance families across:
compute: c5, c6, c7 general purpose: m5, m6, m7 memory optimized: r5, r6, r7 burstable: t2, t3, t4g
Happy to answer hard questions. We kept decisions at the node-pool level and focused on operational safety signals like PDB slack, critical workload concentration, restart time, evictability, zone spread, and On-Demand headroom. If you want to push on safety, failure modes, rollout, or supported AWS scope, those are the right questions.