Minga

How a three-person infrastructure team cut cloud compute costs 30–40% while checking 1.5 million students onto campus in a single morning peak

Minga is the campus management platform K–12 schools use for digital hall passes, tardy management, and rewards for positive behavior (PBIS). It is trusted by over 1,500 schools in 600 districts across 47 states, supporting more than 2.5 million students and seven-figure daily active users. The company has over 100 employees and recently secured a $65M investment from Riverwood Capital to continue its growth trajectory of doubling nearly every year.

Challenge: The Velocity Gap on GKE

Minga’s developers use AI tools daily for application code and ship features faster than ever. Infrastructure couldn’t move at the same pace.

Kubernetes gave Minga a consistent foundation for running its containerized services as the platform grew, but operating that foundation became increasingly difficult for a small team. The challenge was not whether Kubernetes could support Minga’s scale; it was how much Kubernetes and cloud infrastructure expertise the team needed to maintain around it.

Running Kubernetes through Google Kubernetes Engine (GKE) still left Minga’s three-person infrastructure team responsible for coordinating the surrounding configuration required to expose and operate workloads. Load balancing, ingress, TLS certificates, security configuration, scaling, and other dependencies could span multiple services and configuration surfaces. Because infrastructure was only one responsibility for the team, those operational tasks increasingly became a bottleneck as application development accelerated.

For Minga, the next stage of Kubernetes adoption therefore wasn’t about replacing Kubernetes. It was about reducing the amount of Kubernetes operations the team had to perform directly.

Before Control Plane, Minga ran on Google Kubernetes Engine, with container-based Node.js services on the back end, Angular on the front, and MySQL on Cloud SQL. Matt Zytaruk, Minga’s VP of Technology, maintained the cluster with two other engineers while also running the entire engineering department, which made ops a side responsibility. No matter how fast the team shipped code, deploying it and keeping it reliably available on GKE slowed everything down.

The stakes are unusually concrete in K–12. At 8:30am Eastern, Minga checks 1.5 million students onto campus across the Eastern Seaboard. If check-in stops working, 2,500 students end up lined up outside a single high school entrance. Schools abandon the process, and shortly after that, the platform.

GKE is service-oriented, not solution-oriented. Standing up a single workload requires touching many different places: the load balancer, the ingress, the SSL certificate, cert-manager, and the security mounts. The cluster’s actual state drifted from what was committed in Git. Traffic spikes slowed the platform down until capacity caught up. And hiring didn’t help — new developers didn’t even know where to look, and needed months in the GKE world before they could contribute.

“Whenever you want to build something, you have to go to five different places in GCP. If you’re only doing it occasionally, it’s confusing and slow.” — Matt Zytaruk, VP of Tech, Minga

Solution: Building for scale at hypergrowth speed

Minga retained Kubernetes as the orchestration layer for its containerized workloads, but changed how its engineers interact with it. Instead of having the internal team manage Kubernetes clusters and their lifecycle directly, Control Plane provides an abstraction layer over Kubernetes and handles operational responsibilities such as cluster upgrades, kubelet compatibility, and node-pool configuration.

That distinction was important to Minga. The company could continue using Kubernetes as the portable foundation for its applications without requiring every developer—or its small infrastructure team—to become responsible for the complexity of operating Kubernetes itself. Application teams could focus on workloads and configuration, while the underlying platform automated more of the cluster lifecycle.

The result is an evolution in Minga’s Kubernetes adoption: from directly operating Kubernetes infrastructure toward consuming Kubernetes through an internal platform experience designed around developer self-service and automation.

Today Minga runs its workloads on Control Plane, a cloud virtualization platform, in GCP US-West, while connecting to Cloud SQL, Redis, an SFTP server and the rest of its GCP-native services exactly where they were, inside a VPC reached over the platform’s private networking. That mattered for more than convenience: schools send rostering data to the SFTP server, and moving it would have forced every district to change IPs and domains.

Underneath, Control Plane runs on Kubernetes, but Minga doesn’t have to manage Kubernetes directly. The platform handles cluster upgrades, kubelet compatibility, and node-pool surge settings.

AI-Native Cloud for AI-Native Teams

AI-assisted development now extends into the infrastructure layer. Control Plane’s MCP server and CLI are hooked into the SRE workflow, so engineers can diagnose issues and generate the changes they need in the same flow. Because the platform is Terraform-native, the SRE team keeps everything in infrastructure as code. Application engineers self-serve secrets and environment variables for their own workloads.

Smaller things add up too. Copying an entire environment to test a feature, without wrecking QA for the testing team, is one button. Exposing a new workload over SSL is two clicks.

“It’s literally three or four clicks to get a workload running in Control Plane.” — Matt Zytaruk, Minga

Cloud Costs Conforming to the School Day (and Year)

Kubernetes is particularly well suited to Minga’s variable workload profile, but realizing that elasticity depends on how capacity and scaling are configured. Minga’s demand can change dramatically within hours: infrastructure that is largely idle before the school day must rapidly support the morning arrival period, then adjust again as usage changes throughout the day.

Previously, the team compensated for that variability by maintaining excess capacity. Today, its Kubernetes workloads can scale from as few as three pods overnight through 25, 40, 60, and as many as 80 pods as demand increases. That allows compute consumption to follow application demand much more closely while preserving the Kubernetes-based application architecture.

For Minga, Kubernetes elasticity has therefore become both a reliability mechanism and a cost-control mechanism. Instead of choosing between spare capacity and the risk of slower scaling, the team can use automated capacity management to support peak periods while reducing resources when schools are quiet.

Minga’s traffic profile is brutal — quiet at 5am, peaking at 11am, with seasonal swings from 5% of normal in summer to a new annual baseline every August.

On GKE, autoscaling required hand-tuning the team didn’t have time for, so they over-provisioned, keeping a floor of 10 pods overnight. Big spikes still slowed everything down until the cluster caught up.

On Control Plane, Minga scales aggressively — through 25, 40, 60, and 80 pods as load comes in, dropping to just 3 overnight. The ramp is fast enough that no one notices. Automated capacity tuning means the team isn’t trading availability or performance for the discount. Day-to-day operations are now largely a matter of checking dashboards.

Choosing the Right Cloud for the Job

Some products Minga plans to build would benefit from AWS-only services. The next phase of growth includes migrating performance-sensitive workloads from GCP to AWS while keeping the rest in place — a project that would have been a non-starter on traditional infrastructure. In Matt’s words, the scale of it would have scared them off.

Cloud virtualization changes that. Workloads run in GCP and AWS at the same time and talk to each other through the platform’s networking, so Minga can separate its cloud provider from its platform and choose the best underlying service without porting the product back and forth. As Minga expands into new geographies, the operational lift is “basically already done for us.”

“When we initially migrated to Control Plane, our cost savings were probably 30 to 40%. Possibly even more.” — Matt Zytaruk, Minga

Impact

The biggest change is not simply that Minga runs Kubernetes differently. It is that the company can support a rapidly growing Kubernetes estate without building a correspondingly large infrastructure organization.

Minga’s three-person infrastructure team can support workloads serving more than 2.5 million students while spending less time on cluster lifecycle management and routine infrastructure configuration. Application engineers can self-serve common workload requirements, while infrastructure remains defined as code and the platform handles more of the underlying Kubernetes operations.

That operational model has helped Minga reduce cloud compute costs by an estimated 30–40% following the migration while accommodating its highly variable demand. During quiet periods, workloads can scale down significantly; when the school day begins, Kubernetes provides the orchestration foundation for scaling application capacity back up.

For Minga, the value of Kubernetes is increasingly not in how much of it developers have to manage, but in the standardized, portable application foundation it provides underneath the platform.

Minga needs infrastructure its customers can’t break, even as usage swings wildly across the day and the season. Schools now see fewer slowdowns and higher availability than before, and Minga can keep growing without worrying about whether the platform underneath will keep up.

The next chapter is multi-cloud, multi-region, more workloads, and new products. The team can take those on as projects worth doing rather than risks that get deferred, and every dollar saved on infrastructure goes back into building features for schools.

Future plans

Minga’s next phase could extend that Kubernetes operating model across cloud providers. The company expects some future workloads to benefit from AWS-specific services while other applications and data services remain in Google Cloud.

Because its applications already run as containerized workloads on Kubernetes, Minga can approach that expansion without redesigning its entire application platform for each cloud. The goal is to maintain a consistent workload model while allowing teams to choose underlying cloud services according to performance, geographic, or product requirements.

That portability changes how Minga thinks about multi-cloud architecture. Rather than treating a move between cloud providers as a full platform migration, the team is working toward an environment in which Kubernetes provides a common orchestration foundation and the infrastructure layer abstracts more of the differences between providers.

As Minga expands into new regions and builds new products, that common Kubernetes foundation could allow the company to increase infrastructure reach without increasing operational complexity at the same rate.