Removable media: Copy the disk image directly to the disconnected host using removable media (USB drive, portable storage) or a secure file transfer mechanism.

1. On a connected machine, download the QCOW2 or VMDK disk image from the Red Hat Ansible Automation Platform downloads page.
2. Copy the disk image to removable media.
3. Transfer the media to the disconnected environment and copy the image to the target host. For example, for a KVM deployment:

   $ rsync --progress /media/usb/portal-appliance.qcow2 /var/lib/libvirt/images/portal-appliance.qcow2

Internal mirror registry: If your disconnected environment has an internal container registry, you can copy the bootc container image to your mirror and build disk images from it.

1. On a connected machine, copy the bootc container image to your internal registry:

   $ skopeo copy \
     docker://registry.redhat.io/ansible-automation-platform/bootc-automation-portal-rhel9:<version> \
     docker://mirror.internal.example.com:5000/ansible-automation-platform/bootc-automation-portal-rhel9:<version>

2. If your mirror registry uses a self-signed certificate, add the CA certificate to the system trust store on the machine where you will build the disk image:

   $ sudo cp ca.crt /etc/pki/ca-trust/source/anchors/
   $ sudo update-ca-trust

3. Build the disk image from the mirror registry in your disconnected environment. Refer to the Red Hat documentation for building bootc disk images from a custom registry source.
4. Deploy the resulting disk image using the standard installation procedure for your platform.

• For RHEL with KVM, see Install Ansible automation portal on RHEL with KVM.
• For Red Hat OpenShift Virtualization, see Install Ansible automation portal on Red Hat OpenShift Virtualization.
• For VMware vSphere, see Install Ansible automation portal on VMware vSphere.

The cloud-init configuration for a disconnected deployment is the same as a connected deployment. Use the templates from Prerequisites for deploying Ansible automation portal on RHEL.

The following differences apply in a disconnected environment:

• Source control integrations require network access. The integrations.github and integrations.gitlab cloud-init fields require network access to the source control service. If your disconnected environment has internal GitHub Enterprise or GitLab instances, configure these fields with the internal hostnames.
• Set network.base_url to match your internal DNS or IP. Set network.base_url to the hostname or IP address that users will use to access the Ansible automation portal RHEL appliance on your internal network. If omitted, the appliance auto-detects the VM IP address.

Minimal cloud-init template for disconnected deployment:

#cloud-config

users:
  - name: <username>
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - "<your-ssh-public-key>"

aap:
  host_url: "https://<internal-aap-host>"
  token: "<aap-api-token>"
  oauth:
    client_id: "<oauth-client-id>"
    client_secret: "<oauth-client-secret>"

database:
  type: builtin
  builtin:
    password: "auto"
    admin_password: "auto"

$ sudo systemctl status portal postgres devtools

All three services (portal, postgres, devtools) should show active (running).

Alternatively, use the portal management CLI for detailed diagnostics:

$ sudo ansible-portal status

$ sudo podman exec portal ls /opt/app-root/src/dynamic-plugins-root/

You should see plugin directories listed. These plugins were loaded from the pre-baked files at /usr/share/portal/plugins/, not from a registry.

$ sudo podman login --authfile /etc/ostree/auth.json registry.redhat.io

The /etc/ostree/auth.json file is what bootc upgrade and bootc switch use for registry authentication.

If no registry is available for image upgrades, you can bypass the registry authentication gate:

$ sudo touch /etc/portal/.registry-auth-override

This override marker allows the appliance to start without registry credentials. It is preserved across backups, restores, and bootc upgrades.