Managing a handful of VPS instances by hand \u2014 SSHing into each one to install packages, push config files, and run updates \u2014 works until the fleet grows past three or four boxes. Then every change becomes a sequence of copy-paste sessions, and drift creeps in: one server runs Nginx 1.24, another 1.26, and nobody remembers which one has the patched sshd config. Ansible solves this by describing the desired state of every server in plain YAML files and applying them over SSH, with no agent installed on the targets. This guide covers the practical core: inventory, ad-hoc commands, playbooks, and automating security maintenance.<\/p>\n\n\n\n
Ansible is agentless \u2014 it connects to each host over SSH, executes tasks, and disconnects. That makes it a natural fit for VPS fleets, because there is no separate daemon to keep updated and no open management port beyond the SSH you already hardened. If you are still deciding where to run your fleet, our comparison table<\/a> helps you shortlist providers with consistent CPU and network specs, which keeps playbook performance predictable across nodes.<\/p>\n\n\n\n Install Ansible on any machine that can reach your servers \u2014 a laptop or a small admin VPS both work. The inventory is a simple INI or YAML file listing your hosts and their variables:<\/p>\n\n\n\n Verify connectivity across the fleet in one shot:<\/p>\n\n\n\n The last command updates and upgrades every host in the inventory with a single invocation \u2014 the fastest way to close a security patch window across ten servers. Add A playbook is a list of plays, each targeting a group of hosts. This one installs the base packages, configures the firewall, and locks down SSH across the fleet \u2014 the same steps you would otherwise repeat manually on every box:<\/p>\n\n\n\n Two concepts make this playbook reusable. First, Hardcoding passwords or API keys in playbooks is how credentials leak into git history. Use Variables can be scoped per group, per host, or per file. Put generic values in Security is a recurring job, not a one-time setup. Run your update and audit playbooks on a schedule with a cron entry on the control node (or a systemd timer for tighter control):<\/p>\n\n\n\n Combine this with a playbook that greps for failed SSH logins and unauthorized listening ports, and you have a lightweight compliance loop: the same tool that provisions the fleet also audits it. For larger teams, AWX or Semaphore adds a web UI and job history on top of the same playbooks, but the CLI + cron approach keeps a small fleet fully automated with zero extra infrastructure.<\/p>\n\n\n\n Start with one hardening playbook, extend it to deploy application configs, and you will never manually configure a server again. If you are standing up a new fleet and want providers that behave identically across nodes, see the full specs and pricing<\/a> before you commit.<\/p>\n\n\n\nSetting Up the Control Node and Inventory<\/h2>\n\n\n\n
# \/etc\/ansible\/hosts (INI format)\n[web]\nweb1 ansible_host=10.0.0.11\nweb2 ansible_host=10.0.0.12\n\n[db]\ndb1 ansible_host=10.0.0.21\n\n[web:vars]\nansible_user=deploy\nansible_ssh_private_key_file=~\/.ssh\/vps_ed25519<\/code><\/pre>\n\n\n\nansible all -m ping\nansible web -a \"uptime\" # run any command\nansible all -m apt -a \"update_cache=true upgrade=dist\" -b<\/code><\/pre>\n\n\n\n--check<\/code> to any playbook run to preview changes without applying them.<\/p>\n\n\n\nYour First Playbook: Base Security Hardening<\/h2>\n\n\n\n
---\n- name: Base hardening for all VPS hosts\n hosts: all\n become: true\n vars:\n ssh_port: 22\n tasks:\n - name: Install essential packages\n apt:\n name: [\"ufw\", \"fail2ban\", \"ntp\", \"curl\"]\n state: present\n update_cache: true\n\n - name: Allow SSH and web traffic\n ufw:\n rule: allow\n port: \"{{ ssh_port }}\"\n proto: tcp\n\n - name: Enable firewall\n ufw:\n state: enabled\n\n - name: Disable root SSH login\n lineinfile:\n path: \/etc\/ssh\/sshd_config\n regexp: \"^PermitRootLogin\"\n line: \"PermitRootLogin no\"\n notify: restart ssh\n\n handlers:\n - name: restart ssh\n systemd:\n name: ssh\n state: restarted<\/code><\/pre>\n\n\n\nnotify<\/code>\/handlers<\/code>: the SSH restart runs only when the config actually changed, so most runs are no-ops. Second, idempotency: every task describes a desired state, and re-running the playbook produces no duplicate changes. Run it with ansible-playbook hardening.yml<\/code>, then ansible-playbook hardening.yml --check<\/code> on a new host before adding it to the fleet. When you only need to touch a subset \u2014 say, re-run the firewall task on the web group \u2014 add tags: [firewall]<\/code> to the relevant tasks and invoke with ansible-playbook hardening.yml --tags firewall --limit web<\/code>. The --limit<\/code> flag also lets you test a brand-new server in isolation (--limit web3<\/code>) before it joins the full run.<\/p>\n\n\n\nSecrets, Variables, and Group-Specific Config<\/h2>\n\n\n\n
ansible-vault<\/code> to encrypt sensitive files:<\/p>\n\n\n\nansible-vault create group_vars\/all\/vault.yml # store secrets\nansible-vault encrypt group_vars\/all\/vault.yml # encrypt existing\nansible-playbook hardening.yml --ask-vault-pass # prompt at runtime<\/code><\/pre>\n\n\n\ngroup_vars\/all\/<\/code>, web-specific ones in group_vars\/web\/<\/code>, and per-server overrides in host_vars\/web1.yml<\/code>. This is what keeps one playbook correct for a fleet where every node is slightly different.<\/p>\n\n\n\nScheduling Maintenance Runs<\/h2>\n\n\n\n
# every Sunday at 03:00, apply updates and log the result\n0 3 * * 0 \/usr\/local\/bin\/ansible-playbook \/opt\/ansible\/updates.yml \\\n --vault-password-file \/etc\/ansible\/.vault_pass >> \/var\/log\/ansible-updates.log 2>&1<\/code><\/pre>\n\n\n\n