Running AWX on MicroK8s: What a Small Automation Platform Still Requires

Historical field note: The example output below reflects an AWX Operator lab deployment from 2023. Pin and validate current component versions against the AWX Operator documentation before reproducing it.

AWX turns a collection of Ansible playbooks into an operating service: centralized inventories, credentials, schedules, job templates, access controls, and execution history. That is useful in a home lab, but it also changes the responsibility model. Once other people or critical jobs depend on it, the controller itself needs lifecycle management.

I used MicroK8s to explore that boundary in a compact environment. Getting the pods to run was the beginning; the useful work was learning what the platform would require from its operator afterward.

Decide what this deployment is for

Before installation, define the boundary:

• Is this an isolated lab, a shared engineering service, or production automation?
• Which credentials will AWX hold, and how will they be rotated?
• Where will PostgreSQL data and the AWX secret key be backed up?
• Who can launch privileged jobs or change inventories?
• How will the platform be patched without breaking the automation it controls?

MicroK8s is a reasonable learning and small-environment choice. It is not a substitute for availability, recovery, and support requirements that belong in an enterprise design.

Prepare the cluster

AWX is not a lightweight single-container utility. Give the cluster enough CPU, memory, and storage headroom for the operator, web and task services, PostgreSQL, and upgrade surges.

Enable the MicroK8s services the deployment needs:

microk8s status --wait-ready
microk8s enable dns hostpath-storage ingress rbac helm

hostpath-storage is convenient for a single-node lab. Its failure characteristics should be understood before treating the data as durable.

Install a pinned operator

The AWX Operator manages the lifecycle of the AWX custom resource. The community Helm chart can install that operator, but the version should be explicit and reviewed rather than silently following latest.

microk8s helm repo add awx-operator \
  https://ansible-community.github.io/awx-operator-helm/
microk8s helm repo update
microk8s helm search repo awx-operator/awx-operator --versions

microk8s helm install awx-operator awx-operator/awx-operator \
  --namespace awx \
  --create-namespace \
  --version <reviewed-chart-version>

Confirm the operator is healthy before creating an AWX instance:

microk8s kubectl get pods --namespace awx
microk8s kubectl logs \
  --namespace awx \
  deployment/awx-operator-controller-manager \
  --container awx-manager

Create the AWX resource

For a lab, a minimal custom resource can expose AWX through a NodePort:

---
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx
  namespace: awx
spec:
  service_type: nodeport

Apply it and watch the reconciliation:

microk8s kubectl apply --filename awx.yaml
microk8s kubectl get pods --namespace awx --watch

The exact pod count is version-dependent. Readiness, stable restarts, persistent storage, and successful operator reconciliation are better checks than expecting a fixed number.

Retrieve the generated administrator password only from a protected terminal:

microk8s kubectl get secret awx-admin-password \
  --namespace awx \
  --output jsonpath='{.data.password}' \
  | base64 --decode
printf '\n'

Rotate or replace bootstrap credentials, restrict network access, configure trusted TLS, and create named accounts with least privilege before adding sensitive inventories.

Lessons learned after installation

A successful login proves that deployment worked. It does not prove that the service is ready to own automation.

Before relying on it, test:

• Backup and restore of the database and required secrets
• Recovery after a node reboot
• Credential access boundaries between teams and job templates
• A controlled operator and AWX upgrade
• Job isolation, logging, notification, and failure handling
• How a compromised playbook or project source would be contained

The first successful login felt like a milestone, but it only proved that Kubernetes had created the service. It said nothing about credential protection, recovery, or whether I could change the platform without losing the automation now depending on it.

Before other work relies on AWX, put names against identity, state, upgrades, and recovery. Restore the database and required secrets, reboot the node, review privileges, and launch a representative job as a non-administrator. The AWX upgrade runbook continues from there, because the operator’s reconciliation loop is not a rollback plan.

Sources and disclosures

• AWX Operator documentation
• AWX Operator Helm chart
• MicroK8s hostpath storage add-on

This is a historical lab implementation, not a current production reference architecture. It is not affiliated with or endorsed by Ansible, Canonical, or their maintainers. Revalidate component versions, storage behavior, exposure, identity controls, and recovery for the intended environment.