# Install ansible with Homebrew

Automate deployment, configuration, and upgrading. Version 14.2.0 via Homebrew; verified 2026-07-15.

## Install

```sh
sudo av install brew:ansible
```

## Agent safety answer

ansible automates hosts and infrastructure from local inventories and credentials.

- **Credential access:** Reads SSH keys, vault files, inventories, cloud credentials, and environment variables.
- **Remote mutation:** Can configure remote hosts, cloud resources, and application deployments.
- **Publish/artifact risk:** Can roll out generated config, binaries, and service changes.
- **Recommended control:** Gate playbook runs, vault decrypts, and inventory changes.
- **Agent-use guidance:** Allow syntax checks and dry runs; require approval for playbook execution against real targets.

Additional install commands:

### macOS

- Homebrew (100%):

```sh
brew install ansible
```

  Evidence: provider-native install command

## Package facts

- **Package key:** brew:ansible
- **Package manager:** Homebrew
- **Version:** 14.2.0
- **Source summary:** Automate deployment, configuration, and upgrading
- **Homepage:** <https://www.ansible.com/>
- **Repository:** <https://github.com/ansible/ansible>
- **Last updated:** 2026-07-15T20:59:48Z
- **Generated:** 2026-08-03T00:40:33+00:00

## Executables

- ansible (alias)
- ansible-community (alias)
- ansible-config (alias)
- ansible-console (alias)
- ansible-doc (alias)
- ansible-galaxy (alias)
- ansible-inventory (alias)
- ansible-playbook (alias)
- ansible-pull (alias)
- ansible-test (alias)
- ansible-vault (alias)

## Install behavior

- Bottle: not available

## Freshness

- Page generated: 2026-08-03
- Package-manager version: 14.2.0
## Project history and usage

Ansible is a radically simple IT automation system for configuration management, application deployment, cloud provisioning, ad hoc task execution, network automation, and orchestration. Its package history matters because the name `ansible` shifted from the original all-in-one project to the modern community package layered on `ansible-core` and collections.

### Project history

Ansible was created as an agentless automation tool whose playbooks describe desired work in YAML and whose default transport avoids installing an agent on managed hosts. The current upstream source for the runtime is the ansible/ansible repository, while official documentation distinguishes the Ansible community package from `ansible-core`.

Red Hat announced an agreement to acquire Ansible in October 2015, framing it as an IT automation and DevOps platform that would complement Red Hat's management portfolio. That acquisition moved Ansible from a startup-backed open source project into Red Hat's broader automation product line while keeping the community project active.

The 2.10 era changed the packaging model. Official release documentation says the Ansible community package uses new versioning starting with 2.10 and then 3.0.0, while `ansible-core` continued the classic 2.x line. The community package includes the language, runtime, and selected collections; `ansible-core` contains the language, runtime, and builtin plugins.

### Adoption history

Ansible's adoption came from a practical systems-administration sweet spot: SSH-first orchestration, readable YAML playbooks, no managed-node daemon, and a large module ecosystem. It spread through Linux distributions, Python packaging, Homebrew, MacPorts, Nix, and enterprise Red Hat channels because it fits both laptop-driven automation and CI/CD infrastructure workflows.

The split into `ansible-core` plus collections made package selection more nuanced. Many community users still install the `ansible` package because it includes broad batteries: official docs say it offers the functionality that existed in Ansible 2.9, with more than 85 collections containing thousands of modules and plugins. Developers and minimalists often choose `ansible-core` and install only the collections they need.

As Ansible matured, adoption expanded beyond server configuration into network automation, cloud provisioning, security, Windows administration, and platform orchestration. Red Hat Ansible Automation Platform, Automation Hub, AWX, Galaxy, and a large collection ecosystem grew around the core CLI model.

### How it is used

The Homebrew `ansible` formula installs the user-facing suite: `ansible`, `ansible-playbook`, `ansible-galaxy`, `ansible-doc`, `ansible-inventory`, `ansible-vault`, `ansible-config`, `ansible-console`, `ansible-pull`, and testing/community helpers. The everyday loop is inventory plus playbooks, with ad hoc commands for quick tasks and Galaxy for roles and collections.

Configuration is resolved from `$ANSIBLE_CONFIG`, `ansible.cfg` in the current directory, `~/.ansible.cfg`, then `/etc/ansible/ansible.cfg`; the first file found wins. Galaxy credentials can be provided through command-line API-key options or through the configured token path, whose default resolves from `ANSIBLE_HOME` to `~/.ansible/galaxy_token`.

Package users care about the distinction between `ansible --version` reporting an ansible-core version and the installed Python package named `ansible` representing the broader community package. That distinction explains why formula pinning, package-manager naming, and docs version matching can feel surprisingly non-obvious.

### Why package nerds care

Ansible is one of the canonical infrastructure CLIs in package-manager culture: big enough to have versioned formulae, distro backports, Python package splits, and plugin/collection dependency concerns, but still shaped like command-line tools that can be scripted and vendored.

The package is also a case study in ecosystem packaging after modularization. `ansible-core` is the runtime center; `ansible` is the batteries-included community package; collections carry much of the domain-specific surface area; and tools like ansible-lint, ansible-creator, and ansible-language-server orbit the authoring workflow.

For users, the important packaging question is not just latest version but content set: does the install include the collections your playbooks expect, what Python versions are supported on control and target nodes, and which ansible-core line is underneath?

### Timeline

- 2013: PyPI release history shows Ansible 1.0.0 published in February 2013.
- 2015: Red Hat announces it will acquire Ansible.
- 2019: Ansible 2.9 is the last pre-collections-style all-in-one community release line.
- 2020: Ansible 2.10 introduces the community package model alongside ansible-base/ansible-core.
- 2021: Ansible 3.0.0 continues the community-package line based on ansible-base 2.10.x.
- 2026: Official docs list Ansible 13.x as current latest and Ansible 14.0.0 as in development.

### Related projects

- ansible-core is the runtime and language core that the `ansible` community package depends on.
- Ansible Galaxy and Automation Hub distribute roles and collections used by ansible-galaxy.
- AWX and Red Hat Ansible Automation Platform provide web UI, RBAC, scheduling, inventory, and enterprise automation around the CLI model.
- ansible-lint, ansible-creator, ansible-navigator, molecule, and Ansible Language Server are common companion tools for authoring and validating content.

### Sources

- <https://docs.ansible.com/projects/ansible/latest/index.html>
- <https://docs.ansible.com/projects/ansible/latest/reference_appendices/config.html>
- <https://docs.ansible.com/projects/ansible/latest/reference_appendices/release_and_maintenance.html>
- <https://github.com/ansible/ansible>
- <https://pypi.org/project/ansible/>
- <https://www.redhat.com/en/about/press-releases/red-hat-acquire-it-automation-and-devops-leader-ansible>


## Security Notes

No matching local secret-handling manifest was found for ansible. Nucleus package metadata is still published here so future coverage has a stable package URL.



## Configuration and credential file locations

These source-backed paths show where this package keeps local settings or durable credentials. Automic Vault can use them as review targets for secret scanning, migration, and command approval.


## Configuration files

- Unix: $ANSIBLE_CONFIG, ./ansible.cfg, ~/.ansible.cfg, /etc/ansible/ansible.cfg

## Credential files

- Unix: ~/.ansible/galaxy_token

## Combined YAML source

View the package source record on GitHub. [combined/ansible.yml](https://github.com/automic-vault/db/blob/main/combined/ansible.yml)


## Sources

- Nucleus package database
- Geiger risk classifier
- curated configuration and credential file locations
- curated package history
- pkgdb category and tag curation
- curated agent safety answer