Skip to main content

Kind provisioner backend

Local-only Kubernetes provisioner for development and CI. Not for production.
Kind (“Kubernetes in Docker”) is for local testing only. Do not run production agents on a Kind cluster — it has no persistence guarantees, no load-balancer integration, and no high availability. For a self-hosted production cluster use K3s; for managed control planes use AKS, GKE, or EKS.
Kind uses the same generic k8s backend id as every Kubernetes provider. Nora ships a single Kubernetes adapter (workers/provisioner/backends/k8s.ts) that serves Kind, K3s, AKS, GKE, and EKS — only the kubeconfig and exposure mode change.

When to use Kind

  • Local development of Nora itself, or local exercise of the Kubernetes adapter on a laptop.
  • CI smoke runs that need a real Kubernetes API without a cloud account.
  • Quick regression checks before promoting changes to a K3s or cloud cluster.
Do not use Kind for:
  • Hosting agents you depend on — Kind clusters live and die with the local Docker daemon.
  • Modeling cloud LoadBalancer behavior — Kind only supports NodePort routing in this overlay.
  • Multi-node or multi-host scheduling — the bundled Kind config is single control-plane.

Step-by-step setup

1. Prerequisites

kind itself is auto-installed by e2e/scripts/ensure-kind-tools.sh when the smoke script runs.

2. Run the smoke script

The recommended path is the bundled smoke. It creates or reuses a Kind cluster, exports kubeconfigs for both the host and the in-container view, starts the Nora API and provisioner with docker-compose.kubernetes.yml plus the Kind network helper, registers the cluster in Admin, deploys an agent, verifies Kubernetes objects, and exercises stop/start/restart lifecycle.
Set KEEP_ENV=true to leave the cluster and Compose stack running after the script finishes.

3. Inspect the deployed agent

With KEEP_ENV=true, the smoke run leaves only postgres, redis, backend-api, and worker-provisioner running — no nginx and no frontend dashboard. The URL the script prints (default http://127.0.0.1:4110) is the backend REST API base (the host port maps to the backend-api container’s API port 4000), not a UI. Inspect the agent via the API or kubectl:
To view the agent in the operator dashboard fleet view, bring up the full stack with the command shown in Manual stack (without the smoke script) below, then open the dashboard at http://127.0.0.1:8080/app.
Deploy wizard backend
picker

Nora deploy wizard — Backend dropdown with Kubernetes available

Deploy wizard Kubernetes
selected

Nora deploy wizard — Kubernetes selected, namespace + exposure fields visible

Agent detail K8s

Agent detail page — status running, K8s namespace + service shown

Manual stack (without the smoke script)

Then register the Kind cluster in Admin -> Kubernetes: The Admin Runtime host must be reachable from the Compose containers. On Linux without host.docker.internal support, set it to the Kind control-plane container name (nora-kind-control-plane by default) and join the kind Docker network.

Register local Kind in Admin

Open Admin -> Kubernetes, click Add cluster, and use these values: Do not put /tmp/nora-kind.container.kubeconfig in the Admin Kubeconfig path when Nora runs in Docker Compose. That is the host-side CONTAINER_KUBECONFIG_PATH; the containers see it under /kubeconfigs.

Verification

The smoke script exits with {"ok":true,...} on success. Per-agent objects follow the generated naming convention nora-oclaw-<agent-name>-<suffix> in the openclaw-agents namespace. To smoke NemoClaw on the same Kind adapter path, run the script with K8S_SMOKE_CELLS=openclaw:nemoclaw and NVIDIA_API_KEY set in the shell that starts the stack. If the agent reaches running but the gateway is unreachable, confirm the NodePort values match the port mappings in infra/kind/nora-kind.yaml.
Agent logs K8s

Logs tab — worker-provisioner output during a successful K8s deploy

See also

  • K3s — self-hosted production K8s
  • AKS — Azure Kubernetes Service
  • GKE — Google Kubernetes Engine
  • EKS — Amazon EKS