Ansible Tower Is Now Automation Controller: Architecture, Setup, and Licensing

Ansible Tower is now a legacy product name. In Red Hat Ansible Automation Platform, the enterprise control layer that replaced Tower is called automation controller. The change is more than branding: the modern platform separates control and execution, uses containerized execution environments, and can distribute automation through automation mesh.

If you are learning from an older Tower tutorial, the core ideas still transfer—projects, inventories, credentials, job templates, schedules, role-based access, and centralized execution—but the architecture and deployment model have moved forward.

A configuration-management model gives Ansible its strongest foundation because automation should express a desired, repeatable state rather than a one-off sequence of manual commands.

What automation controller actually does

Automation controller gives teams a central place to run, schedule, delegate, audit, and monitor Ansible automation. Instead of every administrator keeping private playbooks and SSH keys on a laptop, the organization can define shared automation with controlled credentials and repeatable execution.

Typical controller responsibilities include managing inventories, projects, credentials, job templates, workflows, schedules, notifications, permissions, and execution history.

The controller is not the automation logic itself. The automation logic still lives in playbooks, roles, collections, and related content. Controller provides the operational system around that content.

Why Tower was replaced

Older Tower deployments concentrated more responsibilities inside a comparatively monolithic architecture. Red Hat’s current automation controller uses separate control and execution layers so that the platform can scale automation more flexibly across data centers, cloud environments, and edge locations.

That separation matters when hundreds or thousands of jobs need to run without turning the central web/API tier into the execution bottleneck.

Control plane and execution plane solve different problems

The control plane handles orchestration, API requests, scheduling, job coordination, access control, and the web interface.

The execution plane runs the automation work.

Keeping those concerns separate makes it easier to add execution capacity where the managed systems actually live. A team can place execution nodes closer to a restricted network or remote site while retaining centralized governance.

Execution environments replace “works on my Python environment”

Modern Ansible Automation Platform runs jobs inside execution environments—container images that package Ansible Core, collections, Python dependencies, and system libraries together.

This solves a common automation problem: a playbook works on one administrator’s machine because that machine happens to contain the right library versions, but fails on another host.

An execution environment makes dependencies part of the automation artifact. Teams can version, test, publish, and promote the environment alongside the playbooks that depend on it.

This is closely related to the wider infrastructure-as-code discipline: repeatability depends on controlling both the desired configuration and the environment that executes it.

Automation mesh distributes jobs without decentralizing governance

Automation mesh allows the platform to route work across execution nodes while maintaining centralized control.

Imagine a company with a primary data center, two cloud environments, and several restricted regional networks. Opening broad inbound management access from one central controller may be undesirable. Distributed execution allows automation capacity to be positioned closer to those networks while the organization still manages jobs, credentials, and access centrally.

Start installation by designing the topology

Do not begin by copying an installation command from an old Tower blog post. First decide what the deployment needs to support.

Ask:

How many concurrent jobs are expected?

Where are managed systems located?

Which networks have restricted connectivity?

What high-availability expectations exist?

Where will execution-environment images be stored?

Which teams require separate organizations, inventories, or credentials?

How will backups, upgrades, and disaster recovery be handled?

The answers determine the deployment pattern much more reliably than the size of a previous Tower server.

Projects connect controller to source-controlled automation

A project typically represents automation content synchronized from source control.

That means Git should be the normal system of record for playbooks and related code. Changes can then move through review, testing, and approval before controller executes them.

The DevOps engineering workflow matters here because enterprise automation should be treated as software: version it, review it, test it, and make changes traceable.

Inventories describe what automation can target

Inventories define hosts and groups. They may be maintained statically or populated dynamically from cloud and infrastructure sources.

Good inventory design reflects operational boundaries. Group hosts by meaningful attributes such as environment, location, platform, application, or lifecycle—not merely by whatever naming convention happens to exist.

Keep secrets out of inventory variables. Inventory should describe systems; credentials should be managed through dedicated credential objects and protected secret stores.

Credentials should be delegated, not copied

One of controller’s strongest operational benefits is credential abstraction.

A user can be permitted to run an approved job without being given the underlying SSH private key, cloud secret, or API token. This supports least privilege and reduces the spread of long-lived credentials.

Design permissions around what a person needs to execute, administer, or approve rather than making every automation user a platform administrator.

Job templates turn playbooks into controlled operations

A playbook says what Ansible can do. A job template defines how the organization allows that playbook to be run.

The template can bind together a project, playbook, inventory, credentials, execution environment, variables, limits, tags, and survey inputs.

This creates a reusable operation such as “patch development Linux servers,” “rotate a service certificate,” or “validate network configuration” without requiring the operator to assemble the command manually each time.

Workflows coordinate multi-step automation

Real operations often need more than one job.

A deployment workflow might validate prerequisites, create infrastructure, configure the operating system, deploy an application, run a health check, and trigger rollback or notification if one stage fails.

Workflow templates let teams represent those dependencies explicitly. They are particularly valuable when approval or different credentials are required at different stages.

Surveys make self-service safer

Surveys expose selected variables through a form when a job starts. They are useful when an operator should choose a controlled value—such as an environment, application version, or change ticket—without editing YAML.

Do not expose every playbook variable. A good survey narrows choices and validates input so self-service does not become arbitrary code execution.

Schedules should automate routine work, not hide ownership

Controller can schedule jobs such as compliance checks, configuration validation, certificate rotation, or maintenance tasks.

Scheduled automation still needs an owner. Someone should know what the job changes, what happens if it fails, and which alert proves that it ran successfully.

The observability model applies to automation as well: a scheduled job that silently stops running is an operational failure.

Use notifications selectively

Notifications can route job status to collaboration, email, or incident systems. Sending every successful job to a shared channel usually creates noise.

Notify people when action is required: repeated failures, production changes, approval events, or jobs tied to important operational controls.

Build role-based access around organizations and teams

Enterprise automation platforms quickly become shared infrastructure. Separate content ownership, platform administration, and job execution.

A network team may own network automation while a Linux team owns operating-system automation. Developers might be allowed to launch an application deployment but not view the production credential behind it.

This is where centralized automation becomes more valuable than personal scripts: the platform preserves governance while still enabling self-service.

Test idempotency before scaling a playbook

Controller makes it easy to run automation at scale, which also makes mistakes scale faster.

A playbook should normally be safe to run repeatedly without producing unintended change. The broader concepts of idempotency and drift control should be tested in a limited environment before a template is delegated widely. Pair that with disciplined automation scripting so operational logic remains readable and reviewable.

Use development, test, and production promotion

Do not edit production playbooks directly in the controller interface and hope change history remains clear.

Use source control and a promotion process. Test the playbook and execution environment in a non-production context, review the change, and then update the production project reference deliberately.

Pricing is subscription-based, not a single Tower license

Older articles often list a fixed “Ansible Tower price.” That framing is outdated.

Red Hat Ansible Automation Platform is sold through subscriptions whose cost depends on the platform edition, managed-node scope, support, deployment requirements, and commercial agreement. Red Hat does not present one universal public price that applies to every enterprise deployment.

For budgeting, define the number of managed systems, required capabilities, support level, topology, and growth expectations, then request current Red Hat or authorized-partner pricing.

Open-source AWX is not the same commercial product

AWX is the upstream community project associated with automation controller. It is useful for experimentation and community use, but it is not identical to a supported Red Hat Ansible Automation Platform subscription.

Organizations evaluating production use should compare support, lifecycle, security updates, platform integration, and operational accountability rather than assuming “same interface” means “same product.”

The modern skill is automation operations, not Tower administration

Learning the old Tower menus is less valuable than understanding the durable concepts behind the platform: source-controlled automation, inventories, credentials, execution environments, distributed execution, idempotency, RBAC, workflows, APIs, observability, and change governance.

If those concepts are strong, moving between Tower-era documentation and current automation controller becomes straightforward. The platform changed because enterprise automation became larger and more distributed; your operating model should change with it.