🚀 Get Fast & Affordable Hosting with Hostinger – Limited Time Discount!

Last Updated on 2 hours by Sachin G

When I first started exploring Ansible automation, the very first question I stumbled upon was: How does Ansible know which servers to manage? That’s where the concept of an Ansible inventory comes in. If you’ve ever wondered what the “inventory file” in Ansible is and why it’s so important, you’re not alone. Almost every beginner has this moment of confusion.

I still remember when I was setting up my very first Ansible playbook. Everything seemed clear until I had to tell Ansible which servers I wanted it to control. That’s when I realized that the inventory file is not just a “list of servers” — it’s the foundation of Ansible’s entire configuration management system.

In this tutorial, we’ll break down the Ansible basics by focusing on the inventory file. We’ll explore what it is, how it works, how to configure it step by step, and even look at examples of static and dynamic inventories. By the end of this article, you’ll not only understand the structure but also gain confidence to manage your own servers with Ansible.

What is Ansible Inventory?

At its core, the Ansible inventory is simply a file (or a script) that tells Ansible which hosts (servers, devices, or nodes) it should connect to. Think of it as your master contact list for automation.

For example, let’s say you have:

  • Two web servers running Nginx
  • One database server running MySQL
  • One load balancer

Instead of manually SSHing into each machine, you can define them all inside the inventory file. From there, Ansible will know exactly where to run tasks and playbooks.

In short: The inventory file is the backbone of Ansible configuration management, grouping hosts into categories for easy automation.

Types of Ansible Inventory

There are two main types of inventories in Ansible:

1. Static Inventory

This is the most common and beginner-friendly type. It’s usually a simple text file (INI or YAML format) where you manually list servers and groups.

Example (INI format):

[web]
192.168.1.10
192.168.1.11

[db]
192.168.1.20
Example of a static Ansible inventory file in INI format
Screenshot by TechTransit.org: A static inventory file listing web and database servers

2. Dynamic Inventory

As infrastructure grows (think AWS, Azure, or Kubernetes), maintaining static files becomes painful. That’s where dynamic inventories shine. They use scripts or plugins to automatically fetch host information from cloud providers or APIs.

Example (Dynamic AWS plugin in YAML):

plugin: aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: dev
Example of an Ansible dynamic inventory fetching AWS EC2 instances
Screenshot for Using the AWS EC2 plugin for dynamic inventory

When to use what?

  • Static: Great for small labs, testing, or environments with a fixed number of servers.
  • Dynamic: Essential for production-scale environments where servers are created/destroyed frequently.

Step-by-Step: How to Configure an Ansible Inventory File

Here’s a simple guide to configuring your first inventory file.

Step 1: Create the Inventory File

By default, Ansible looks for an inventory file at:

/etc/ansible/hosts

But you can also define a custom inventory file (recommended). For example:

nano ~/my_inventory.ini

Step 2: Add Hosts

Let’s add a few servers:

[web]
192.168.1.10 ansible_user=root
192.168.1.11 ansible_user=ubuntu

[db]
192.168.1.20 ansible_user=admin

Step 3: Test Connection

Run a simple Ansible ping test:

ansible -i my_inventory.ini all -m ping

Expected output:

192.168.1.10 | SUCCESS => { "ping": "pong" }
192.168.1.11 | SUCCESS => { "ping": "pong" }
192.168.1.20 | SUCCESS => { "ping": "pong" }

Pro Tip: If you face SSH issues, ensure your keys are properly copied using ssh-copy-id.

Ansible Groups and Hosts Explained

One of the best features of the inventory hosts file in Ansible is the ability to create groups. Groups allow you to target sets of servers at once.

Group Example:

[frontend]
192.168.1.10
192.168.1.11

[backend]
192.168.1.20

[all_servers:children]
frontend
backend

Here, frontend and backend are groups, and all_servers combines both into a parent group.

Why this matters:

  • Easier to manage 50 servers at once.
  • Cleaner playbooks (just target groups instead of individual IPs).
  • Great for separating environments (e.g., dev, staging, prod).

Pro Tip: If you want to go deeper into Linux/DevOps/automation, I’ve curated a list of Recommended Courses here. They’re structured step-by-step and perfect for learners who want to build real-world skills.

Ansible Inventory in YAML Format

While INI is common, YAML is cleaner and easier for complex setups.

Example YAML inventory:

all:
  hosts:
    web1:
      ansible_host: 192.168.1.10
      ansible_user: ubuntu
    web2:
      ansible_host: 192.168.1.11
      ansible_user: ubuntu
  children:
    db:
      hosts:
        db1:
          ansible_host: 192.168.1.20
          ansible_user: admin

YAML is especially useful when working with Ansible best practices, as it integrates better with playbooks.

Static vs Dynamic Inventory: Which One Should You Use?

Here’s a quick comparison i created :

FeatureStatic InventoryDynamic Inventory
Setup effortLowMedium/High (requires plugin or script)
ScalabilityLimitedExcellent
Best forSmall setups, labs, local testingCloud environments, production clusters
ExampleManual IP listAWS EC2, GCP, Azure, Kubernetes

Best Practice: Start with static inventory for learning. Move to dynamic once you’re managing 10+ servers in the cloud.

Real-World Use Cases of Ansible Inventory

  • Web Hosting Panels: Group servers as web, db, and cache for seamless deployment.
  • DevOps Teams: Separate staging vs production environments in the same inventory file.
  • Cloud Scaling: Use dynamic inventory to automatically track new instances in AWS.
  • CI/CD Pipelines: Trigger Ansible playbooks against specific groups for deployments.

From personal experience, I found grouping hosts into dev, staging, and prod a lifesaver when managing client projects. It eliminated human error and gave me confidence that the right servers were being targeted.

Best Practices for Ansible Inventory

  • Use groups wisely: Avoid cluttering with single hosts; group them logically.
  • Prefer YAML over INI: Especially for larger environments.
  • Keep sensitive data separate: Use ansible-vault for passwords and keys.
  • Use dynamic inventory in cloud: Don’t manually update IPs for ephemeral servers.
  • Document everything: Add comments in your inventory file for clarity.

FAQs about Ansible Inventory

Q1: What is an Ansible inventory file?

It’s a configuration file where you define servers (hosts) that Ansible manages.

Q2: Can I have multiple inventory files?

Yes! You can pass a custom inventory file using -i a flag. Example:

ansible -i my_custom_inventory.ini all -m ping

Q3: What’s the difference between static and dynamic inventory?

Static: Manually listed servers.
Dynamic: Automatically discovered servers via plugins/scripts.

Q4: Which format is better — INI or YAML?

Both work, but YAML is more structured and integrates better with Ansible best practices.

Q5: How do I secure my inventory file?

Don’t store passwords in plain text. Use ansible-vault to encrypt sensitive values.

Understanding the Ansible inventory is like learning the alphabet before writing sentences. Without it, playbooks have no direction. With it, you can scale from managing a couple of test servers to orchestrating entire production clusters.
When I first wrapped my head around the inventory concept, my Ansible journey became much smoother. Suddenly, tasks that seemed complicated — like updating all web servers at once — felt effortless.

So here’s your action plan:

  • Create your first static inventory file.
  • Run a simple ping test.
  • Experiment with groups and YAML format.
  • Once comfortable, explore dynamic inventory for cloud setups.

Happy automating with Ansible!