Does Cast AI Lock You In? Node Provisioning, GitOps and What Happens If You Leave

Key takeaways

• Technical lock-in: LOW. Cast AI provisions standard cloud VMs in your own account using standard cloud APIs. Your infrastructure is not proprietary.
• Operational lock-in: MODERATE. If you leave, you rebuild the rightsizing and node-provisioning process your team stopped doing manually. This is the same risk as switching from Karpenter.
• The cluster keeps running. By default, nodes Cast AI provisioned remain live after uninstall. Applications are unaffected at the moment of removal.
• Your manifests are never touched. Cast AI adjusts resource requests at admission time via a mutating webhook. Git, Helm charts, and application code are unchanged throughout.
• Exit is documented and reversible. A four-step process disconnects Cast AI cleanly. The path back to Karpenter or Cluster Autoscaler is supported and described step by step.

What “lock-in” actually means, and which kind applies here

Data lock-in, infrastructure lock-in, operational lock-in: three different questions

These three categories behave differently. Treat them separately rather than lumping them together under the same concern.

Data lock-in means your data only works inside the vendor’s platform. Cast AI collects cluster metrics and cost analytics. None of that data controls your workloads or becomes a dependency for cluster operability.
Risk level: LOW.

Infrastructure lock-in means the vendor controls your compute layer in a proprietary way. Cast AI provisions standard EC2, GCE, or Azure VMs directly into your cloud account. The nodes run on your account and follow standard cloud APIs.
Risk level: LOW.

Operational lock-in means your team depends on the vendor’s tooling to perform a function, and removing it requires rebuilding a process. This is where Cast AI creates real dependency.
Risk level: MODERATE, on par with switching autoscalers.

Which one applies to a Kubernetes automation layer

An automation layer sits between your orchestrator and your cloud provider. It makes decisions your team used to make manually. When you remove it, those decisions do not make themselves. That is the operational dependency.

Importantly, this pattern is not unique to Cast AI. Removing Karpenter or Cluster Autoscaler creates the same gap. Any tool that automates a previously manual process creates operational dependency by design. The question worth asking is not whether dependency exists, but how difficult the exit actually is. That is what the rest of this post covers.

What Cast AI changes in your cluster

The read-only phase: analysis before anything is provisioned

When you first connect a cluster, Cast AI runs in read-only mode. The agent collects metrics: node utilization, pod resource requests, actual consumption, and spot interruption history. It changes nothing. You can read the full technical breakdown of what the agent accesses in Cast AI’s documentation on how the read-only agent works and what data it can read.

Exit at this stage requires three commands:

kubectl delete namespace castai-agent
kubectl delete clusterrole castai-agent
kubectl delete clusterrolebinding castai-agent

That is the complete cleanup for the read-only phase. No IAM changes, no webhook removal, nothing else.

What the agent creates when automation is enabled: nodes, node configurations, policies

Enabling automation deploys additional components into the cluster: Cluster Controller, Spot Handler, Workload Autoscaler, Pod Mutator, CLM Controller, and Evictor. These run inside your cluster and interact with your cloud account via a scoped IAM role.

At the cloud layer, Cast AI provisions individual nodes directly via the cloud API, similar to how Karpenter works. It creates Node Templates as CRDs in your cluster, manages autoscaler policies, modifies pod CPU/memory requests via a mutating webhook (not by editing your manifests), and creates webhook configurations.

What it never touches: your manifests, your images, your application code

Cast AI does not modify:

• Kubernetes manifests stored in Git
• Helm chart values or templates
• Container images
• CI/CD pipeline definitions
• Services, Ingress resources, ConfigMaps, or Secrets
• Application code

The mutating webhook intercepts pod admission to adjust resource requests at runtime. Your Git repository stays unchanged. If you export your manifests after six months of Cast AI running, they look identical to how they looked on day one.

Does it work with GitOps?

Where automated node provisioning and declarative infrastructure meet, and where they conflict

Cast AI components deploy via Helm, so ArgoCD or Flux can track them like any other release. ArgoCD Rollouts are supported. One practical note: set test.enabled=false to work around Helm test hook behavior that causes ArgoCD sync issues.

Node provisioning works the way Karpenter does: the platform makes placement decisions dynamically, based on real-time pricing and availability. This is “GitOps-adjacent” rather than fully declarative. You define policies; the platform decides which node type to provision at that moment. The specific instance selection is not committed to Git, because it depends on conditions that change minute to minute.

If that is a problem for your compliance requirements, it is the same problem you have with Karpenter. The category is not unique to Cast AI.

Keeping policy in Git while the platform decides placement

For teams that want full IaC coverage, Cast AI offers a Terraform provider. You can define node templates, autoscaler policies, and cluster settings in Terraform and manage them through your standard workflow. Running terraform destroy cleanly removes Cast AI configuration.

The pattern that works well in practice: manage Cast AI policies in Terraform or via Helm values in Git, and let the platform handle instance-level placement decisions. This mirrors how most teams already use Karpenter. The policy is declarative; the runtime decision is dynamic. Both things are true at the same time, and that is fine.

What happens if you uninstall Cast AI

The cluster keeps running: what remains and for how long

By default, deleteProvisionedNodes=false. Nodes Cast AI provisioned remain in the cluster when you disconnect. Applications keep running without interruption. There is no service disruption at the moment of uninstall.

Those nodes will eventually be replaced by whichever autoscaler you re-enable. Until that happens, they stay live. The transition is gradual rather than a cutover event.

Reverting to Cluster Autoscaler or Karpenter

The revert sequence depends on your target autoscaler. For Cluster Autoscaler, there is one structural difference worth knowing: CA requires node groups (ASGs, MIGs, or VMSSs), and Cast AI provisions nodes without them. You need to recreate node groups before CA can take over node lifecycle management.

For Karpenter Enterprise, Cast AI’s own documentation states: “No vendor lock-in. Your Karpenter configuration remains portable.” Note that the Cast AI Autoscaler and Karpenter are mutually exclusive. Running both simultaneously is not supported, so the transition is a clean swap rather than a parallel run.

A checklist for a clean exit

Full automation uninstall, in order:

1. Disable all policies (toggle Autoscaler OFF in the Cast AI console)
2. Run castctl cluster disconnect
3. Run the offboarding script from the console (cleans IAM roles from your cloud account)
4. Clean up cluster resources:
   kubectl delete namespace castai-agent castai-omni
   Then remove webhook configurations, Cast AI CRDs, and ClusterRoles

After step four, the Cast AI footprint is gone. Your cluster continues running with whatever autoscaler you re-enabled in step one.

What you would actually have to rebuild

The honest answer: the manual rightsizing and instance-selection process you stopped doing

If Cast AI has been running for six months, your team has stopped doing manual rightsizing. No one audits CPU and memory requests across namespaces, selects instance families for spot workloads, or adjusts bin-packing parameters week to week. Cast AI automated all of that.

Remove it and those decisions return. The infrastructure still runs, but the optimization work comes back to your backlog. That is the real cost of switching, and it is worth being honest about it during evaluation.

Why this is true of any automation layer, and how to keep the knowledge

This is not a Cast AI-specific risk. Removing KEDA means rebuilding event-driven scaling logic. Removing Karpenter means rebuilding node provisioning policies and instance selection criteria. Every automation layer creates operational dependency when it replaces a manual process.

The mitigation is straightforward: document what Cast AI is optimizing while it is running. Export node template configurations before you disconnect. Keep records of which instance types and regions it selected consistently, and the reasons it selected them. That knowledge is reproducible. You just need to ensure it gets written down rather than left inside the platform.

How Cast AI compares to the alternatives on reversibility

Comparison table across cloud-native autoscalers and commercial platforms

Cast AI and Spot.io/Ocean sit at similar revert complexity. Both modify IAM and require a replacement autoscaler after removal. The difference is that Cast AI’s exit process is documented step-by-step, and the proprietary config (Node Templates) maps reasonably well to Karpenter NodePools if that is the direction you are moving.

The security and compliance position

Read-only agent, SOC 2 Type II, ISO 27001, CNCF membership

In Phase 1, the agent is genuinely read-only. It reads cluster state and metrics. It writes nothing. Phase 2 grants write access to your cloud account via an IAM role scoped to the specific actions required: launching and terminating instances, describing instance types, and interacting with Auto Scaling groups. The role does not carry broad account permissions.

Cast AI holds SOC 2 Type II and ISO 27001 certifications and is a CNCF member. For compliance-heavy environments, the certifications cover the agent’s data handling scope. The CNCF membership signals a commitment to the open-source ecosystem rather than a closed-platform strategy, which is relevant context for lock-in discussions.

If your security review focuses on what the agent actually reads and writes, the linked documentation above covers the read-only phase in detail. The IAM policy for the automation phase is also documented in Cast AI’s onboarding flow and is customer-controlled.

Conclusion

Lock-in is the right question to ask before adopting any automation layer. The honest answer for Cast AI: technical lock-in is low, and operational lock-in is moderate, which is the same score you would give Karpenter or any autoscaler that takes over node provisioning. For context on general cloud vendor lock-in patterns across infrastructure categories, that framing helps put the Kubernetes-specific question in perspective.

The 2026 Cast AI State of Kubernetes Optimization Report found that average CPU utilization across monitored clusters sits at 8%. Addressing that kind of underutilization is ultimately what Cast AI automates. If you leave, your cluster does not stop working. You are simply back to solving that problem manually, without the tooling. The Kubernetes cost optimization problem does not go away when you uninstall the tool.

The read-only phase is a genuine zero-risk evaluation entry point. Three kubectl commands return you to where you started. For teams ready to understand what production deployment costs, Cast AI’s pricing page has the details.

Frequently Asked Questions