AWX and Ansible Tower Alternative on an Offshore VPS

Red Hat Ansible Automation Platform charges per-node licensing fees. For a 200-node fleet, the annual cost runs into five figures. AWX is the same codebase under an open-source license, maintained by the Red Hat community. It has the same web UI, the same job templates, the same inventory and credential management, the same schedules, and the same callback workflows. The differences are commercial support and certified content collections - features that most teams running their own infrastructure do not need. Self-hosting AWX on an offshore VPS adds three more wins. First, your inventory stays private. AWX inventories often include every server IP, hostname, environment tag, and sometimes embedded credentials. Pushing that to a vendor cloud is a significant data leak risk. Second, your job artifacts and stdout logs (which routinely contain config snippets, IP addresses, version strings) never cross to a third-party platform. Third, you can integrate AWX with any private git remote, any custom dynamic inventory plugin, and any internal vault without licensing checks. The trade-off is that you operate AWX yourself - upgrades, backups, and monitoring fall on you. The official deployment path uses the AWX Operator on a Kubernetes cluster, so the operational burden compounds with k8s management. The shortcut for small teams is to run AWX on a single VPS using k3s, which gives you a fully featured Kubernetes API on one node with minimal overhead.

AWX has several components - the web frontend, the task scheduler, the rabbitmq message bus, the postgres database, and a redis cache. All of these run as containers in a Kubernetes pod stack. On a single VPS this means a baseline RAM commitment of about 4 GB just to keep the stack idle and healthy. Add 1 to 2 GB more for actually running jobs against your inventory. For a fleet of up to 200 managed nodes with a handful of concurrent job runs, a 6 to 8 GB RAM VPS with 4 vCPU and 80 GB SSD is comfortable. Larger fleets (500+ managed hosts) or heavy concurrency (10+ simultaneous jobs each touching dozens of hosts) want 16 GB RAM and 8 vCPU. The disk is mostly job artifacts and database growth - prune AWX job history with the built-in scheduled cleanup task or expect steady disk growth. Network throughput matters when AWX fans out an SSH job to many hosts simultaneously. AnubizHost 1 Gbps uplinks give you parallel SSH to hundreds of targets without saturation. Iceland or Romania locations are well placed for a globally distributed managed fleet because their transit peering reaches both EU and US-East quickly.

Start with a clean Ubuntu 22.04 VPS, at least 6 GB RAM. Install k3s: `curl -sfL https://get.k3s.io | sh -`. After a few seconds, verify with `kubectl get nodes` - you should see a single Ready node. Set up kubeconfig for your user: `export KUBECONFIG=/etc/rancher/k3s/k3s.yaml`. Install the AWX Operator. Clone the operator repository: `git clone https://github.com/ansible/awx-operator.git && cd awx-operator`. Check out the latest tagged release with `git checkout 2.10.0` (or whatever the current stable tag is). Build and deploy: `export NAMESPACE=awx && make deploy`. This creates the awx namespace and installs the operator CRDs. Write a minimal AWX custom resource at `/root/awx.yaml`: `apiVersion: awx.ansible.com/v1beta1 kind: AWX metadata: name: awx namespace: awx spec: service_type: nodeport nodeport_port: 30080`. Apply with `kubectl apply -f /root/awx.yaml`. The operator now provisions all the pods - this takes 5 to 10 minutes on first install. Watch with `kubectl get pods -n awx -w`. Once all pods report Running, fetch the auto-generated admin password: `kubectl get secret awx-admin-password -n awx -o jsonpath='{.data.password}' | base64 -d`. Access AWX at `http://YOUR_VPS_IP:30080` and put a reverse proxy with TLS termination in front for production use.