Hosted Control Plane Limitations
The Hosted Control Plane is in active development. This page describes current constraints and what is on the roadmap.
Current Constraints with the PaaS Hosted Control Plane
Management Clusters Run on Civo Only (AWS, GCP, Bare Metal Coming)
Management clusters must be provisioned on Civo Kubernetes. You cannot use an existing EKS, GKE, or AKS cluster as a management cluster with the hosted control plane.
Workload clusters support multiple clouds. See Supported Clouds for the current list.
Multi-cloud management cluster support is on the roadmap. See Roadmap below.
No Direct Access to the Control Plane Cluster
The Konstruct control plane runs on a Civo-managed cluster. You cannot:
- Run
kubectlagainst the control plane cluster - Deploy custom workloads onto the control plane cluster
- Access control plane logs directly
All interaction with the control plane happens through the Konstruct UI and API at konstruct.saas.civo.com.
No Custom Operator Versions on the Control Plane
You cannot pin or roll back the version of Konstruct operators running on the hosted control plane. Civo manages operator upgrades on a release schedule.
If you require control over control plane upgrade timing or need to run a specific operator version, use the Self-Hosted Control Plane.
No Access to Control Plane Custom Resources
You cannot modify the configuration of components running on the control plane, including:
- Konstruct API settings
- Operator environment variables and feature flags
- ArgoCD configuration on the control plane (distinct from ArgoCD on your management cluster)
- Secrets and credential storage configuration
- Access to Konstruct custom resources for cloud accounts, git operations, etc
What You Do Control
The hosted model gives you full ownership and control of your platform tier:
- Management cluster — you own the Civo Kubernetes cluster, its node pools, and all workloads running on it
- GitOps repository — your ArgoCD applications, infrastructure code, and cluster configurations live in a repository you own and can modify directly
- Workload clusters — provisioned, configured, and deprovisioned at your direction
- Platform tooling — ArgoCD, cert-manager, ingress-nginx, and other platform apps on your management cluster are managed via your GitOps repo; you can add, remove, or reconfigure them
- Cluster templates — define custom Terraform modules and GitOps content for how your clusters are provisioned
When to Choose Self-Hosted Instead
Consider the Self-Hosted Control Plane if you need any of the following:
| Requirement | Self-Hosted | Hosted |
|---|---|---|
| Air-gapped or private network installation | Yes | No |
| kubectl access to the control plane | Yes | No |
| Konstruct CRD access | Yes | No |
| Pinned control plane version / manual upgrade schedule | Yes | No |
| Management clusters on non-Civo clouds (today) | Yes | No |
| On-premises or bare-metal management clusters | Yes | No |
| Specific data residency requirements for control plane | Yes | No |
Roadmap
The following improvements are planned for the Hosted Control Plane:
- Multi-cloud management clusters — provision management clusters on AWS, GCP, and Azure in addition to Civo. If you're looking for this now talk to us
- More customization options — surface additional control plane configuration through the UI and API, reducing the need to switch to self-hosted for common use cases
- Audit logging — export control plane audit events to your own logging infrastructure
Roadmap items are not committed delivery dates. Contact your account team or the Konstruct community for current status.
What's Next?
- Quickstart — start with the hosted control plane
- Hosted vs Self-Hosted — full feature comparison
- Install Self-Hosted — set up a self-hosted control plane if you need capabilities not available in hosted