CAST AI vs ZopNight: Kubernetes Autopilot or Estate-Wide Control
If your bill is mostly Kubernetes nodes, CAST AI goes deeper there. If Kubernetes is one part of a mixed estate, ZopNight covers more of it.
What CAST AI does
CAST AI is Kubernetes automation. Its homepage (cast.ai) describes “rightsizing pods, scaling nodes, optimizing GPUs and Spot” with “zero changes to your EKS, AKS, GKE or on-prem cluster”. OpenShift on AWS is also listed.
It also covers the scheduled-environment use case that an earlier version of this page said it lacked. Cluster hibernation means “scaling your cluster to zero nodes while preserving the control plane”. It supports “manual hibernation and scheduled automation”: schedules carry a time zone and are assigned to clusters (hibernation docs, updated 18 September 2026).
Pricing is by conversation: “we’ll need to get in touch to give accurate pricing information” (cast.ai/pricing).
Cluster-level versus namespace-level off-hours
Both tools can put Kubernetes to sleep, but at different grains. CAST AI hibernates a cluster: nodes go to zero and the control plane stays. While the cluster runs, its autoscaler and rightsizing keep node count and pod requests tight, which is where CAST AI’s depth lies.
ZopNight can stop a whole cluster: EKS, GKE and AKS are all on its start/stop list, including GKE and EKS node pools. It can also stop a single namespace. Deployments and StatefulSets in that namespace scale to zero and CronJobs are suspended. HPAs and PDBs are removed on stop and restored on start, so an autoscaler does not immediately undo the stop. System namespaces such as kube-* and istio-* are always skipped. That lets you turn off one team’s preview environment inside a shared cluster while the rest stays up. See namespace versus cluster scheduling for the trade-offs.
Outside Kubernetes, ZopNight schedules VMs, managed databases and data platforms. It also raises Kubernetes workload recommendations for reliability and security, such as missing requests and limits, single-replica deployments and privileged containers, alongside cost.
| Capability | ZopNight | CAST AI |
|---|---|---|
| Kubernetes platforms | EKS, GKE, AKS | EKS, AKS, GKE, on-prem, OpenShift on AWS |
| Off-hours for Kubernetes | Cluster, node pool or namespace schedules | Scheduled cluster hibernation to zero nodes |
| Live node autoscaling and pod rightsizing | Recommendations; autoscaler policies for ASG, VMSS, MIG, ECS | Automated, core product |
| Non-Kubernetes resources | VMs, RDS, Cloud SQL, Databricks, Snowflake and more | Not the product focus |
| Pricing | See zop.dev/pricing | Custom quote |
Choose CAST AI if…
- Kubernetes node spend dominates your bill, and you want pods rightsized and nodes packed automatically, all day.
- You run GPU workloads or heavy spot usage in Kubernetes.
- You run on-prem or OpenShift clusters alongside managed Kubernetes.
Choose ZopNight if…
- You need to switch off individual namespaces inside shared clusters, not whole clusters.
- Your off-hours waste also sits in VMs, databases and Databricks clusters, and you want one schedule and override model across all of them.
- You want Kubernetes cost inside the same showback, budgets and anomaly views as the rest of your cloud.
Questions we get a lot.
If yours isn't here, email us and we'll answer directly.
Can CAST AI shut down clusters on a schedule?
Yes. As of 24 September 2026 CAST AI documents cluster hibernation, which scales a cluster to zero nodes while keeping the control plane, with manual and scheduled modes.
What does ZopNight do to HPAs when it stops a namespace?
It removes HorizontalPodAutoscalers and PodDisruptionBudgets on stop, together with the prior replica counts, and restores them on start. Otherwise an HPA would scale the workload straight back up, and a PDB could block the scale-down.
Can the two run on the same cluster?
They do different jobs, so they can. Be careful to give each namespace or cluster one owner for off-hours decisions, so two schedulers are not fighting over the same resources.