Deployment guide

This page provides a deployment guide for Omada Identity Cloud Private. It explains the deployment modes available, the shared prerequisites you need in place before deploying, and how to validate a completed deployment.

Release package signing

Before choosing a deployment mode and installing the product, you can confirm that the downloaded release packages actually came from Omada and have not been altered in transit. See Release package signing before following a deployment mode of your choice.

Deployment modes

Omada Identity Cloud Private supports two deployment approaches that provide different levels of control and automation: Installation Script mode and Raw IaC (Infrastructure as Code) mode.

Mode Selection

Start with Installation Script mode unless you have specific requirements for Raw IaC customization. You can transition to Raw IaC later if needed.

Installation Script mode (recommended)

Installation Script is the currently recommended and fully supported deployment mode. A single installation script (install.sh) orchestrates the entire deployment end-to-end, including preflight validation, toolchain bootstrap, infrastructure provisioning, artifact publishing, configuration validation, and node setup.

When to use:

• First-time Cloud Private deployments.
• Standard environment configurations.
• Teams that want a guided, validated deployment process.

For full step-by-step instructions, see Installation Script mode.

Raw IaC mode (advanced)

The Raw IaC mode provides direct access to Terraform and Ansible scripts for maximum control and customization. It is suitable for advanced users with IaC (infrastructure as code) expertise.

When to use:

• Significant customization or modifications required.
• Existing Terraform/Ansible infrastructure to integrate with.
• Internal tooling requires direct script access.
• Advanced users comfortable with IaC.

For full step-by-step instructions, see Raw IaC mode.

Prerequisites

Before proceeding, ensure the Azure tenant prerequisites are in place. For identity, quota, networking, and certificate requirements at the Azure tenant level, see Prerequisites in the Omada Identity Cloud Private overview.

System prerequisites

Installation Script prerequisites

The installation script handles toolchain setup automatically: it installs Terraform, Ansible, kubectl, Helm, and other required tools for you during the toolchain phase, so you do not need to install or version-pin them yourself. Before running it, ensure the following:

Requirement	Details
OS	Ubuntu 24.04 LTS (native or WSL 2 on Windows)
RAM	Minimum 8 GB (recommended)
Disk space	Minimum 30 GB free
Azure CLI	Installed (see Step 3 of the Installation Script mode) and authenticated (az login)
Network	Outbound HTTPS access to login.microsoftonline.com, api.github.com, and pypi.org (verified by preflight). Additional outbound access to Azure services and Docker registries is required but not preflight-checked.

The exact tool versions installed for a given release are pinned by the installer and are not repeated here. To learn the versions it installs, see the release notes of the Cloud Private version you want to deploy or check the generated configuration files on the deployment host after installation.

Raw IaC prerequisites

The Raw IaC mode has no installer to pin tool versions for you, so you must install and version-match the tooling yourself. Required tools include the OS, Terraform, Ansible, Ansible Core, Azure CLI, and Python, plus additional dependencies defined in code (see scripts/install/ansible-requirements.txt for the full pinned set).

For the exact versions required, check the release notes for the release you are deploying, as each release has a dedicated note that lists the tool versions it requires.

Networking prerequisites

Before deploying Cloud Private, ensure your Azure tenant has proper network infrastructure configured:

Virtual Network (VNet) planning

Each Cloud Private environment requires a dedicated VNet sized appropriately for your deployment. The default configuration allocates:

Environment	VNet CIDR	Recommended use
Development	10.1.0.0/20 (4,096 IPs)	Dev deployments
QA	10.2.0.0/20 (4,096 IPs)	UAT/staging environments
Production	10.3.0.0/20 (4,096 IPs)	Production workloads

Planning considerations:

• Ensure VNet CIDR ranges do not overlap with existing networks or on-premises networks
• If using VNet peering or ExpressRoute, plan non-overlapping address spaces
• Reserve the entire /20 even if not all IPs are immediately used
• Consider future expansion of subnets within the /20 range

Subnet configuration

Each VNet is subdivided into subnets for different functional areas. You must provision these subnets before deployment:

Subnet Name	CIDR	Total IPs	Purpose	Configuration
Compute (AKS)	/24	256	Kubernetes cluster nodes and pods	Network Security Group (NSG) required
App Service (delegated)	/27	32	App Service VNet integration	Delegated subnet; NSG required
Private endpoints	/26	64	Private Link connectivity	NSG recommended
Additional subnets	Variable	-	Reserved for future services	Plan expansion accordingly

Example subnet allocation for Dev (10.1.0.0/20):

10.1.0.0/24    > AKS Compute (Kubernetes nodes)
10.1.2.0/27    > App Service (delegated)
10.1.2.64/26   > Private endpoints
10.1.4.0/22    > Future expansion

Network Security Groups (NSGs)

NSGs control inbound and outbound traffic for each subnet. Deploy the following NSG configurations:

AKS Compute NSG Rules:

Direction	Priority	Name	Source	Destination	Port	Action	Purpose
Inbound	100	AllowFromWhitelistedIPs	Whitelisted IPs*	AKS subnet	All	Allow	Office/corporate network access
Inbound	120	DenyAllInbound	Any	Any	All	Deny	Default deny rule
Outbound	100	AllowAllOutbound	Any	Any	All	Allow	Required for image pulls, updates

Whitelisted IPs

*Configure the allowed source IPs based on your organization's network addresses (for example, office network ranges or VPN gateway IPs).

NSG rules for private endpoints (if enabled):

Direction	Priority	Name	Source	Destination	Port	Action	Purpose
Inbound	100	AllowFromComputeSubnet	AKS subnet	PE subnet	443	Allow	HTTPS to private services
Outbound	100	AllowToPrivateServices	PE subnet	Any	443	Allow	Private Link traffic

NSG Customization

The NSG rules above are templates. Customize the Whitelisted IPs and source ranges based on your organization's IP address allocation and security policies.

DNS configuration

External DNS (public endpoints):

• Register a DNS domain for your Cloud Private deployment (for instance, omada.<your-domain>.com).
• Create a DNS zone in Azure (via azure.microsoft.com or your registrar).
• After AKS deployment, an ingress IP will be assigned; create A records pointing to this IP.
• Obtain and import a valid TLS certificate for the DNS name.

Internal DNS (Azure-managed):

• Azure DNS automatically provides name resolution within the VNet.
• No configuration required; Kubernetes and service-to-service communication work automatically.

DNS Updates

DNS records are updated automatically during the Ansible deployment phase when update_private_dns_records is set to true in deployment-config.json (default). To manage DNS records manually, set this parameter to false.

Connectivity to on-premises networks

If your Cloud Private instance needs to integrate with on-premises systems, you can reach them in one of two ways, depending on the connectivity package that each system integration uses:

• Through the Linux CAG: For system integrations that use cross platform connectivity packages. The Linux CAG workers run in the AKS compute subnet and open the connections to the target systems themselves. The installation does not create the network path, so you have to set it up:
  • VPN Gateway or ExpressRoute: Configure site-to-site connectivity from your Azure VNet to on-premises networks.
  • Firewall rules: Ensure your on-premises firewalls allow traffic from the AKS compute subnet to the target systems.
  • DNS resolution: Configure hybrid DNS resolution so Azure resources can resolve on-premises hostnames.
• Through a self-hosted Windows CAG: Required for system integrations that use connectivity packages that are not cross platform, for example Active Directory or LDAP. Host a Windows CAG close to the target systems, for example on-premises. The Windows CAG connects outbound to your Cloud Private deployment over HTTPS. See Self-hosted Windows CAG.

Azure services and quota requirements

Before deployment, verify that your Azure subscription has sufficient quotas for all required resource types. For detailed quota tables covering compute, networking, AKS, and storage, see Subscription and quotas in the Omada Identity Cloud Private overview.

Certificates and Key Vault secrets

Azure Key Vault is used for secure storage and management of secrets, certificates, and sensitive configuration values. All certificates must be prepared and uploaded to Azure Key Vault before running the installation script: the script validates their presence during the secrets_validate phase and will stop if any are missing.

For required certificates, encoding instructions, automatically generated secrets, and a pre-deployment checklist, see Key Vault and secret management.

Deployment validation checklist

After deployment, run the health check script to validate that the environment is operational and ready for handover:

Tool: Bash shell

./scripts/health_check.sh --global-prefix <global-prefix>

The script automatically verifies the following:

Check	What is validated
Endpoint availability	All services (web apps, function apps, Enterprise Server) respond on their expected endpoints.
AKS pod readiness	Enterprise Server, RoPE, Timer, CagOps, and the four Cloud Application Gateway worker pods each have at least one ready pod.
Component versions	All running components match the versions declared in variables.auto.tfvars.json.
Error logs	No errors in the OIS diagnostic log table (OIS_CL) in the last 30 minutes.
Service Bus dead letters	No dead-lettered messages across all Service Bus namespaces.

The script produces a PASS, WARN, or FAIL result per check, followed by an overall summary. The environment is ready for handover when the final result is PASS.

For full details on running the script and interpreting results, see Post-deployment health check.

tip

If the health check reports failures or warnings, see Collecting debug logs to gather diagnostic data for analysis or to send to Omada Support.