CHAI™ Appliance Delivery Methods¶
CHAI™ is available as a SaaS offering (https://app.cloudhedge.io) and as a stand-alone appliance. This page helps you choose how the stand-alone appliance is delivered and how it connects to your source servers. Installation steps are documented at CHAI™ Appliance Installation using CHCTL.
Which Delivery Format Do I Need?¶
| Target environment | Format | OS variants | Network topology | Hosted by |
|---|---|---|---|---|
| Any Linux host (including air-gapped) | Tar Ball | Ubuntu, RHEL, Alma Linux | On-premises data center, or your cloud | Customer |
| On-premises VMware / hypervisor | OVA / VMDK | RHEL, Ubuntu | On-premises data center | Customer |
| AWS EC2 | AMI | RHEL, Ubuntu, Alma Linux | Your AWS account, Site-to-Site VPN, or Public-facing with guardrails | Customer or CloudHedge |
| Azure | Azure VM Image | RHEL, Ubuntu | Your Azure subscription, or Site-to-Site VPN | Customer or CloudHedge |
Appliance Requirements¶
Every delivery format runs the same appliance, so the same requirements apply to all of them:
- Hardware, OS, and Docker versions: see Recommended Resource Requirements and the Prerequisites Summary.
- User and access requirements (appliance host, Linux and Windows source servers): see the Prerequisites Summary.
- Ports: see the Port Configuration Matrix.
- VMware assessment (optional): see Prerequisites for VCenter Discovery.
Note: Use the container engine native to the chosen OS: Podman (podman, podman-docker, podman-compose) on RHEL, and Docker (docker, docker-compose) on Ubuntu. The AMI, OVA, and Azure images include the OS and container runtime. The tar ball does not.
Delivery Formats¶
Tar Ball¶
A portable archive of the CHAI™ installer and images that you extract and run on a Linux host you have already provisioned.
Best for: Air-gapped or on-premises data centers, environments with strict image-provenance controls, or any platform where a pre-built image is not available.
- A supported OS and container runtime pre-installed on the host.
- Outbound access to a package/registry mirror, or a fully offline image bundle for air-gapped environments.
- Extra temporary space to extract the archive (in addition to
/optand/var). - Secure transfer (SFTP or signed download) with SHA-256 checksum and signature verification.
Considerations: Most flexible option, but requires the most manual effort. You are responsible for OS hardening and runtime prerequisites.
OVA / VMDK¶
A virtual appliance package for VMware vSphere/ESXi. The VMDK can also be imported into other hypervisors.
Best for: On-premises VMware environments, especially when the same appliance will also run VMware assessment against vCenter.
- vCenter/ESXi privileges to deploy an OVF/OVA template and assign the network and datastore.
- A port group / VLAN with access to source servers and, if used, vCenter.
- A static IP and DNS plan for the appliance VM.
- Secure OVA transfer with checksum verification.
- For VMDK only: confirm the target hypervisor's import path and virtual hardware compatibility.
Considerations: Native fit for VMware and vCenter-based discovery. Requires hypervisor administrator involvement and a larger file transfer.
AMI (Amazon Machine Image)¶
A pre-built EC2 image with the OS, container runtime, and CHAI™ bundled, launched into your AWS account.
Best for: Source workloads running in AWS, or using AWS as the modernization staging environment.
- AMI shared to your AWS account and copied to each Region where it is needed (AMIs are Region-scoped).
- An instance type such as
m7i.xlargeorm5.xlarge, with EBS volumes sized for/optand/var. - A VPC, subnet, and security group allowing the required CHAI™ ports. See Networking Considerations.
- IAM permissions to launch the instance, and an optional instance profile if the appliance needs AWS API access.
- An SSH key pair, and EBS encryption (KMS) as per your security policy.
Considerations: Fast, repeatable launch. AMIs must be shared and managed per Region.
Azure VM Image¶
A managed image / VHD deployed into your Azure subscription.
Best for: Source workloads running in Azure, or using Azure as the staging environment.
- Image shared through an Azure Compute Gallery, or provided as a VHD to import.
- A VM size such as
Standard_D4s_v5, with managed disks sized for/optand/var. - A VNet, subnet, and NSG rules for the required CHAI™ ports. See Networking Considerations.
- RBAC permissions to deploy the VM, and an optional Managed Identity if the appliance calls Azure APIs.
- An SSH key, and disk encryption as per your security policy.
Considerations: Native Azure launch. Image versions and region replication must be managed.
Networking Considerations¶
The appliance must reach your source servers (Linux/Windows) and, for VMware assessment, vCenter. Four network topologies are supported.
| Topology | Use when | Key requirements |
|---|---|---|
| Site-to-Site VPN (CloudHedge ↔ Customer) | CloudHedge hosts the appliance and must reach source servers in your private network. | IPsec VPN gateway and agreed IKE/encryption parameters; non-overlapping CIDR ranges; routes to source subnets; CHAI™ ports opened within the tunnel only. |
| Public-facing with guardrails | You prefer managed ingress over a VPN and can provide fixed source IP ranges. | ALB / NLB / CloudFront in front of the appliance; allow-list of known networks only (security groups / WAF); TLS termination; edge logging and monitoring. |
| Customer on-premises data center | Data residency or air-gap requirements keep everything on-premises. | Internal access from the appliance to source servers and vCenter; internal DNS or static IP; no inbound internet; outbound only if licensing or updates require it. |
| Customer public / private cloud | Source workloads already run in your AWS or Azure account. | Appliance deployed in your VPC/VNet with access to source subnets; private connectivity (peering / private endpoints) preferred; optional bastion host. |
Pre-Delivery Checklist¶
- Delivery format chosen and matched to the network topology (see Which Delivery Format Do I Need?).
- OS variant confirmed (RHEL / Ubuntu / Alma Linux) and OS licensing owner agreed (see OS Subscription & Licensing).
- Appliance host/VM meets the appliance requirements.
- Artifact transferred securely, with SHA-256 checksum and signature verified.
- Ingress security review completed (allow-lists / VPN / NSG / security groups).
After the appliance is installed, complete the Pre-Assessment Checklist to confirm your source hosts are ready.
OS Subscription & Licensing¶
The appliance ships with a supported OS, but OS subscriptions are the customer's responsibility and are not included in the delivery.
- RHEL: Attach a valid Red Hat subscription, or use a cloud marketplace / pay-as-you-go (PAYG) image billed through your AWS or Azure account.
- Alma Linux / Ubuntu: Free to use. Any enterprise support (for example, Ubuntu Pro/ESM) is your responsibility if your policy requires it.
- AMI / Azure VM Image: Marketplace/PAYG OS charges appear on your cloud bill. Confirm this before launch.
- Tar ball / OVA / VMDK: You maintain OS entitlements and update channels (Red Hat Satellite / subscription-manager, or an offline mirror for air-gapped sites).