Prerequisites — Azure (AKS, VM, Container Apps)

Status: all three Azure paths below were installed end to end and are preview install paths like the on-premises ones — AKS on 2609.0.0-preview.15, an Azure VM on 2609.0.0-preview.17, and Azure Container Apps on 2609.0.0-preview.27, deployed with Install-CloudGrange-Aca.sh into a throwaway subscription resource group and then driven through the same product checks as every other path. Install-CloudGrange-Aca.zip is published with 2609.0.0-preview.27 and every release after it, so the install guide’s download step resolves. That first release has three known Container Apps defects — a region-dependent deployment failure, a 502 on SSO sign-in, and in-app updates refused at the pre-update backup — all fixed in the next release. See current product and release status.

CloudGrange plans three Azure paths. They differ in who owns the Foundation:

Common to every Azure path

AKS

AKS is a customer foundation: you create and upgrade the cluster, and CloudGrange installs and updates the Platform on it. Everything on the BYO Kubernetes prerequisites page applies. The chart does not create Azure resources. CloudGrange verified this path on AKS 1.36 with the application routing add-on (2609.0.0-preview.15).

Install exactly as for bring your own Kubernetes, without the cert-manager step, and add the Azure overlay, which is inside the chart archive:

tar xzf cloudgrange-chart.tgz cloudgrange/values-azure.yaml
helm install cloudgrange ./cloudgrange-chart.tgz \
  --namespace cloudgrange --create-namespace \
  -f cloudgrange/values-azure.yaml \
  --set global.hostname=<your-hostname> \
  --set global.aks.tlsCertificateUri=https://<vault>.vault.azure.net/certificates/<certificate-name> \
  --timeout 15m --wait

global.aks.tlsCertificateUri is the certificate URI without a version.

Optional: Azure Key Vault as a secrets provider, with no stored credential. To let CloudGrange read and write secrets in a Key Vault as its own workload identity (Secrets → Add provider → "The platform's managed / workload identity"):

1. Create a user-assigned managed identity and give it Key Vault Secrets Officer on the vault.
2. Add a federated credential to it for your cluster's OIDC issuer URL and subject system:serviceaccount:<namespace>:<release>-api (for the command above: system:serviceaccount:cloudgrange:cloudgrange-api).
3. Set the identity on the release: helm upgrade cloudgrange ./cloudgrange-chart.tgz -n cloudgrange --reuse-values --set global.aks.managedIdentityClientId=<client ID> --set global.aks.tenantId=<tenant ID>. The API restarts with the identity.

Permissions. To create the cluster, identity, vault and role assignments you need Contributor, plus User Access Administrator or Owner on the resource group. To install the chart you need cluster-admin on the AKS cluster. See RBAC and namespace.

Updates. You upgrade AKS and its node images. Platform → Updates updates the Platform in the cluster and shows the cluster's Kubernetes version and whether it is in the Platform's supported range. It never offers a Foundation update on AKS.

Azure VM

The Azure VM path is a managed foundation: an Ubuntu VM in your subscription that runs the Linux script on its first boot, which installs K3s and the chart. It gets the same Foundation updates as the other managed foundations, always started by an administrator.

You create the VM; CloudGrange's cloud-init file does the rest. Pass azure-vm/cloudgrange-cloud-init.yaml from the installer repository as the VM's custom data. On first boot it downloads the latest release bundle from GitHub, checks its SHA-256 and runs Install-CloudGrange-Linux.sh. The platform's address is the VM's public IP address (else its private one). To use a DNS name instead, set CLOUDGRANGE_HOSTNAME at the top of the file's script before you create the VM.

What you will need:

• Contributor on a resource group, to create the VM, its disk, network interface, network security group and public IP.
• A VM with Ubuntu 24.04 LTS (amd64) and at least the Linux script's sizing (4 vCPU, 8 GB, 30 GB). Verified on Standard_D4s_v5 (4 vCPU, 16 GB) with a 64 GB OS disk.
• Outbound internet access from the VM on first boot (GitHub and ghcr.io).
• Inbound TCP 443 (users and the cg CLI) and TCP 8443 (managed hosts' agents), allowed in the network security group from the addresses that need them. Keep SSH (22) closed or limited to your own address.

For example, with the Azure CLI (replace the release tag with the latest one on the releases page):

curl -fsSLO https://raw.githubusercontent.com/CloudGrange/cloudgrange-deployment-installer/2609.0.0-preview.19/azure-vm/cloudgrange-cloud-init.yaml
az vm create -g <resource group> -n cloudgrange --image Canonical:ubuntu-24_04-lts:server:latest \
  --size Standard_D4s_v5 --os-disk-size-gb 64 --public-ip-sku Standard \
  --admin-username azureuser --generate-ssh-keys --custom-data cloudgrange-cloud-init.yaml
az vm open-port -g <resource group> -n cloudgrange --port 443,8443 --priority 900

The install runs for several minutes after the VM starts; /var/log/cloudgrange-azure-vm.log on the VM shows its progress. Then open https://<public IP> and complete the setup wizard. The certificate is issued by the platform's own CA for that address; download the CA from Platform → CLI to trust it.

Azure Container Apps

Container Apps does not run Kubernetes that you manage and does not use the Helm chart — Container Apps has its own deployment schema and cannot run Kubernetes manifests. The platform is deployed by the Bicep template in the installer repository (iac/main.bicep), driven by scripts/Install-CloudGrange-Aca.sh. The full procedure is on the Container Apps install guide.

Everything above the deployment format is the same product as on every other path: the same API and portal, the same Keycloak realm, the same built-in relay, the same modules and cg CLI, and the same Platform → Updates page.

There are no Foundation updates on this path, and the portal shows no Foundation card. Azure owns the host operating system and the runtime, so CloudGrange has no Foundation to offer. Platform updates are in-app, through a Container Apps executor behind the same API: it verifies the release manifest's SHA-256, takes an on-demand backup of the PostgreSQL flexible server, then re-tags each CloudGrange container so Azure rolls a new revision. Read Updates and rollback before relying on rollback — it returns the application to the previous release but does not restore the database, because the database is a managed Azure service rather than a container the updater controls.

The template deploys at subscription scope (targetScope = 'subscription'). It creates the resource group and role assignments, optionally Azure Policy assignments and Microsoft Defender for Cloud pricing settings, alongside:

Only the portal is published. Keycloak and the relay use internal ingress. The portal proxies /api, /hubs, /realms/cloudgrange and the pinned Keycloak theme path, so authentication lives on one origin here exactly as the chart's Ingress arranges on Kubernetes — which is what keeps SSO and cg auth login identical across paths.

Bootstrap secrets: nothing to create. The installer generates the database password, the encryption master key, the Keycloak bootstrap credentials, the API's realm client secret and the relay enrolment token, and stores them in the deployment's Key Vault. None is printed or written to a file, and none is ever an operator input. A re-run reads each value back from the vault rather than generating a new one, so redeploying does not rotate a live credential.

Permissions. Because the template assigns roles at resource scope and creates the resource group, the deploying identity needs Owner, or Contributor plus User Access Administrator, on the subscription. Leaving the governance options on additionally requires rights to change Defender for Cloud pricing and to assign Azure Policy.

Governance changes outlive the resource group. Azure Policy assignments and Defender for Cloud plan changes are made outside the resource group, so deleting the group does not undo them. Pass --no-governance for any deployment you intend to throw away.

Quotas. The subscription needs Container Apps and PostgreSQL flexible server capacity in the chosen region (location, default eastus).

See current product and release status.