Company
Rezolve AI is a London-based publicly traded technology company specializing in generative AI solutions for commerce and retail. Founded in 2016, it provides a proprietary, secure LLM (Brainpowa) designed for conversational, visual, and text-based product discovery, along with instant, one-tap checkout capabilities (Braincommerce, Braincheckout) to drive engagement and revenue for enterprises. As of 2026, the company has secured over $750 million in funding, positioning it among the best-capitalized firms in AI-driven commerce.
Rezolve AI is a global company built in part through acquisition, which means its engineering organization inherited a wide variety of stacks, tooling, and cloud footprints from day one. Rather than standardizing on a single cloud, Rezolve AI made a deliberate architectural bet on Kubernetes as the abstraction layer that could run any workload across any major hyperscaler.
Central to Rezolve AI’s infrastructure model is a demanding design decision: dedicated, multi-regional Kubernetes clusters per client. Every e-commerce customer runs their own cluster or clusters, sized and configured for their specific catalog, traffic patterns, and regional footprint.
The Challenge: Manual Operations Across Hundreds of Clusters Were Unsustainable, and a Vendor Failure Made It a Crisis
The complexity of managing per-client clusters at scale
The operational complexity of Rezolve AI’s multi-cluster model is significant. Each client can run one or more Kubernetes clusters across multiple regions, and traffic distribution across those regions is uneven and unpredictable. E-commerce catalogs vary in size, and the applications that handle them need to be rightsized accordingly.
This creates a compounding problem: not only does each cluster need to be correctly sized and balanced independently, but those decisions cannot be made in isolation from what is happening across all other clusters.
“Depending on the type of workload, depending on the customer, depending on the region, you may have to rightsize and pick your node and then jump to the next cluster and do the exact same thing with another client. And then that client might be having a sale, so you can’t change the nodes all of a sudden. You have to balance it all out.”
Sarim Ali, SRE Manager at Rezolve Ai
Facing Kubernetes limitations
A common misconception the team encountered was that Kubernetes itself handles these concerns natively. It doesn’t. “People think that Kubernetes handles rightsizing for you. Rebalancing is a whole different issue, and bin-packing is a whole separate issue, and these are independent from each other. And when you try to do them regularly, they become toil,” said Sarim.
The SRE team was writing automation scripts to handle rebalancing and bin-packing manually, but the scripts were only reliable enough to run in development environments. “We ran those scripts mostly in development, and we were never able to get them into that production sphere,” he added.
The Reserved Instance trap
On top of node management, Reserved Instance planning was a constant exercise in guesswork. The team was manually calculating which workloads would fit on which Reserved Instance plans, committing to those plans, and then engineering their deployments to conform to what they had purchased rather than what the workload actually needed.
“We had to use only the Reserved Instances plan because we just had to get our workloads to fit on that, as it’s cheaper for us. Otherwise, we’re not using those, and it’s a waste of resources. We were doing a lot of that math and balancing manually.”
Sarim Ali, SRE Manager at Rezolve Ai
Three production outages in three months
With around 100 Kubernetes clusters to manage, the team evaluated open-source solutions but found the rollout overhead alone made them impractical at that scale. They then ran a formal spike across multiple tools, ultimately selecting a Cast AI competitor. That decision had serious consequences.
“We had three production outages within the span of three months, across hundreds of clients. Each time, it was because they made a Terraform change on their end. Their module would no longer pull up their images, or we couldn’t roll out a change anymore because they changed their Terraform module, or they made an API deprecation on their end and wanted us to roll out an update.”
Sarim Ali, SRE Manager at Rezolve Ai
Each failure cascaded across client environments simultaneously. “To go from zero outages for a year to three back-to-back was terrible on its own, but then all of them attributed to a team that you’re relying on for reliability is probably the worst feeling ever,” added Sarim.
The Solution: Automating the Infrastructure Layer So the Engineering Team Could Focus Elsewhere
Finding Cast and starting the rollout
Cast was not entirely new to Sarim Ali, SRE Manager at Rezolve Ai. Before the GroupBy acquisition that brought his team into Rezolve AI, the team has already been running Cast on GCP. When the same operational challenges emerged at Rezolve AI’s scale, the answer was clear. After the experience with a previous vendor, Sarim went looking for a solution: “It was the first time ever where I reached out to a company and told them, ‘I think you’re the best-case scenario for me right now.’”
Onboarding Cast started in lower environments. For every client, Rezolve AI maintains a corresponding lower Kubernetes cluster for development and staging. These had previously been left at zero nodes because the team did not want to write the automation to spin them up and down on demand. Cast’s cluster scaling feature resolved this immediately.
“When Cast came around and said, ‘You have the ability to do that through our platform,’ that was one of the first features we rolled out. We can turn it on when there are requests to it and turn it off when it’s not in use.”
Sarim Ali, SRE Manager at Rezolve Ai
After validating in development and staging environments, the rollout to the first production client followed. The full rollout took approximately six to seven weeks, completed in close collaboration with the Cast support team.
Shifting the engineering effort from the cloud layer to the application layer
Once in production, the team restructured its entire infrastructure management approach. Rather than trying to manually model and maintain the cloud layer, they shifted that responsibility to Cast and redirected their engineering effort toward making their own applications more composable and resilient.
“We spent the engineering effort of figuring out how to get our applications to handle that composability as opposed to trying to do the math of handling the cloud. We left that part to Cast and started optimizing our engine.”
Sarim Ali, SRE Manager at Rezolve Ai
Node tagging, Spot placement, and nightly rebalancing
In practice, this involved several configuration phases. The team audited their applications to determine which could safely run on Spot Instances and which required more stable node types. For workloads that could not tolerate Spot, they used Cast’s node tagging to enforce placement rules, ensuring each workload class landed on the appropriate node type.
“We were able to use the tagging features within Cast. And basically at that point, Cast did what it does best, which is pick a right-sized node and resize workloads.”
Sarim Ali, SRE Manager at Rezolve Ai
Nightly rebalancing jobs replaced manual intervention. When Reserved Instance contracts expired, the team configured Cast with additional options rather than renewing those commitments, allowing Spot Instances to dynamically absorb the workload.
The team then moved from their own horizontal pod autoscaling policies to Cast’s HPA integration. The configuration evolved iteratively, with each layer of automation building on the last.
Extending to ARM and broadening the Spot pool
The team also extended their node pool configuration to support ARM-based instances, prompted by Cast’s recommendation that ARM nodes are less frequently contended in Spot markets. This required updating their CI/CD build pipelines to produce multi-architecture images targeting both x86-64 and ARM, opening up a broader pool of Spot capacity with no change to the application layer.
Sourcing H200 GPU nodes across clouds with OMNI
The most recent development in the team’s Cast usage is Cast OMNI. When Rezolve AI needed H200 GPU nodes in Azure and couldn’t source them directly, they used OMNI to pull nodes from a different cloud provider and present them to their existing Azure Kubernetes clusters as if they were native.
“Being able to get nodes from Oracle Cloud and bringing them into Azure as if they were native without having to rebuild our entire Kubernetes cluster, move resources, and all that, speaks volumes for itself. It was a whole bunch of toil reduced thanks to Cast.”
Sarim Ali, SRE Manager at Rezolve Ai
The team now has a repeatable, tested path for sourcing specialized GPU capacity from cloud providers whenever needed.
The support relationship as a foundation for reliability
Equally important to the technical implementation has been the support relationship. The Cast team worked with Rezolve AI’s SREs throughout the rollout – proactive communication around updates and early access to new features has sustained that relationship.
“Your team has been really instrumental and the reason behind sticking around with Cast, constantly making sure that any updates that are happening, they’re notifying us. And the best is new features: ‘We just launched this crazy feature, and we want you guys to come try it out.’ They’ve just been there for us, and we want to be there for them too.”
Sarim Ali, SRE Manager at Rezolve Ai
The Results: Operational Confidence at Scale With Cost Savings as a Consequence
Eliminating cluster-level toil across hundreds of environments
The manual effort that previously consumed SRE capacity has been eliminated at the cluster level.
“You have hundreds of Kubernetes clusters, and each of them can have different-sized workloads depending on the amount of traffic they’re receiving. If your workloads are larger on one cluster than they are on the other cluster, you need to pick the right size node, find the nodes available within Spot that already have reduced capacity, know which ones are going to be best suited for your workload type, and then write the code associated with that. That’s already there for you in Cast.
And I think that alone is enough toil for me not to want to deal with it. Our company is focusing on e-commerce, not building Kubernetes at scale, and we leave that to the pros.”
Sarim Ali, SRE Manager at Rezolve Ai
Running a smooth multi-cluster architecture
The most significant outcome of Cast’s deployment at Rezolve AI is that the team has been able to sustain and scale its multi-cluster, multi-client architecture without collapsing it into a simpler but less capable model.
“We could have turned around a couple of years ago and said, ‘Hey, look, we ran into too many issues running many different Kubernetes clusters. We can’t maintain this anymore. We gotta go back to one big Kubernetes cluster.’ This is an approach I’ve seen among many companies I’ve worked at in the past. They’re running multiple Kubernetes clusters, each with its own policies and procedures, and they’d have to amalgamate them, which is a horrible experience. But we didn’t have to do that. We were able to accommodate every type of team, every unique requirement, and run their Kubernetes cluster in their own space.”
Sarim Ali, SRE Manager at Rezolve Ai
50% of production nodes running on Spot
Running 50% of production nodes on Spot Instances is perhaps the clearest technical proof of what that operational confidence looks like in practice. Spot Instances are typically avoided in production because managing preemptions at scale without disruption requires robust automation that most teams lack.
“Being able to say that 50% of our nodes in production are running on Spot Instances, that’s almost entirely attributed to the work Cast has done.”
Sarim Ali, SRE Manager at Rezolve Ai
Per-client cost visibility without custom logic
Each client now runs in an isolated Google Cloud project, which means cost attribution is direct and requires no custom logic.
“I just go and jump into their project. I can tell them, ‘Okay, this is what your costs were like last month, and this is what it is this month, and it’s almost entirely because of your XYZ application that was deployed or your usage of Gemini or something.’”
Sarim Ali, SRE Manager at Rezolve Ai
Cost savings as a consequence of automation
Switching from Reserved Instances to managed Spot capacity reduced compute costs by approximately half or more.
The shift to ARM nodes widened the Spot pool further, compounding those savings without requiring application-layer changes.
As Sarim puts it, for any team running Kubernetes at the scale Rezolve AI operates: “Anybody that’s using it at scale can benefit from cost savings, environment optimization, and a great support structure.”
