App Service won't allow the level of privilege needed to start the "head" container that enables container-in-container to work. Options like `--privileged` and

App Service won't allow the level of privilege needed to start the "head" container that enables container-in-container to work. Options like `--privileged` and `--cap SYS_ADMIN` or mounting special volumes from the host are the first step on "how to escape from a container" so shared container services don't allow them. The options might be more allowable in your own App Service Environment but I don't think the API is even there to set the options in the first place. Container-in-container also pushes a number of responsibilities from the the App Service down into the head container, like ingress, service management, health, logging etc. You might as well run compose/swarm on your own VM(s) than reinvent those wheels. AKS + kompose might be a not too bad option. AKS can deploy on the private vnet and can do private endpoints. The cluster will probably fall over once a year for <reasons> but it will mostly manage itself. If you leave k8s to auto upgrade, run a microk8s instance as a test env somewhere and it will hit the upgrade issues before AKS releases a k8s version. - https://github.com/kubernetes/kompose https://github.com/kubernetes/kompose - https://learn.microsoft.com/en-us/azure/aks/private-clusters#use-a-private-endpoint-connection https://learn.microsoft.com/en-us/azure/aks/private-clusters...