# How Aunalytics built infrastructure for AI-ready data | Spectro Cloud > Source: > Published: 2026-11-09 08:00:00+00:00 # How Aunalytics built the infrastructure behind AI-ready data ## Building data and AI services for community banks At [Aunalytics](https://www.aunalytics.com/), we give midsize organizations the same advantage from their data that large enterprises rely on. Many of our clients are financial institutions, including [community banks](https://www.aunalytics.com/industry/community-banks/) and [credit unions](https://www.aunalytics.com/industry/credit-unions/). A community bank holds *years* of relationship and transaction history on the customers it serves. What it rarely has is the engineering bench of a national bank or a fintech to put that history to work. We close that gap. Clients rely on us across the stack: managed IT, managed security, enterprise cloud hosting, and backup and disaster recovery. At the top sits the [Intelligent Data Warehouse](https://www.aunalytics.com/intelligent-data-warehouse/), which makes their data AI-ready, and [Auna](https://www.aunalytics.com/auna/), our AI agent for financial institutions, which turns that data into deposit growth and stronger customer and member relationships. All of it runs on an *analytics cloud* we operate end to end, in data centers we own, under PCI DSS and GLBA. We hold data usability to the same standard a traditional cloud provider holds compute, with an uptime and availability commitment attached. In May 2026 we published a piece on [the AI compute constraint](https://www.aunalytics.com/the-ai-compute-constraint-and-the-case-for-an-intelligence-layer/). Compute is now physically constrained and per-token costs are volatile, so a regulated institution should route each task to the tier of intelligence that fits it. That means a frontier model where the task justifies the cost, and a specialized model, classical machine learning or a deterministic rule everywhere else. We call that architecture an *intelligence layer*. My team runs the infrastructure underneath that intelligence layer. Every task routed away from a frontier API still runs somewhere. It runs on a server in one of our data centers, in a cluster our team provisions, patches, isolates from the client next door and documents for an auditor. For the past year, Spectro Cloud's Palette has managed those clusters in our analytics cloud. Palette is now one of the foundations of Platform 3.0, the next generation of our Aunsight platform. ## Hand-built clusters and hand-checked isolation For years we managed our bare-metal clusters with Rancher, and it met our needs at a smaller scale. As our estate grew, we started hitting limits. Provisioning new capacity involved manual work against [MAAS](https://canonical.com/maas) (Metal as a Service). Scaling our Cluster API deployments was slow. Isolation between client environments is a hard requirement when separate institutions share physical infrastructure. Ours depended on configuration our engineers checked by hand. A growing share of engineering time was going into cluster plumbing rather than the platform our clients pay for. We had also invested in NVIDIA H100 GPUs and needed to bring them under the same management model. ## Four requirements and a deadline Our Rancher contract came up for renewal in July 2025. That set our deadline. We looked at staying with Rancher, or moving to OpenShift, OpenStack, or VMware Tanzu. We evaluated alternatives against four requirements: - First-class [Cluster API](https://www.spectrocloud.com/blog/cluster-api-and-kubernetes-cluster-management) and MAAS support for bare metal - Multi-tenant isolation strong enough to satisfy an examiner - A [self-hosted](https://www.spectrocloud.com/platform/deployment-options) control plane, because our compliance posture rules out a management plane hosted by a third party - One platform for both our CPU and H100 GPU infrastructure. We chose Spectro Cloud's Palette, self-hosted in our environment and backed by Spectro Cloud's [Pro technical support](https://www.spectrocloud.com/platform/service-and-support). Two capabilities decided it for us. First, full-stack profiles let us manage the OS together with Kubernetes and its add-ons as one versioned unit. Second, it runs the same way on our own hardware as it does anywhere else, which matters when your clients expect their data in a facility you control. My advice to a peer is to test day-two operations as part of the evaluation. Run an upgrade across several clusters and rebuild a failed node. Unplug a host and watch what an ungraceful disappearance looks like. Onboard a new tenant, then measure how many people and hours each task takes. These real-world management events show where the platforms differ. ## Repeatable clusters and isolated client environments We now define the OS, Kubernetes distribution, networking, storage and add-ons in versioned Palette cluster profiles. MAAS handles bare-metal provisioning, automated end to end. Palette's tenant and project hierarchy, with virtual clusters inside it, maps directly onto the isolation model we had already defined on paper. Clients that require full separation get it. Within shared infrastructure, we apply lighter-weight separation where it fits. Palette’s [virtual clusters](https://www.spectrocloud.com/platform/virtual-clusters), built on vcluster technology, are central to how we isolate client environments. Each environment gets what behaves like its own Kubernetes cluster, with its own API server and role-based access control (RBAC), while running on shared bare metal. Each one also has an independent lifecycle. A dedicated physical cluster for every client environment would waste a great deal of hardware at our density. With virtual clusters, we stand up an isolated production or development environment in minutes and keep it separated to a standard we can document for an examiner. When the environment is no longer needed, we reclaim the capacity. We also made a deliberate choice about how Aunsight connects to the clusters Palette manages. Applications deploy through a narrowly scoped service account. Platform engineering owns the cluster lifecycle, the application team owns deployment, and neither has access beyond its remit. ## A year in: faster provisioning, fewer incidents We started with three clusters and 15 nodes under Palette. Today we run 6 clusters, 30 nodes and 40+ virtual clusters. Three engineers run the whole platform. Our node and cluster count has grown about 2x, but the team running it hasn’t had to grow at the same rate, and that’s the number I care about most. We set a goal of cutting manual configuration time by more than half, and we beat it. A new client environment used to take around two days of hands-on build work. Now it takes under an hour from a profile we’ve already tested. Kubernetes upgrades used to be planned weekend events. Now we roll them through clusters in two-hour windows with no client-facing downtime. Configuration drift used to drive a lot of our deployment and runtime incidents, and we’ve seen 90%+ fewer of those, because every cluster is built from the same declared profile instead of being hand-tuned. We can give new clients a firm onboarding date and hit it, because a new institution’s environment is built from a profile we’ve already run many times. Isolation is designed in from the start. Each client’s workloads run in dedicated virtual clusters with their own policies, so we can show an examiner exactly where that institution’s data lives and what can reach it. Audit evidence has improved too. Because every environment is defined as versioned configuration, we can show what was running, when it changed and who approved it, without someone rebuilding that history from tickets. A year ago that took manual work for every exam cycle. Under PCI DSS and GLBA, reproducibility is also a compliance requirement in its own right, and it shortens audits. When every cluster is built from the same declared profile, most of the evidence we need already exists. ## Platform 3.0: bringing VMs into the cattle model With Platform 3.0, our goal for the platform is clear. We want as much of our infrastructure and workloads as possible to run as cattle, not pets. When we need to scale, we should be able to add another replica. When a cluster has a problem, we should be able to tear it down and replace it with an identical copy from the same source definition. That's the cloud-native, infrastructure-as-code approach, and Palette delivers it for Kubernetes. Virtual machines have historically been managed differently, and like many organizations, we still run an extensive VM estate. Our next chapter brings as many of those VMs as possible into the cloud-native model. VMware will remain part of our environment for years, along with a substantial virtualized estate. Our goal is one operating model. VMs should be defined declaratively and scheduled alongside containerized workloads, and when something goes wrong, we rebuild them from a known definition. They should run under the same profiles, isolation controls, audit trail and team as our Kubernetes estate. To get there, we launched a phased initiative with Spectro Cloud, built on Palette's KubeVirt-based [Virtual Machine Orchestrator (VMO)](https://www.spectrocloud.com/fleet-orchestration/vms-on-kubernetes). Over the past several months we laid the foundation: discovery across the VM estate, architecture validation, networking design and a migration plan organized in waves. Each wave has defined workloads, validation criteria, operational runbooks and a production rollout strategy. We expect to bring about 90% of our VM estate under Virtual Machine Orchestrator over the next 6 months. We’ll start with stateless workers and applications suited to volatile infrastructure. Over time, we’ll move existing stateful services and hosts to a volatile-first strategy. Some VMs will stay where they are on VMware for licensing or vendor-support reasons, and we’re fine with that. The goal is one operating model for most workloads, not 100% for its own sake, in addition to vendor lock and license cost elimination on the Broadcom/VMware relationship. ## Running AI workloads on GPUs we own Our [intelligence-layer model](https://www.aunalytics.com/the-ai-compute-constraint-and-the-case-for-an-intelligence-layer/) only works if the specialized and classical tiers are economical to operate. Frontier API pricing is variable and set by someone else. A right-sized model on hardware we own is a fixed cost we can plan around and defend in our regular budget reviews. We've invested heavily in servers with high-end NVIDIA GPUs. Those are expensive assets, and we need them fully utilized and integrated into our overall cloud management model. One capability that drew us to Spectro Cloud was the [native ability](https://www.spectrocloud.com/ai/ai-as-a-service) to schedule and manage GPUs, including the full enabling software stack from NVIDIA and the open-source community. Our GPU clusters now run under the same profiles and tenancy as the rest of the estate, which gives us the control to schedule them for maximum utilization. Today the GPU nodes run our self-hosted language models behind a gateway that handles routing, failover and usage tracking. Those models power our agentic product line in addition to our internal development and deployment workloads originating within our engineering teams. Routine, high-volume banking work, like classifying documents or transaction summaries, summarizing member interactions and answering repeat questions, runs all day, every day, and at volumes that require us to balance owned hardware and cloud-hosted LLM services which allows us to choose when and where our costs OR timelines expand. Just as important for our clients, we get to choose that sensitive financial data never leaves infrastructure we control. We still use hosted frontier models where they’re clearly better and the data allows it. ## Ready for what comes next Our clients trust us to run their infrastructure securely and in compliance, and to give them the innovation they need to grow in an AI-driven market. That requires platform infrastructure managed on modern principles, with automation driving consistency and speed. Spectro Cloud's Palette was the best way for us to get there. It puts us in control of our clusters and what runs on them, and its virtual clusters give us smart isolation in a multi-tenant environment. Palette lets a small team run infrastructure with the discipline of a large one, and that’s what lets us bring enterprise-grade AI to community banks and credit unions. Our destination is clear. Platform 3.0 is the version of Aunalytics where intelligence is routed to the tier that fits the task, and every layer of infrastructure underneath can be recomposed as client needs change. We're proud to have Spectro Cloud with us on that path. ## Next steps Learn more about Aunalytics and its technology-powered approach to supporting banks and credit unions [here](https://www.aunalytics.com/company/). You can follow Aunalytics on LinkedIn [here](https://www.linkedin.com/company/aunalytics/).