For software vendors selling AI platforms into enterprise accounts, customer-hosted deployments may be part of the commercial and technical requirements for a deal. Customers may require software to run in their own Amazon Web Services (AWS) account, Google Cloud Platform (GCP) project, Azure subscription, or Kubernetes cluster because of data residency requirements, internal security policies, or a need to retain control of the underlying infrastructure.
Once the contract is signed, the delivery work begins. The application team may have purchased the product, but it may not control the cloud account, Kubernetes cluster, DNS records, firewall rules, identity provider, or production change process.
The vendor needs named owners across those teams, clear prerequisites for deployment, and an agreed operating model for what happens after go-live.
An installation date depends on more than the time it takes to run the installer. Self-hosted Kubernetes deployments for AI platforms often stall when customer prerequisites, environment restrictions, and cross-team handoffs are incomplete. Access, approvals, and customer-team availability must be in place before the first deployment session begins.
The people using the software may not control the Kubernetes cluster, cloud account, DNS records, firewall rules, identity provider, or secrets-management process. The schedule is only credible when the customer has identified the teams responsible for each prerequisite and can complete the required approvals. For a Kubernetes-based application, customers may need to provide:
Schedule the installation only after the required customer teams have completed their work or committed to a specific completion date. A calendar invite cannot resolve an open IAM request or a pending firewall review.
A missing IAM permission can pause an installation session. A blocked outbound connection can create a network work item. Both require action from customer teams that may not have been involved in the initial purchase.
These are standard enterprise operating processes. They still determine whether the deployment can proceed on the planned date.
Customer-hosted delivery requires an operating model that accounts for the people who control the environment.
A smaller customer may assign several of these responsibilities to one platform engineer. A larger enterprise may have separate owners for each function. Either way, the people who bought the product may not be the people who can make the changes required to deploy it.
|
Customer Team |
What It Commonly Controls |
How It Affects Deployment |
|
Application team |
Business ownership, internal use cases, acceptance testing |
May own the purchase and product requirements but lack the permissions to make infrastructure changes |
|
Platform or infrastructure team |
Kubernetes clusters, cloud accounts, nodes, storage, ingress, and platform add-ons |
Determines whether the target environment supports the application requirements |
|
Security team |
Container image review, vulnerability processes, RBAC review, data handling, and exception approvals |
May need to approve what runs in the environment and what permissions it requires |
|
Network team |
DNS, load balancers, ingress paths, firewall rules, private connectivity, and egress controls |
Determines whether users, integrations, and external services can reach the application |
|
IAM team |
SSO, service accounts, cloud roles, access policies, and credential processes |
Controls the identities and permissions needed to deploy and operate the application |
|
Change-management team |
Maintenance windows, formal change processes, and release approvals |
Can determine when installation and upgrades can happen |
Identify these owners before you schedule deployment work.
A customer champion can keep the project moving, but may not control the service accounts, firewall rules, DNS records, or production-cluster access required for installation.
A signed contract does not confirm that the customer environment is ready for deployment.
Before your team commits to an installation date, define the information, access, approvals, and customer participants required to begin. Use that Definition of Ready as the gate for scheduling implementation work.
For a Kubernetes-based application, that checklist may cover:
Give customers this material during the sales-to-onboarding handoff. The customer team needs time to route each requirement to the people who can complete it.
If a network or identity requirement first appears halfway through an installation call, the project is already waiting on someone who wasn’t included in the plan.
Documentation establishes the requirements. A readiness gate establishes whether the customer has met them.
Before confirming an installation date, track each requirement, its customer owner, the method used to verify it, and any work that remains open. Your Helm charts, configuration references, deployment guides, and supporting tooling should make those requirements visible before your implementation team joins an installation call.
Build pre-flight validation around the requirements your team can test before installation. Depending on the application, checks may confirm supported Kubernetes versions, required permissions, expected namespaces, storage classes, image-registry access, and connectivity to required endpoints.
Document the Kubernetes and Helm versions your team supports, then test those combinations before making them available to customers.
Customer-owned dependencies still need their own approval path. Access requests, security reviews, DNS changes, firewall exceptions, and maintenance windows should be complete before you schedule the installation.
The first deployment starts the customer relationship. Before the application enters production, define who handles application upgrades, security patches, troubleshooting, and cluster or cloud changes that affect the software. For air-gapped or restricted-egress deployments, document how updates and required artifacts will be handled before go-live.
Tightly controlled customer environments may require separate approval and scheduling cycles for upgrades, patches, and infrastructure changes. Document the operating model before the application goes live.
Clarify who owns:
Scope boundaries matter here. Your team may own the application and its support process. The customer may own cluster health, node capacity, DNS configuration, network policies, and cloud-account access.
Define those responsibilities in writing. When an infrastructure issue occurs, the teams involved should know who investigates first, who can make the required change, and how to escalate the problem. Without that clarity, the vendor can become the default owner for issues it cannot directly diagnose or fix.
Customer-hosted delivery creates work that sits outside the application itself. Engineers may track incomplete prerequisites, join installation calls, investigate Kubernetes configuration issues, coordinate with customer platform teams, and wait for access or networking changes.
Support needs can begin before an installation session and continue through customer go-live. Some vendors need help reviewing their deployment process and documentation before they add more customer installs. Others need Kubernetes expertise available when an active deployment runs into customer-side blockers. High-touch accounts may need direct customer-facing help with coordination and installation.
Fairwinds Self-Hosted AI Platform Deployment Support is designed for AI platform teams offering self-hosted Kubernetes deployments. Fairwinds can assess the deployment process, strengthen prerequisites and runbooks, support vendor teams during active deployments, and work directly with customers on complex installations.
Self-hosted AI software can create opportunities with enterprise customers that cannot use a standard multi-tenant SaaS model. It also changes what the vendor must support after the sale.
A repeatable customer-hosted deployment process needs:
Treat this work as part of the product delivery model. A documented onboarding process gives customers a clearer path to production and gives your internal team a predictable way to plan and support enterprise installations.
If self-hosted AI deployments are delaying delivery or pulling product and platform engineers into repeated customer installation work, talk with Fairwinds about Self-Hosted AI Platform Deployment Support.
