Making homelab automation repeatable
Personal infrastructure work that separates automation content from its execution platform so tasks can be reviewed, validated and repeated.
Category: Personal homelab
Status: Personal homelab project
The problem
Ad hoc infrastructure commands are hard to review and repeat. A personal lab also needs a clear boundary between the service running automation and the playbooks changing machines.
The approach
Keep AWX platform configuration separate from Ansible content and declarative job configuration, with explicit validation and reconciliation paths.
Implementation
One repository defines the AWX platform on K3s using the AWX Operator and Kustomize. A separate repository holds Ansible playbooks, roles and declarative AWX job configuration. Platform installation and task content have distinct ownership.
The automation content includes connection/fact-gathering jobs, Linux maintenance and disposable virtual-machine provisioning/removal workflows. Its lifecycle documentation covers provision-to-removal work rather than treating creation alone as completion.
Inventories, templates and credential types are declared in source, while sensitive credential values stay outside Git. Project and credential synchronization use deliberate opt-in configuration.
Current state and limits
Configuration and playbook syntax can be validated without contacting AWX or target hosts. The repositories define CI and reconciliation paths; those definitions alone do not establish that every path is active in the live lab.
This is personal infrastructure work rather than a client engagement. The exact controller configuration and enabled tasks require a current operational review before a live-operation claim is published.
What this demonstrates
Repeatable automation depends on scope and ownership as well as playbook syntax. Separating platform configuration, task content and credentials gives operators a clearer account of what a job may change.
Topics: Ansible, AWX, K3s, Kustomize, Linux, Hyper-V