Terraform provisions infrastructure. Helm deploys applications. Together, they make installing your software repeatable and predictable. But getting software running is not the same as delivering a managed service that customers can easily adopt, consume, and scale.
Your customers still need to configure environments, troubleshoot failures, manage upgrades, monitor health, handle security patches, and recover from outages. If customers own these responsibilities, you're asking them to become operators of your software. If your engineers handle them, every new customer adds operational overhead.
Either way, the cost is real: slower customer onboarding, longer sales cycles, higher operational costs, and limited ability to scale. This is the fundamental limitation of Terraform and Helm. They automate individual infrastructure and application deployment tasks, but they don't automate the end-to-end customer journey. Turning software into a managed service requires much more: self-service onboarding, secure provisioning, lifecycle management, upgrades, monitoring, recovery, metering, and billing—all working together without manual intervention.
In our earlier article, Why Deployment Automation Is a Day-One Problem for AI Startups, we explained why startups need to solve deployment automation from day one rather than treat it as a scaling problem for later. Here, we'll explore why Terraform and Helm alone aren't enough, what's missing, and what it takes to deliver a truly automated customer experience that scales with your business.
1. Your customer experience shouldn't be a set of deployment scripts
When a prospective customer wants to evaluate your product, you send them Terraform modules, Helm charts, and instructions. Their platform engineer runs the scripts, adjusts configurations, troubleshoots permissions, and eventually gets the application running. The scripts may work perfectly, but the customer is still doing part of your deployment work.
THE CHALLENGE
Bad developer experience: A developer interested in trying your product shouldn't have to schedule a sales call, understand your infrastructure, or spend hours following installation instructions. Every additional step creates friction and increases the likelihood of losing a potential customer before they experience the value of your product.
Sales friction: Moreover, every sale will require understanding complex workload requirements upfront, making it harder for customers to start small and grow over time. This adds friction and slows down sales. Simple, transparent, and predictable pricing based on usage or value delivered makes it easier for customers to get started.
No feedback: Worse, customers who abandon an evaluation rarely tell you why. Without visibility into the onboarding process, you may never know how many potential customers you lost, where they got stuck, or what prevented them from experiencing your product.
The goal should be to let customers discover, evaluate, and start using your product with minimal friction. Onboarding should be self-service, pricing should be transparent, and customers should be able to provision their deployments without depending on your engineers.
If you offer your software as a managed service through a branded self-service portal, that same customer can choose a subscription plan, select a cloud and region, connect their infrastructure if needed, configure the service, and deploy. Once it's running, they can check its health, change configurations, scale resources, review usage, manage team permissions, and initiate supported lifecycle operations themselves. Your engineers no longer need to join every onboarding call or handle every routine change request.
Gartner's 2026 research found that 70% of B2B buyers prefer a completely digital, self-service buying experience. MongoDB lets developers create temporary database clusters through a single API call without creating an account. Snowflake lets customers start a trial without providing payment information. These companies are removing the barriers between customer interest and product adoption. Customers can experience the product's value before making a significant commitment, while the vendor retains control over the service.
As AI agents increasingly discover, evaluate, and consume software on behalf of users, your customer experience needs to work for machines, not just humans. An AI agent cannot navigate manual setup instructions, troubleshoot Helm charts, or coordinate Terraform scripts with your engineering team. It needs a fully automated, API-driven experience where it can provision, configure, scale, upgrade, and manage your product programmatically. If your product requires manual intervention to get started or operate, you're creating a barrier not just for human customers, but for the next generation of AI-driven customers. The future of software consumption is self-service and machine-to-machine, and deployment scripts alone aren't enough to get you there.
FalkorDB faced this exact challenge when turning its open-source graph database into a fully managed cloud service. Rather than asking customers to manage installations or spending months building its own control plane, FalkorDB used Omnistrate's generated control plane to deliver a fully automated, self-service experience. Customers could sign up, configure, and provision their databases without running Terraform or Helm scripts or depending on FalkorDB's engineers, making it easier to evaluate and adopt the product.
2. Your customer fleet needs a system of record, not scattered configuration files
THE CHALLENGE
Infrastructure configuration: One customer runs your application on AWS with EKS and RDS. Another requires Azure, while a third uses GCP. Some prefer cost-effective multi-tenant deployments, while others require dedicated infrastructure, custom networking, or deployment in their own cloud accounts. It's the same application, but every customer may have different compute, storage, networking, secrets, and infrastructure requirements.
Application and feature configuration: Every customer may require different application settings. How do you track, update, and consistently enforce these configurations across hundreds of deployments without manually editing Helm values or configuration files?
Pricing and commercial configuration: One customer pays a fixed monthly subscription, another pays based on usage, and a third has negotiated enterprise pricing. Customers may have different minimum commitments, feature entitlements, usage limits, support plans, and billing arrangements. How do you track what each customer is entitled to, measure consumption, and bill them correctly?
Software version and upgrade configuration: Customer A runs version 2.1, Customer B is on 2.3, and Customer C requires a custom release. Some customers want automatic upgrades, while others require maintenance windows, approvals, or staged rollouts. Different customers may have different CVE commitments that you need to contractually honor. You need to know exactly which version is running where, what upgrades are pending, and how to roll back safely.
Managed Service configuration: One customer requires high availability, automated backups, disaster recovery, and private connectivity, while another prioritizes lower costs with simpler infrastructure. Each deployment may have different scaling policies, monitoring requirements, backup schedules, access controls, network restrictions, and security settings. These configurations must be tracked and consistently enforced throughout the deployment's lifecycle.
Operational state and audit history: Customers create, scale, modify, pause, and delete deployments over time. Each change impacts infrastructure, entitlements, billing, and operations, requiring an accurate, up-to-date view of every customer's deployments and their current state. Which deployments are healthy? Which have failed upgrades, configuration drift, or pending maintenance? Who changed a customer's configuration, when, and why?
In a Terraform and Helm world, all this information ends up scattered across Terraform state files, Helm values, Git repositories, cloud consoles, spreadsheets, and internal systems. Infrastructure configurations live in one place, application settings and software versions in another, pricing and entitlements somewhere else, and operational policies and deployment history across multiple tools.
There's no single source of truth for what each customer has, how it's configured, what they're entitled to, and what's actually running. Every customer change requires coordinating across multiple systems, increasing the risk of configuration drift, operational errors, and inconsistent customer experiences. Hence, modern startups build a system of record via control planes to track the customer fleet. As your fleet grows from 1 to 10 to 100 to 1,000 deployments, this quickly becomes even more unmanageable.
The goal of a control plane layer is one product definition instead of a collection of customer-specific forks that keeps growing. A control plane keeps track of the customer, infrastructure, configuration, software version, and operational state while using the Terraform and Helm assets you've already built.
DataRobot faced this challenge while managing its AI platform across on-premises, customer-owned VPCs, and single-tenant SaaS environments on AWS, Azure, and GCP. Each environment had different infrastructure configurations, security requirements, and operational policies. Rather than managing a growing collection of customer-specific configurations and cloud-specific tools, DataRobot used Omnistrate's generated control plane to standardize deployments across environments, centrally manage security and governance, and maintain a unified view of its customer infrastructure. One control plane to manage a diverse customer fleet instead of separate configurations and processes for every deployment.
3. Your customer deployments need much more than Terraform and Helm scripts
You've successfully deployed your application using Terraform and Helm. But does that mean you're ready to offer Hosted SaaS or deploy into your customers' cloud environments? Not quite.
THE CHALLENGE
Even Hosted SaaS requires far more than running deployment scripts. You need to decide how customers share infrastructure, how tenants are isolated, how compute and storage are provisioned, and how to support customers who require dedicated environments. Your deployment architecture must accommodate different workloads, regions, capacity requirements, and isolation levels without requiring custom engineering for every customer.
BYOC (Bring Your Own Cloud) introduces an entirely different level of complexity. Your software now runs inside infrastructure you don't own or control. One enterprise customer provides a dedicated AWS account, another requires deployment into an existing VPC with private networking, and a third allows only an approved Kubernetes cluster. Enterprises will require strong controls from no inbound connectivity, restricted outbound internet access, strict IAM permissions, Service Control Policies (SCPs), customer-managed encryption, container image security policies and so on.
Yes, we have to securely establish trust between your control plane and customer environments, deliver software artifacts through approved channels, provision infrastructure with limited permissions, and orchestrate deployments across different clouds and security boundaries. It requires a set of vetted controls to achieve the enterprise requirements. Our BYOC Anywhere framework outlines ten foundational principles for deploying software into customer-owned environments, covering data sovereignty, zero-trust connectivity, identity and permissions, software supply chains, auditability, and customer-controlled access.
Now, you have to make all these deployment, networking, security, and infrastructure controls work consistently across AWS, Azure, GCP, and on-premises environments. Each has different APIs, permissions, networking models, and infrastructure constraints, requiring you to build and maintain cloud-specific integrations while delivering a consistent deployment experience to every customer. A script that works perfectly in your AWS account may fail completely inside a customer environment.
With a proper control plane, you can hide all this complexity and define your application once and deploy it consistently across Hosted SaaS, dedicated environments, BYOC, and even air-gapped infrastructure. Terraform and Helm remain valuable building blocks, but you need a deployment orchestration layer that understands the target environment, manages its constraints, and coordinates the entire deployment process.
Zep faced this exact challenge when deploying its AI platform into Fortune 500 customer environments. Enterprise security requirements, including restricted outbound connectivity, SCPs, and locked-down container image supply chains, made traditional deployment scripts insufficient. By leveraging Omnistrate's generated BYOC control plane, Zep could automate deployments into customer-owned VPCs while respecting their security and networking requirements, instead of building a custom deployment process for every enterprise customer. Watch Zep AI CEO Daniel Chalef explain the real challenges of enterprise BYOC deployments
4. Deploying a version is easy. Managing versions across customers isn't.
THE CHALLENGE
A critical security vulnerability in your application requires a new container image and an updated Helm chart. With Terraform and Helm, publishing the fix is straightforward, but getting it safely deployed across your customer fleet requires considerably more work. Some customers are on the latest release; others are several versions behind. One enterprise customer has a Sunday maintenance window, another requires explicit approval before changes, and a third needs a customer-specific hotfix. You need to know who's affected, which upgrades are compatible with the versions they run, and how to deploy the patch without disrupting everyone else.
Deploying a new version to one environment can be automated with Helm. Managing versions across customers requires a control plane that knows what each customer is running and which changes are permitted. It coordinates staged rollouts, maintenance windows, approvals, version tracking, upgrade status, and failure handling. Customers can see available releases and initiate upgrades within the policies you've set.
That responsibility extends beyond application releases. Kubernetes versions change, infrastructure configurations evolve, dependencies need security patches, and storage or compute may need migration. Your CI/CD pipeline builds and publishes new releases, while Terraform and Helm execute changes in individual environments. The control plane coordinates how those changes reach each customer and tracks what succeeded, failed, or still needs attention.
Rox needed to deliver its AI platform across dedicated SaaS, customer-owned VPCs, and fully air-gapped environments. Each deployment model introduces different challenges for delivering software updates, security patches, and ongoing upgrades, especially when some environments have no external connectivity. Rather than building separate deployment and lifecycle processes for each model, Rox adopted Omnistrate's generated control plane to standardize software delivery and lifecycle management, including the packaging and operational logic needed for offline environments. This provides a foundation for managing releases across different customer environments without treating every update as a separate engineering project.
5. Getting software running is not the same as keeping it running
THE CHALLENGE
A deployed Helm release and healthy Kubernetes pods don't necessarily mean the service is working for the customer. Background processing could have stalled, a network partition could make the application unreachable, storage could be running out, or failing database connections could be causing timeouts. The containers can look healthy throughout.
Running a managed service requires visibility into infrastructure and application health, plus a way to respond when something goes wrong. Across customer deployments, you need logs and metrics from the system and application layers, end-to-end health monitoring, alerting, audit trails, and lifecycle workflows that can act on what they find.
Failure recovery may involve restarting an affected component, triggering application-aware failover, restoring from a validated backup, or detecting infrastructure drift. Your control plane also needs to escalate failures when automated recovery isn't safe. Those workflows have to be tailored to the application and its infrastructure; Kubernetes doesn't handle them all for you.
Troubleshooting becomes substantially harder across 50 customer-owned environments, each with its own network restrictions and security policies. Operating that fleet reliably calls for consistent processes and as little manual intervention as possible. The control plane needs to coordinate those operations across the entire fleet.
Plotline faced this challenge while supporting over 1.5 billion API calls daily. Its engineers were spending valuable time maintaining production infrastructure, troubleshooting brittle scripts, and managing inconsistent deployment processes. By using Omnistrate as its internal delivery platform, Plotline standardized deployments, automated infrastructure management, and gained unified operational control. This reduced ongoing maintenance overhead and enabled Plotline to run DevOps at scale without dedicated DevOps engineers.
6. A deployment isn't a subscription, and a running application isn't revenue.
THE CHALLENGE
Your infrastructure automation deploys the software successfully. But, consider the commercial systems involved when a customer buys your Enterprise offering through AWS Marketplace, deploys it into their VPC, increases capacity three months later, and renews their contract. That single customer journey involves several systems.
The marketplace transaction has to map to the right customer and subscription. The subscription determines what they're entitled to deploy, which configurations are allowed, and any resource or usage limits. Your deployment platform must provision the right offering, metering must connect consumption to the right customer, and billing must apply the agreed pricing and report usage through the proper channel.
If you also sell directly, you may need Stripe-based subscriptions, invoices, and payments. Customer-owned deployments may require deployment-specific licensing and entitlement enforcement as well. When someone changes plans, suspends service, or terminates a subscription, your control plane has to handle those transitions consistently.
Terraform provisions infrastructure, and Helm deploys software. On their own, they don't connect contracts, subscriptions, entitlements, usage, licensing, and billing into a commercial offering. Without that integration, your team ends up building more systems and reconciliation workflows around every deployment.
Union AI faced this exact challenge when launching self-service access to its enterprise AI platform through AWS Marketplace. Customers needed to subscribe, activate their entitlements, deploy into their own cloud environments, and pay based on usage—all without manual intervention. Using Omnistrate's generated control plane, Union.ai automated the commercial lifecycle, connecting AWS Marketplace subscriptions, customer onboarding, entitlements, usage metering, and billing. Customers can now subscribe through AWS Marketplace, start a 30-day free trial, connect their infrastructure, and begin using Union.ai without a sales call or separate billing setup. Union.ai turned a Marketplace transaction into a self-service, usage-metered offering rather than just another software installation.
The problem compounds as you grow
Take ten customers, each with a production and a staging deployment. That's 20 application instances. Publish one update a month and you're looking at potentially 240 instance-level upgrade operations in a year, before counting hotfixes, security patches, infrastructure changes, failures, or customer-specific maintenance windows.
With three cloud providers, different networking policies, application versions, and subscription plans, the operational workload grows alongside the number of deployments. A good DevOps engineer can write a script for an individual task, improve a pipeline, or add another monitoring integration. But someone still has to build and maintain the systems that coordinate everything: persistent deployment state, customer permissions, workflow retries, auditability, version compatibility, metering, and recovery from partial failures.
Each of those pieces becomes another production system your engineers own. The hidden cost of building your own managed-service platform is the years spent maintaining and evolving the infrastructure around your product, long after the first implementation. For a startup or growth-stage software company, that work competes with the features your customers are paying you to build.
How Omnistrate builds on Terraform and Helm
Terraform and Helm manage infrastructure and application resources. A managed-service control plane also keeps track of the customer, their subscription, deployments, configuration, and the operational policies that apply to them. It's the system customers use to consume your software and your team uses to operate it.
Omnistrate generates that control plane around your existing application and deployment artifacts, including Helm charts, Terraform modules, container images, or Kubernetes Operators. You define the service requirements, including deployment models, infrastructure, configuration parameters, subscription plans, versions, upgrades, operational workflows, and governance policies. Omnistrate generates a private-label control plane with a customer portal and APIs, along with the capabilities for deployment, fleet operations, billing, and lifecycle management.
You can keep your application and the deployment automation your team has already built. Your engineers can continue building the product customers are buying, instead of maintaining platform engineering as a second product.
Explore how Omnistrate generates control planes from your existing software.