Choose a provisioner backend for agents
Compare Docker, Kubernetes, experimental NemoClaw sandboxing, and planned Proxmox placement to pick the right agent isolation and scaling strategy for your Nora deployment.Nora provisions agent runtimes onto execution targets selected in the Deploy flow. Docker and Kubernetes are GA paths. Docker is the default. Kubernetes clusters are registered in Admin -> Kubernetes so one Nora control plane can manage several clusters at once. NemoClaw is an experimental sandbox profile layered onto supported targets. Proxmox is a planned execution target and remains release-blocked in current Nora releases.
Docker
Single-host deployments, local development, and quick evaluation.
Proxmox (planned)
Planned Proxmox-managed LXC runtime placement. Not supported in the current release.
Kubernetes
K3s, AKS, GKE, EKS, or another conformant Kubernetes cluster.
Comparing backends
| Docker | Proxmox | Kubernetes | |
|---|---|---|---|
| Support status | GA | Planned / release-blocked | GA |
| Deployment scale | Single host | Private VM/LXC fleet | Multi-node cluster |
| Agent isolation | Container | Proxmox LXC | Pod and namespace boundaries |
| Setup complexity | Low | Medium - Proxmox API plus SSH bootstrap | Medium to high - cluster and kubeconfig |
| Best for | Local dev, evaluation, lean self-hosted | On-prem and private infrastructure operators | Cloud-native and managed-cluster rollouts |
| Horizontal scaling | No | Limited by Proxmox fleet capacity | Yes |
Runtime selection
Runtime selection is three-dimensional:ENABLED_BACKENDS=docker for normal onboarding. Proxmox is a known but release-blocked target; adding proxmox only surfaces the blocked roadmap target for operator awareness. Do not add Kubernetes labels to ENABLED_BACKENDS; the Kubernetes deploy targets come only from the Admin cluster registry.
Register Kubernetes clusters in Admin -> Kubernetes. Each enabled registry row with a passing Test result becomes a separate deploy target with an id like k8s:aks-eastus2, while persisted agents still use the base k8s adapter internally. Failed, untested, or disabled clusters stay visible in Admin but are hidden from the Deploy page for both OpenClaw and Hermes. The Deploy page shows the cluster label, provider, actual cluster name, namespace, and exposure mode so operators can tell AKS, GKE, EKS, K3s, Kind, or generic clusters apart.
Each Kubernetes provider guide includes the Admin registry values for that backend. Put kubeconfig files under NORA_KUBECONFIGS_DIR; docker-compose.kubernetes.yml mounts that directory at /kubeconfigs, so Admin rows can point to paths such as /kubeconfigs/aks-eastus2 and /kubeconfigs/aks-westus2.
Kubernetes providers
The Kubernetes adapter is provider-neutral. Nora talks to the Kubernetes API through the kubeconfig stored on each Admin-registered cluster, then creates Deployments and Services for each OpenClaw or Hermes agent. Compose overlays only mount kubeconfig files into the containers; provider, namespace, exposure, Service annotation, and load-balancer options are saved on the Admin cluster row.Generic Kubernetes
Adapter contract, exposure modes, namespace, service annotations, and RBAC expectations.
K3s
Lightweight self-hosted Kubernetes setup through the generic Kubernetes overlay.
AKS
Azure Kubernetes Service setup through the generic Kubernetes overlay.
GKE
Google Kubernetes Engine setup through the generic Kubernetes overlay.
EKS
Amazon EKS setup through the generic Kubernetes overlay.