How CloudRaft Helped Enkrypt AI Ship Its AI Security Platform Into Customer VPCs, OpenShift, and Air-Gapped Data Centers

Enkrypt AI sells AI security to enterprises that will not send their models, prompts, or data to someone else's cloud. So the product has to run where the customer runs: inside an AWS VPC, on AKS or GKE, on an on-premise OpenShift cluster, or as an air-gapped Kubernetes deployment in a data center with no internet connection at all.

CloudRaft has worked with Enkrypt AI since late 2024. We engineered a cloud-native platform and operationalized it to serve both Enkrypt's SaaS offering and its customer-hosted deployments. This case study covers one part of that work that every enterprise software vendor eventually hits: cloud-native software distribution — getting the same release packaged, licensed, and installed in each customer environment, including the ones with no internet access.

In August 2026, Anaconda acquired Enkrypt AI. We are proud to have contributed to that journey.

About the client

Enkrypt AI provides an AI security and safety layer for enterprises. It scans models, tools, and MCP servers for vulnerabilities, runs pre-deployment red-teaming across hundreds of attack categories, adds runtime guardrails that block jailbreaks and sensitive-data leakage, and automates compliance with frameworks such as the NIST AI Risk Management Framework and the EU AI Act.

All of it can run inside the customer's own environment. Enkrypt's customers include Fortune 500 enterprises in regulated industries, where data sovereignty, security, and compliance requirements mean the platform has to be deployed on infrastructure the customer controls rather than consumed as public SaaS.

Business impact

• The same Helm chart and release process now ships to customer VPCs on AWS, Azure Kubernetes Service, Google Kubernetes Engine, on-premise Red Hat OpenShift, and air-gapped data centers.
• Average install time went from 2 to 3 days to under 2 hours. Air-gapped installs went from 3 to 5 days to 4 to 6 hours.
• Preflight checks catch a missing StorageClass, an unsupported Kubernetes version, or an undersized cluster before anything is deployed.
• Customers no longer receive shared registry credentials. Image access is tied to each customer's license.
• Internal, Beta, and Stable release channels let Enkrypt stage a version to some customers before others.
• Enkrypt can see which version each connected customer runs.

The challenge

Enkrypt started with the distribution model most software startups begin with: Helm charts published on GitHub, and container registry credentials shared with each customer by hand. That holds up while the customer list is short. As Enkrypt's enterprise customer base grew, every release became a coordination exercise: send updated images to each customer, coordinate image mirroring for air-gapped sites, debug image pull failures, and track by hand who had installed what.

The customer environments made it harder. Enkrypt's customers deploy on AWS VPCs, Azure, Google Cloud (GKE), on-premise OpenShift clusters, and fully air-gapped data centers. Any fix had to work in all of them.

The same problems kept coming back:

• Prerequisites surfaced only at install time. Customers found a missing StorageClass, an incompatible Kubernetes version, or insufficient CPU and memory after an installation had already failed, which started long troubleshooting cycles.
• Air-gapped installs were manual. Getting images into an offline data center meant mirroring them by hand.
• Registry access depended on credentials handed to each customer.
• There was no licensing. Enkrypt had no way to tie a deployment to a customer, issue a time-limited trial, or gate features by tier.
• There were no release channels. Every customer got the same version at the same time, with no beta group and no staged rollout.
• There was no visibility after install. Enkrypt could not see which version a customer was running, so support and upgrade planning started without deployment context.

One distribution layer for VPCs, OpenShift, and air-gapped Kubernetes

We kept Enkrypt's Helm charts as the packaging format and added a distribution layer, Replicated, between Enkrypt's release process and its customers. Enkrypt now publishes a release once. Replicated handles who is allowed to get it, which version each customer sees, how images reach the cluster, and whether that cluster is ready for the install.

The same chart and release process covers dedicated customer VPCs on AWS, Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE), Red Hat OpenShift clusters on-premise, other on-premise Kubernetes distributions, and air-gapped data centers.

Figure 1. One release, two delivery paths. Connected clusters pull images with their license and report version and status back. Air-gapped sites install from a bundle and do not report back.

Why a distribution platform instead of more scripts

Every problem on the list above sits in the same place: between the release being built and the release running in the customer's cluster. Licensing, credential handling, prerequisite checks, release targeting, air-gap packaging, and install inventory can each be scripted on their own. Together, they become a second product that someone has to build and maintain.

Replicated covers all six on top of standard Helm charts. Enkrypt's engineers did not have to migrate to a different packaging format, and customers' platform teams kept the Helm workflow they already knew.

One license per customer

Each customer gets a unique license tied to its installation. Licenses carry the customer's entitlements for different feature tiers, and trial licenses carry an expiration date. Customers manage their installs, updates, release notes, and license details through a self-service portal instead of asking Enkrypt's team.

Release channels instead of per-customer coordination

Enkrypt maintains three release channels: Internal, Beta, and Stable. Each customer is assigned to a channel. A release moves from Internal to Beta to Stable, and when it lands on a channel, every customer on that channel can see it and install it from their portal.

Staged rollout stops being a coordination task. It becomes a question of which channel a customer is on.

Preflight checks that fail before the install does

Before installation, preflight checks run against the target cluster and report anything that would cause the install to fail: no usable StorageClass, a Kubernetes version outside the supported range, or not enough CPU and memory for the platform. A failed check returns a specific message, so the customer's platform team closes the gap before deploying instead of reading pod logs afterward.

Replicated's preflight checks are built on the open-source Troubleshoot project and defined in YAML alongside the Helm chart. Here is a simplified example of the kinds of checks involved:

apiVersion: troubleshoot.sh/v1beta2
kind: Preflight
metadata:
  name: enkrypt-ai-preflight
spec:
  analyzers:
    - clusterVersion:
        outcomes:
          - fail:
              when: '< 1.27.0'
              message: Kubernetes 1.27 or later is required. Upgrade the cluster before installing.
          - pass:
              message: Kubernetes version is supported.
    - storageClass:
        checkName: Default StorageClass
        outcomes:
          - fail:
              message: No default StorageClass found. Create one or set a StorageClass in the chart values.
          - pass:
              message: A default StorageClass is available.
    - nodeResources:
        checkName: Total allocatable CPU
        outcomes:
          - fail:
              when: 'sum(cpuAllocatable) < 16'
              message: The cluster needs at least 16 allocatable CPU cores.
          - pass:
              message: The cluster has enough CPU capacity.
yaml

Simplified for illustration. Version and resource thresholds are examples, not Enkrypt's production requirements.

Image delivery without shared credentials

Container images now reach customers through Replicated rather than through credentials Enkrypt hands out. Customers authenticate with their license, image pull secrets are generated for the install, and Enkrypt's own registry credentials are never shared with customers. Access follows the license, not a shared secret.

Air-gapped installs from a single bundle

For data centers with no internet access, each release is available as an air-gap bundle that contains the application and its container images. The customer downloads it from the portal on a connected machine, carries it across the air gap, and installs from it. Nothing in the deployment reaches out to the internet, and there is no image-by-image mirroring to coordinate with Enkrypt.

Knowing what customers run, and where that stops

Connected installations report their version and status back to Enkrypt. That gives Enkrypt a version inventory across customers, release adoption data, and installation health, so a support conversation starts with context instead of asking which version the customer is on.

Air-gapped installations cannot report back. That is the point of an air gap. For those sites, Enkrypt's view depends on what the customer's team shares.

Running customer deployments alongside Enkrypt's team

Before each deployment, we assessed the customer's environment, documented infrastructure requirements, ran preflight checks, and provisioned the license and portal access. During installation, the customer followed a guided install through the portal with support on hand. Afterward, we verified installation health and configuration, established a performance baseline, and planned the upgrade path. We also coordinate version upgrades, manage release channel assignments, and watch deployment health for connected installs.

Results

The Helm chart did not change much. Everything around it did.

Figure 2. Shipping a release, before and after.

Installation-related support load dropped, because environment problems now show up in preflight output instead of halfway through an install. Adding a customer no longer adds manual distribution work for every release.

"CloudRaft played a key role in establishing robust, industry-standard DevOps practices for Enkrypt AI. Their expertise in scalable enterprise Kubernetes deployments, networking, monitoring, and operations ensured seamless customer deployments. Their reliable support significantly strengthened our platform, and we highly recommend CloudRaft."

— Prashanth Harshangi, Co-founder and CTO, Enkrypt AI

What we would tell other teams shipping AI software into enterprises

• Distribution is more than packaging. A Helm chart answers how to install the software. Enterprise customers also need answers to who is licensed, which version they should run, whether their cluster is ready, and how the software gets in without internet access. Plan for all of them before the customer list gets long.
• Treat air-gapped as a first-class target. For AI security buyers in regulated industries, an offline install is often a requirement rather than an edge case. Designing for it early costs less than retrofitting it.
• Fail before you install. A preflight check that names the missing StorageClass is far cheaper than debugging a failed install on a customer's cluster you cannot access.
• Be honest about what you can see. Connected installs can report back. Air-gapped ones cannot. Plan support and upgrades around both.
• Let customers serve themselves. A portal with install instructions, release notes, and license details takes routine requests off the support queue.

Technology stack

Shipping self-hosted software to enterprise customers?

If your customers need your product inside their own VPC, on OpenShift, or in an air-gapped data center, we can help you package, license, and ship it without maintaining a separate build for every environment.