7. Upgrading an Existing Tower Installation

You can upgrade your existing Tower installation to the latest version easily. Tower looks for existing configuration files and recognizes when an upgrade should be performed instead of an installation.

As with installation, the upgrade process requires that the Tower server be able to access the Internet. The upgrade process takes roughly the same amount of time as a Tower installation, plus any time needed for data migration.

This upgrade procedure assumes that you have a working installation of Ansible and Tower.


You can not convert an embedded-database Tower to a Active/Passive Redundancy mode installation as part of an upgrade. Users who want to deploy Tower in a Redundant configuration should back up their Tower database, install a new Redundant configuration on a different VM or physical host, and then restore the database. It is possible to add a primary or secondary instance later on to Tower if it is already operating on an external database. Refer to the Active/Passive Redundancy chapter of the Ansible Tower Administration Guide.

7.1. Requirements

Before upgrading your Tower installation, refer to Requirements to ensure you have enough disk space and RAM as well as to review any software needs. For example, you should have the latest stable release of Ansible installed before performing an upgrade.


All upgrades should be no more than two major versions behind what you are currently upgrading to. For example, in order to upgrade to Ansible Tower 3.5.x, you must first be on version 3.3.x; i.e., there is no direct upgrade path from version 3.2.x. Refer to the recommended upgrade path article off your customer portal.

In order to run Ansible Tower 3.5 on RHEL 8, you must also have Ansible 2.8 or later installed.

7.2. Backing Up Your Tower Installation

It is advised that you create a backup before upgrading the system. After the backup process has been accomplished, proceed with OS/Ansible/Tower upgrades.

Refer to Backing Up and Restoring Tower in the Ansible Tower Administration Guide.


Please note that an issue was discovered in Tower 3.0.0 and 3.0.1 that prevented proper system backups and restorations.

If you need to backup or restore your Tower v3.0.0 or v3.0.1 installation, use the v3.0.2 installer to do so.

7.3. Get the Tower Installer

You may install standalone Tower or use the bundled installer:

  • if you set up Tower on an environment with a direct Internet access, you can download the standalone Tower installer

  • if you set up Tower on an environment without direct access to online repositories, or your environment enforces a proxy, you must use the bundled installer

Download and then extract the Ansible Tower installation/upgrade tool:

[email protected]:~$ tar xvzf ansible-tower-setup-latest.tar.gz
[email protected]:~$ cd ansible-tower-setup-<tower_version>

To install or upgrade, start by editing the inventory file in the ansible-tower-setup-<tower_version> directory, replacing <tower_version> with the version number, such as 2.4.5 or 3.0.0. directory.


As part of the upgrade process, database schema migration may be done. Depending on the size of your Tower installation, this may take some time.

If the upgrade of Tower fails or if you need assistance, please contact Ansible via the Red Hat Customer portal at

7.4. The Setup Playbook


Ansible Tower 3.0 simplifies installation and removes the need to run ./configure/ as part of the installation setup. Users of older versions should follow the instructions available in the v.2.4.5 (or earlier) releases of the Tower Documentation available at:

The Tower setup playbook script uses the inventory file and is invoked as ./ from the path where you unpacked the Tower installer tarball.

[email protected]:~$ ./

The setup script takes the following arguments:

  • -h – Show this help message and exit

  • -i INVENTORY_FILE – Path to Ansible inventory file (default: inventory)

  • -e EXTRA_VARS – Set additional Ansible variables as key=value or YAML/JSON (i.e. -e bundle_install=false forces an online installation)

  • -b – Perform a database backup in lieu of installing

  • -r – Perform a database restore in lieu of installing (a default restore path is used unless EXTRA_VARS are provided with a non-default path, as shown in the code example below)

./ -e 'restore_backup_file=/path/to/nondefault/location' -r


Please note that a issue was discovered in Tower 3.0.0 and 3.0.1 that prevented proper system backups and restorations.

If you need to back up or restore your Tower v3.0.0 or v3.0.1 installation, use the v3.0.2 installer to do so.