Support boundary and shared responsibility
Every CloudGrange deployment has two layers:
- The Platform is the CloudGrange Helm release: our services, their images, the database schema and your data. CloudGrange owns the Platform on every delivery path.
- The Foundation is everything below it: the host operating system, the Kubernetes distribution, the container runtime, host services, and network and disk configuration. Who owns the Foundation depends on how you installed CloudGrange.
The rule is simple:
- If you ran any CloudGrange installer (the VHDX appliance, the Windows script or the Linux script), CloudGrange owns the Foundation. That includes the operating system and its updates, which CloudGrange delivers through the admin-started Foundation card. This is a managed foundation. The Azure VM path, where CloudGrange provisions the VM, is a managed foundation too.
- If you installed the chart with
helmdirectly on your own cluster, you own the Foundation. This is a customer foundation, and CloudGrange never changes it. - On AKS and Azure Container Apps, Azure and you own the Foundation together. CloudGrange does not change it.
CloudGrange is in active development and is not GA. No response-time SLA is offered for this preview. See current product and release status.
Who owns what
CG = CloudGrange. You = the customer. Azure = Microsoft, under your Azure agreement. "CG (admin applies)" means CloudGrange builds, tests and publishes the update, and your administrator decides when to apply it.
| Item | VHDX appliance | Windows script | Linux script | Azure VM | BYO Kubernetes | AKS | Azure Container Apps |
|---|---|---|---|---|---|---|---|
| Physical hardware, hypervisor | You (Hyper-V) | You (Hyper-V) | You | Azure | You | Azure | Azure |
| Hyper-V host OS and patches | You | You | — | — | — | — | — |
| VM definition (vCPU, memory, disk, switch) | You, after import | You, after install | — | CG creates; you size | — | — | — |
| Guest / node OS (Ubuntu) and its patches | CG (admin applies) | CG (admin applies) | CG (admin applies)¹ | CG (admin applies) | You | Azure node images; you apply | Azure + you |
| Kubernetes distribution and version | CG: K3s (admin applies) | CG: K3s (admin applies) | CG: K3s (admin applies) | CG: K3s (admin applies) | You | You + Azure | Azure (not Kubernetes you manage) |
| Container runtime | CG (with K3s) | CG (with K3s) | CG (with K3s) | CG (with K3s) | You | Azure | Azure |
| Ingress controller | CG (K3s Traefik) | CG (K3s Traefik) | CG (K3s Traefik) | CG (K3s Traefik) | You | You | Azure |
| Storage / StorageClass | CG (K3s local-path) | CG (K3s local-path) | CG (K3s local-path) | CG (K3s local-path) | You | You (Azure Disk CSI) | Azure |
| LoadBalancer for the relay | CG (K3s ServiceLB) | CG (K3s ServiceLB) | CG (K3s ServiceLB) | CG (K3s ServiceLB) | You | Azure LB | — |
| cert-manager | CG | CG | CG | CG | You | You | — |
| TLS certificate (replacing the self-signed default) | You | You | You | You | You | You | You |
| Network: IP plan, DNS, firewall, egress | You | You | You | You | You | You | You |
| Platform: CloudGrange services, images, chart | CG | CG | CG | CG | CG | CG | CG |
| Platform updates | CG (admin applies) | CG (admin applies) | CG (admin applies) | CG (admin applies) | CG (admin applies) | CG (admin applies) | CG (admin applies) |
| Database schema and migrations | CG | CG | CG | CG | CG | CG | CG |
| Your data (hosts, settings, users) | You | You | You | You | You | You | You |
| Backups and DR target | You | You | You | You | You | You | You + Azure |
| Identity: users, roles, SSO integration | You | You | You | You | You | You | You |
| Managed Hyper-V hosts and the agent service | You install; CG ships the agent | ← same | ← same | ← same | ← same | ← same | ← same |
¹ On the Linux script path you provide the server, but once you run the script, CloudGrange owns its Foundation, including the Ubuntu operating system and its updates. That is why the server must be a dedicated, fresh install of a supported Ubuntu release, used only for CloudGrange. See Linux script prerequisites.
What "managed foundation" means for you
On the appliance, the Windows script, the Linux script and the Azure VM path, CloudGrange:
- chose and pinned the operating system image and the K3s version;
- publishes signed, versioned Foundation releases (for example
F2609.1.0) with release notes; - offers them in Platform → Updates on a separate Foundation card;
- never applies them by itself, including security patches. Your administrator starts every Foundation update. Before the administrator confirms, the Foundation card lists the exact packages and the K3s version it will change, and whether a reboot is needed;
- refuses a Foundation update that would move Kubernetes outside the range your installed Platform supports.
You remain responsible for the Hyper-V host or Azure subscription, the network, the VM's size, backups, and applying the updates CloudGrange publishes. A managed foundation that is not updated falls behind on security patches.
Do not change the managed foundation yourself, for example by upgrading K3s by hand, running apt upgrade, enabling unattended-upgrades or installing other workloads on the host. CloudGrange cannot support a foundation it no longer matches.
What "customer foundation" means for you
When you install the chart with helm directly on your own Kubernetes cluster, you own the cluster. On AKS you own it together with Azure. You:
- choose, upgrade and patch Kubernetes, the nodes and their operating system;
- provide and operate the ingress controller, StorageClass, LoadBalancer and cert-manager, and grant the chart the RBAC and Pod Security it needs;
- keep Kubernetes inside the Platform's supported range. Platform → Updates shows your cluster's version and whether it is in range.
CloudGrange supports the Platform on any cluster that meets the BYO Kubernetes prerequisites. Problems below the chart, such as a failing CSI driver, an ingress misconfiguration or node pressure, are yours to resolve. CloudGrange will help you tell which side of the boundary a problem is on.
The rule behind the boundary
The Helm chart is the product. The installer paths only provision a host and Kubernetes, then run the chart. They never do Platform work of their own. So the Platform behaves the same on every path, and anything the Platform needs is available to a bring-your-own-Kubernetes customer too.
See Updates, Prerequisites and the glossary.