In network automation, you want things to be efficient, right? Managing tons of devices from different vendors takes effective tools, and let's be honest, writing Ansible playbooks from scratch for every single task is a major time drain. That's where Ansible Galaxy comes in, a central place for ready-made automation content from the community and vendors, built to make your job easier and faster.
If you already know the basics of Ansible playbooks, checking out Galaxy is the next logical step to really speed up your network automation. This guide will walk you through what Galaxy gives you, how to use its roles and collections, and how CloudMyLab fits into your practice.
Before you pull down a single role, here is how the three places you can host Ansible content compare on cost, support, and what they are actually built for.
| Hub | Cost | Who Maintains It | Content Type | Best For |
Ansible Galaxy (galaxy.ansible.com) |
Free | Community + vendors | Roles and collections, mixed quality | Learning, OSS projects, individual engineers |
| Red Hat Automation Hub | Bundled with AAP subscription | Red Hat (certified) | Certified collections only | Enterprise teams that need vendor support |
Private Galaxy server (galaxy_ng) |
Self-hosted infrastructure | You | Internal roles and collections | Air-gapped networks, regulated environments, internal-only modules |
Galaxy is the right starting point for almost everyone. It is free, it has the widest selection, and the official vendor collections you actually need (cisco.ios, arista.eos, junipernetworks.junos) are published there. The catch is quality. Some roles are abandoned. Some collections drift behind their upstream modules. There is no SLA when something breaks at 2 a.m.
If you are running Ansible at scale and need a production safety net, CloudMyLab's hosted Ansible automation lab gives you a sandbox to test new Galaxy collections against virtual Cisco, Juniper, and Arista devices before you let them touch production. That is the gap most teams need to fill — Galaxy gives you the content, but you still need a safe place to validate it. For a deeper comparison of how the open-source CLI stacks up against the paid platform, see Ansible CLI vs Ansible Automation Platform.
Ansible Galaxy serves as a central repository for Ansible content. It contains:
This stuff is built and kept up-to-date by the community – individual engineers, the core Ansible team at Red Hat, and network vendors like Cisco, Juniper, and Arista. For network engineers like you, Galaxy is a library of proven automation you can reuse instead of building common tasks from zero.
You've probably run a show run playbook before—but what if you need to automate complex tasks like:
Writing these from scratch can be tedious. Instead, you can reuse roles and collections from Galaxy that others (including Cisco!) have already tested and published.
Read more: Depending on your environment’s size, you can run these tasks using the Ansible CLI for simplicity or the Ansible Automation Platform for enterprise-scale management. Learn the differences in this Ansible CLI vs Ansible Automation Platform comparison.
A role is a neatly packaged set of automation tasks, structured for reusability. It includes:
tasks/main.yml) showing the automation steps.defaults/main.yml for defaults and vars/main.yml for role-specific variables).templates/ directory) using Jinja2 to generate configuration files.handlers/main.yml) that run when notified, often for things like restarting services.files/ directory) to be copied to devices.meta/main.yml) about the role, who made it, and if it needs other roles.Roles make things modular, keeping your playbooks cleaner and easier to handle by putting complex bits into reusable packages.
You want to configure NTP on 500 Cisco routers. You can use a role like:
ansible-galaxy install network-ntp
Then in your playbook:
- hosts: cisco_routers roles: - cisco_ios_vlan
Note: cisco_ios_vlan is a sample name
Ansible Collections are the newer, standard way to package Ansible content (started with Ansible 2.9). They're bigger than roles – a single collection can have multiple roles, custom modules (like vendor-specific ones for device APIs), plugins (for things like inventory or connections), and docs.
Collections use a <namespace>.<collection_name> format (like cisco.ios or junipernetworks.junos). This helps avoid naming clashes and tells you who made or maintains the content. Collections make it easier to share full, integrated automation solutions from vendors and the community.
Example:
ansible-galaxy collection install cisco.ios
Installing cisco.ios gets you modules like cisco.ios.ios_config, cisco.ios.ios_command, cisco.ios.ios_facts, plus any roles or plugins included in that collection.
Read more: To ensure these collections run consistently across different systems, use Ansible Execution Environments, which package dependencies into containers. Explore Understanding Ansible Execution Environments for setup and benefits.
| Feature | Role | Collection |
| Format introduced | Ansible 1.x | Ansible 2.9 |
| Contains tasks | Yes | Yes (inside roles) |
| Contains modules | No | Yes |
| Contains plugins | No | Yes |
| Namespaced | No (URL-based) | Yes (namespace.name) |
| FQCN reference | No | Yes (namespace.collection.module) |
| Distributed via | Galaxy, Git URL, archive | Galaxy, Automation Hub, archive |
| Active development | Maintenance only | Yes |
Roles are tactical, collections are strategic. Together, they let you automate everything from one-off tweaks to enterprise-wide deployments while following community best practices.
Using them effectively helps you out in several ways:
A namespace in Ansible Galaxy is a unique name (usually for an organization, vendor, or person) that groups related content, specifically collections.
Examples of Popular Namespaces:
cisco, arista, junipernetworks (or juniper): Vendor-specific content.ansible: Content from the core Ansible team (like ansible.netcommon).community: Content maintained by the wider community (like community.general).ansible-galaxy collection list
Read more: For an enhanced CLI experience when managing Galaxy content, try Ansible Navigator, a tool for running and debugging Ansible tasks. Learn more in our Ansible Navigator guide.
Install a single role (using a namespace is best practice now):
ansible-galaxy install .
Roles usually land in ~/.ansible/roles. You can check or change this path in your ansible.cfg file using the roles_path setting:
[defaults] roles_path = ~/.ansible/roles:/etc/ansible/roles:/opt/custom_roles
To see what roles are installed on your system:
ansible-galaxy role list
For air-gapped or offline environments, you can download a collection archive without installing it, copy the .tar.gz to your target host, and install it from disk:
ansible-galaxy collection download cisco.ios
ansible-galaxy collection install cisco-ios-5.3.0.tar.gzThis pattern is essential for regulated networks where the Ansible control node has no outbound internet access. For a fuller treatment of execution environments and how to bundle collections into reproducible containers, see Ansible Execution Environment.
As described earlier, you may install collections using ansible-galaxy collection install:
ansible-galaxy collection install cisco.ios
You can grab a collection archive (.tar.gz) without installing it right away, which is handy for offline setups:
ansible-galaxy collection download cisco.ios
Then, install the downloaded file later:
ansible-galaxy collection install cisco.ios-*.tar.gz
To list installed collections (and see their versions and where they are):
ansible-galaxy collection list
Collections usually go into ~/.ansible/collections/ansible_collections/<namespace>/<collection_name> or in a project's collections/ directory if you use a requirements.yml file.
To remove a collection:
ansible-galaxy collection remove cisco.ios
Note that older Ansible versions did not support uninstall for collections. If the command fails, check your ansible-core version. On anything from 2.10 onward it works.
requirements.ymlInstalling collections one at a time on the command line is fine for tinkering. For any project that lives longer than a weekend, you want a requirements.yml file that lists every dependency, pins versions, and gets committed to Git. Without it, you are one upstream release away from a broken pipeline.
A minimal requirements.yml looks like this:
---
collections:
- name: cisco.ios
version: "5.3.0"
- name: cisco.nxos
version: ">=5.0.0,<6.0.0"
- name: ansible.netcommon
version: "6.1.0"
- name: community.general
version: ">=8.0.0"
roles:
- name: geerlingguy.docker
version: "7.0.0"
- src: https://github.com/your-org/ansible-role-internal-baseline
name: internal_baseline
version: "v1.4.2"
scm: gitTo install everything in the file:
ansible-galaxy install -r requirements.ymlThat command handles both collections and roles in one pass. If you only want to install collections (for example, in a CI step that does not need roles), use the explicit form:
ansible-galaxy collection install -r requirements.yml
ansible-galaxy role install -r requirements.ymlA few practical rules for requirements.yml that save you from real production incidents:
>=5.0.0) work until a vendor ships a breaking change in a minor release — which happens more often than you would expect. Pin to exact versions for anything production-adjacent.requirements.txt for Python or package.json for Node.-p ./collections or set collections_path so dependencies stop leaking across projects.For network teams running Ansible against live infrastructure, the wrong place to discover that cisco.ios 6.0 changed the default for save_when is during a Friday afternoon change window. Pin, test in a sandbox, then merge.
Read more: How you write and structure your Ansible playbooks totally impacts how well they scale. Read our article on the best practices for Ansible playbooks.
Let's set up NTP servers on devices in your cisco_routers inventory group using modules from the cisco.ios collection.
Playbook configure_ntp.yml:
---
- name: Configure NTP on Cisco routers
hosts: cisco_routers
gather_facts: false
collections: # Tell Ansible which collections this playbook uses
- cisco.ios
tasks:
- name: Set NTP server configuration
cisco.ios.ios_config: # Use the Full Collection Name (FQCN) for the module
lines:
- ntp server 192.168.1.10
- ntp server 192.168.1.11
save_when: modified
This playbook uses the ios_config module to push NTP settings and saves the config if changes are made. Done in minutes, not hours.
ansible-galaxy ErrorsMost Galaxy issues fall into a handful of categories. Here is what tends to go wrong and how to fix it without burning a Saturday.
The collection name is wrong, the version pin does not match anything published, or the registry you are pointing at does not have the collection. Check what is actually available:
ansible-galaxy collection list cisco.iosIf you are using a private server, make sure ~/.ansible/galaxy_token or your ansible.cfg [galaxy] section is configured for the right URL.
The collection installed, but Ansible cannot find a module from it. Almost always this is a Fully Qualified Collection Name (FQCN) issue. Old playbooks reference ios_config directly. Modern playbooks should reference cisco.ios.ios_config:
tasks:
- name: Push NTP config
cisco.ios.ios_config:
lines:
- ntp server 192.168.1.10
- ntp server 192.168.1.11
save_when: modifiedThe collections: keyword at the play level used to let you skip the FQCN, but FQCN is the recommended style going forward. Use it everywhere and you avoid this class of problem entirely.
You have the same collection installed in two paths, usually ~/.ansible/collections/ and a project-local ./collections/. List everything to confirm:
ansible-galaxy collection listThen remove the one you do not want, or set collections_path in ansible.cfg so only one path is searched.
The playbook references a role by short name, but the role is installed under a different name. Roles installed from a Git URL pick up the repository name, not the role name. Either install with --role-name:
ansible-galaxy role install git+https://github.com/your-org/ansible-role-baseline.git --role-name internal_baselineOr set the name explicitly in requirements.yml:
roles:
- src: https://github.com/your-org/ansible-role-baseline
name: internal_baselinegalaxy.ansible.comBehind a corporate proxy, ansible-galaxy does not always pick up your environment proxy variables. Set them explicitly:
export https_proxy=http://proxy.example.com:3128
ansible-galaxy collection install cisco.iosFor air-gapped environments where there is no path to public Galaxy at all, download collections on a host that does have access, copy the archives across, and install from local files. For deeper performance and execution debugging, Optimize Ansible Performance covers strategies that apply once your collections install cleanly.
Sharing your useful automation helps the community. Here's how:
Create Role in VS Code
ansible-galaxy init my_custom_role
Create a GitHub Repository - Name it like: ansible-role-my_custom_role
Push Role to GitHub - Push your role files to GitHub, including a meta/main.yml with basic info.
Create a Galaxy Account - Create an Ansible Galaxy account if you don't have one.
Link Your GitHub Account - Go to your Galaxy Settings → GitHub Integration, and then authorize access to your GitHub repositories.
Import Your Role - Import your role from GitHub via "My Content" -> "Add Content". Your role becomes available on Galaxy. It'll be listed under your namespace like
my_namespace.my_custom_role
To Install Your Role - Others can install it using:
ansible-galaxy install my_namespace.my_custom_role
While custom Python scripts (using libraries like Netmiko or NAPALM) offer detailed control, and vendor-specific tools (like Cisco DNA Center, Arista CloudVision) provide integrated experiences within their ecosystems, Ansible Galaxy offers advantages for scalable and standardized multi-vendor automation:
Galaxy content is often designed and tested for large environments, enabling consistent management of many devices. This scale is hard to achieve reliably with custom scripts without significant engineering. Using community or vendor content encourages using established automation patterns, making your work more maintainable. Galaxy benefits from the collective knowledge of thousands of engineers and direct vendor contributions, providing access to ongoing maintenance and support through collection maintainers. It excels in multi-vendor environments. A single Ansible control node with collections like cisco.ios and junipernetworks.junos can orchestrate changes across a heterogeneous network within one workflow, which is difficult with separate vendor tools.
While Python scripting offers flexibility and vendor tools deep integration, Ansible Galaxy provides a balance with reusable, standardized, community-supported content ideal for scaling network automation across diverse environments efficiently.
The right Galaxy setup depends on your team size, your compliance environment, and whether you are running Ansible against production. Here is a decision matrix that maps team profiles to the setup that matches.
| If you are... | Recommended setup |
| Learning Ansible solo or studying for an Ansible cert | Public Galaxy, no requirements.yml yet, install ad-hoc |
| Running Ansible against a homelab or non-production | Public Galaxy + project-local requirements.yml with pinned versions |
| Running Ansible against production at a small/mid team | Public Galaxy + requirements.yml + a CI step that installs and tests against a sandbox |
| Running Ansible at an enterprise with compliance requirements | Automation Hub for certified vendor collections + private galaxy_ng for internal modules |
| Operating in a fully air-gapped network | Private galaxy_ng mirroring required collections + offline .tar.gz workflow |
| Training a team of 20+ engineers | Hosted lab platform pre-loaded with the collections you teach against |
The most common mistake is using Galaxy without a requirements.yml. Engineers install collections on their laptops, push playbooks to Git that run cleanly locally, and the CI runner (or a teammate on a different machine) has a different version installed and gets a different result. Pinning versions in a committed file fixes that, for free, in five minutes.
The second most common mistake is testing new Galaxy content directly against production. A community collection can be perfectly fine on the version you originally tried, then ship a new module default in the next release that quietly changes behavior on your gear. Test in a sandbox first — every time. CloudMyLab's hosted Ansible automation lab gives you a pre-built environment to validate new collections against virtual Cisco, Juniper, and Arista devices before they touch your real network. For broader context on where automation labs fit into a network engineer's day, see Network Automation Proofs of Concept and Cloud-Based Training Labs.
If your time is worth more than the subscription, or you already know you want a place to test Galaxy content safely without rebuilding it locally, start a CloudMyLab free trial and skip the lab setup. For the broader picture of why network automation matters and how Galaxy fits into it, see Network Automation: Critical for IT.
Learning Resources
It's a website and command-line tool (ansible-galaxy) for finding, sharing, and managing reusable Ansible content, primarily roles and collections.
A role is a standardized way to structure automation for a specific task or component. A collection is a broader package that can contain multiple roles, modules, plugins, and documentation, often used to distribute content from a specific vendor or community. Collections are the newer standard.
The roles usually go into ~/.ansible/roles/. Check or change the path in ansible.cfg using roles_path.
The collections typically land in ~/.ansible/collections/ansible_collections/. Use ansible-galaxy collection list to confirm the exact paths on your system.
Use the ansible-galaxy install command for roles (ansible-galaxy install <namespace>.<role_name>) or collections (ansible-galaxy collection install <namespace>.<collection_name>). You can also install multiple dependencies using a requirements.yml file (ansible-galaxy install -r requirements.yml).
You need internet access to install content from https://galaxy.ansible.com/ . Once installed, you can use the content locally. For air-gapped environments, you can download collection archives first and install them offline.
Yes, many collections are vendor-specific (like cisco.ios, junipernetworks.junos, arista.eos), allowing you to use modules and roles tailored for those devices. Other collections like ansible.netcommon provide modules that work across multiple vendors.
You need to structure your automation as a role or collection, store it in a public GitHub repository, and then import it into your Ansible Galaxy account.
requirements.yml and why do I need it?requirements.yml is a YAML file that lists every collection and role your project depends on, along with pinned versions and source URLs. You commit it to Git so that any teammate or CI runner can reproduce your exact dependency set with one command (ansible-galaxy install -r requirements.yml). Without a requirements.yml, every install is a moving target and your playbooks are one upstream release away from breaking.
Ansible Galaxy at galaxy.ansible.com is free and open, hosting community and vendor content with no quality gate. Automation Hub is part of Red Hat Ansible Automation Platform, contains only Red Hat-certified collections, and comes with a vendor support contract. Most teams start on public Galaxy and adopt Automation Hub when they need certified content under support. The two can coexist in the same requirements.yml.
Yes. The open-source galaxy_ng server is the same software that powers public Galaxy and Automation Hub, and you can self-host it inside your network. Teams use private Galaxy servers for three reasons: hosting internal-only collections that cannot leave the network, operating in air-gapped environments with no path to galaxy.ansible.com, or proxying public collections internally for compliance reasons.