Certified, community, and the hybrid catalogue.

Ansible certified collections versus community collections is a licensing question dressed as a content question. Both certified and community collections install through the same toolchain, run inside the same execution environments, and target the same managed nodes. The difference is who tested them, who supports them, and what licensing posture each carries. The buyer side reading begins by separating the channel from the content and treating each on its own terms.1

Certified collections are the curated set of Ansible collections that Red Hat has tested against the supported platform releases and ships through the certified content channel. Entitlement to certified collections is included with Ansible Automation Platform. There is no separate per collection line on the order form. The collections appear in the private automation hub, in the Red Hat hosted automation hub, and in the documentation as a single index. Where a collection bears the certified badge, the support coverage attached to the platform agreement extends to the collection.

Community collections are everything else, in the strict sense. They are the broader catalogue of Ansible content published through Ansible Galaxy, contributed by community maintainers, vendor maintainers, and individual operators. They are open source under their own licenses. They are not Red Hat supported by default. They install through the same toolchain and run inside the same execution environments as certified collections. The buyer side licensing question is therefore not the cost of the collection content. It is the cost of the support and the cost of the risk.

For the broader Ansible practice view, see the Ansible Automation Platform practice hub. For the benchmarking that underlies the support coverage observations here, see the benchmarking service hub.

The certified catalogue is a subset of the community catalogue in volume but covers most of the operational territory enterprises actually use. The overlap is therefore high. Where a buyer is running RHEL system roles, common cloud provider modules, common network device modules, or common security tool modules, certified versions of all of those exist. Choosing certified for those domains carries no additional cost.

The overlap thins at the edges. New cloud services launched in the trailing six months may have community collections that the certified channel has not yet incorporated. Niche network devices, niche storage arrays, and specialised hardware sometimes have community collections only. Specialised vertical content, particularly in academic or research domains, lives outside the certified channel by default.

The buyer side reading is therefore that the choice between certified and community is rarely binary at the enterprise level. Most enterprises operate a hybrid catalogue, certified where certified exists and community where it does not, with internal collections layered on top. The licensing question is not which side of the catalogue to choose but how to govern the hybrid. The governance question is operational.

The most consequential difference between certified and community collections, in operational practice, is support coverage on a failed playbook run that pulls in a collection module. When a certified collection's module fails, the playbook stack trace is supportable through the Red Hat support channel under the Ansible Automation Platform agreement. When a community collection's module fails, the failure is supportable only through the community maintainer channel, which may be active and may be effectively dormant depending on the collection.

The cost of this difference is asymmetric across estates. On a stable estate that runs unchanged playbooks against a stable inventory, the support coverage rarely activates. On an estate in active change, integrating new infrastructure or migrating between platforms, the support coverage activates frequently and the difference between certified and community becomes operational.2

The buyer side reading is that support coverage is a real benefit on certified collections and an under utilised benefit on stable estates. Where the estate is stable, the cost of operating community collections in domains where the certified channel exists is mainly the governance cost of maintaining the choice rather than the support cost of executing on the choice.

Community collections carry three risks the certified channel does not. The first is maintenance risk. Community maintainers move on. A collection that was actively maintained two years ago may be dormant today. The reshape is to monitor the upstream activity of every community collection in production use and to budget for forking or replacing dormant collections before they become operationally critical.

The second is supply chain risk. Community collections install through Ansible Galaxy or through Git. The provenance chain for a collection's source code is the upstream maintainer's repository and the chain of contributors to it. Compromise upstream propagates downstream. For estates in regulated industries or with heightened supply chain security requirements, this risk is material and shapes the buyer side reading of the hybrid catalogue toward more certified content.

The third is licensing risk. Community collections carry their own open source licenses. The license of each collection is usually permissive and usually compatible with enterprise use. Usually is not always. Some collections embed dependencies under copyleft licenses that may surface obligations the enterprise had not anticipated. The reshape is a license scan of the community catalogue at the time of inclusion in an execution environment and again on each refresh. This connects to the broader content licensing posture in the UBI redistribution rules note.

The hybrid catalogue that works in operational practice has four components. Each is governance rather than purchase. None changes the Ansible Automation Platform line on the order form.

The first component is the private automation hub as the single internal source of truth for what content is in scope. Every collection, certified or community, enters the operational estate through the hub. The hub is the gate. For the hub licensing context, see the private automation hub licensing note.

The second component is a collection intake process that classifies each candidate as certified, community high confidence, community low confidence, or internal. The classification drives the refresh cadence, the support routing, and the inclusion in execution environments. The classification is reviewed annually.

The third component is the execution environment composition policy that constrains which collections can appear in which execution environments. Production environments may be limited to certified plus community high confidence. Development environments may admit broader content. The policy lives in the execution environment definition files and is enforced at build time. For the deeper EE mechanics, see the execution environments deep dive.

The fourth component is the annual catalogue audit that reviews every collection in active use against its upstream status, its license, and its known vulnerabilities. The audit produces a refresh list and a deprecation list. Deprecated collections are scheduled for removal at the next execution environment refresh cycle.

For estates that are building this governance from scratch, the engagement is normally a focused subscription assessment supplemented by an Ansible specific governance review. To begin, see the contact page. For the validated content sibling that overlaps with parts of this governance question, see the validated content licensing note.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.