Running Ansible Ad-hoc Commands Against Remote Hosts (Without Playbooks)

Sometimes you don’t need a full-blown Ansible playbook. You just want to restart a service, check disk space, or quickly install a package across a few servers. That’s exactly where Ansible ad-hoc commands against remote hosts shine.

They’re fast, direct, and surprisingly powerful once you understand how they work.

A quick example (before the theory)

Let’s say you want to check uptime on all your web servers:

1ansible web -i inventory.ini -m command -a "uptime"

This single line connects to all hosts in the web group and runs the uptime command remotely. No YAML. No playbook. Just execution.

What are Ansible ad-hoc commands?

Ad-hoc commands are one-liners used to perform quick operations on remote machines. Under the hood, they still use Ansible modules, but you invoke them directly from the CLI.

Think of them as:

• Quick fixes
• Exploratory commands
• One-time automation tasks

They’re not meant to replace playbooks, but they’re perfect for rapid execution.

Breaking down the syntax

1ansible <host-pattern> -i <inventory> -m <module> -a "arguments"

Here’s what each part means:

• host-pattern: Target group or host (e.g., web, db, all)
• -i: Inventory file
• -m: Module (like command, shell, yum)
• -a: Arguments passed to the module

Simple, but flexible enough to cover a wide range of tasks.

Common real-world examples

1. Ping all remote hosts

1ansible all -i inventory.ini -m ping

This verifies connectivity and SSH access.

2. Install a package

1ansible web -i inventory.ini -m yum -a "name=nginx state=present" -b

The -b flag enables privilege escalation (sudo).

3. Restart a service

1ansible web -i inventory.ini -m service -a "name=nginx state=restarted" -b

4. Check disk usage

1ansible all -i inventory.ini -m shell -a "df -h"

Notice we used shell here instead of command. That brings us to an important distinction.

Command vs Shell: a subtle but important difference

A common mistake developers make is using shell when command would be safer.

• command: Executes directly, no shell interpretation
• shell: Runs through a shell (supports pipes, redirects, etc.)

Example requiring shell:

1ansible all -m shell -a "cat /var/log/syslog | grep ERROR"

If you don’t need pipes or operators, prefer command for better security and predictability.

Targeting specific hosts

You’re not limited to groups. You can target hosts in multiple ways:

• Single host: ansible server1 -m ping
• Multiple groups: ansible "web:db" -m ping
• Exclude hosts: ansible "all:!db" -m ping

This makes ad-hoc commands very flexible for quick targeting.

Using variables inline

You can pass variables without editing inventory files:

1ansible all -m command -a "echo Hello" -e "ansible_user=ubuntu"

Useful when testing against different environments or credentials.

Parallel execution and performance

By default, Ansible runs tasks in parallel. You can control this using the -f (forks) option:

1ansible all -m ping -f 20

Higher forks = faster execution, but more load on your control node.

When ad-hoc commands start to break down

Ad-hoc commands are great—until they’re not.

Here’s where they struggle:

• Multi-step workflows
• Conditional logic
• Reusability
• Complex orchestration

If you find yourself chaining commands or copy-pasting them repeatedly, that’s your signal to switch to a playbook.

A practical workflow developers actually use

In real projects, ad-hoc commands often complement playbooks rather than replace them:

• Use ad-hoc commands for quick checks and fixes
• Convert repeated tasks into playbooks
• Test modules interactively before formalizing automation

This hybrid approach keeps your workflow fast without sacrificing maintainability.

Gotchas worth knowing

• Quoting matters: Incorrect quotes can break commands silently
• Permissions: Forgetting -b is a common issue
• Inventory mistakes: Wrong host groups lead to confusing results
• Shell overuse: Can introduce security risks

Final thoughts

Ansible ad-hoc commands against remote hosts are one of those features that feel trivial at first—but become indispensable once you start using them daily.

They’re perfect for speed, experimentation, and small operational tasks. Just don’t let them grow into something they weren’t designed for. When things get complex, playbooks are still your best friend.

If you’re working in DevOps or managing infrastructure, mastering these commands can save you a surprising amount of time.