Ansible Automation Platform 2.7 deletes the RPM installer, and that is the real upgrade cost

Red Hat has shipped Ansible Automation Platform 2.7 with a Model Context Protocol server, an automation intelligent assistant and an automation dashboard ^[1], and the same release completes what the company describes as a multiyear journey to fully containerize the platform ^[2]. The line that will actually consume engineering time sits further down the announcement: the RPM-based installation option has been removed in favor of a container-first strategy for all aspects of the platform ^[3].

For anyone running a package-based install, this is not a version bump. It is a change of installation method and a change of version at the same time ^[8], and Red Hat says so plainly: customers on RPM-based deployments, or on older versions of Ansible Automation Platform or Red Hat Enterprise Linux, will need to make decisions about their future runtime environment, which may involve a migration and a platform shift ^[7].

What the removal does not mean is a forced move to OpenShift. Red Hat states that both virtual machine and OpenShift-based deployments remain supported ^[4], so the container requirement applies to how the platform is installed rather than to where it runs ^[9]. Teams already on OpenShift, an option Red Hat has offered since 2018 ^[5], get the easy path; the company calls upgrading from there straightforward and streamlined ^[6]. That is a vendor characterization, and it is also the least interesting cohort, because the teams Red Hat is aiming at are the ones it says remain several versions behind the newest release, which in its framing limits their ability to scale automation ^[10].

The precedent Red Hat reaches for is instructive. It compares the shift to ansible-core 2.9, when Ansible Content Collections were split out and delivered independently of the core product, a change the company concedes caused initial tension and required automation teams to alter their development processes, but which it argues the ecosystem needed ^[11]. Read that as a forecast of the migration's shape: disruption up front, in exchange for modules and components that release on their own cadence ^[12].

The architectural arguments are the usual ones and are not unreasonable. Containerization lets individual platform features develop, update and scale separately, avoiding a synchronized update across every component of an automation environment ^[12]. Red Hat also claims two organizational benefits: true modularity, meaning you deploy only the components you want ^[13], and a security posture hardened by running natively in rootless containers, which it contrasts with traditional RPM-based installations ^[14].

What to watch is the part the announcement leaves for later. The post is published as Part 1 of a series and says it will help customers navigate the architectural decisions ahead ^[15], which means the specifics that determine cost, such as how existing RPM deployments are converted and what the runtime choice implies for existing playbooks and credentials, are still to come. Until those land, operators several versions behind should treat 2.7 as a scheduled platform project with a migration inside it, not as a patch window, and price the AI features as a secondary benefit rather than the reason for the work.