This guide walks through the fully automated deployment of the Cloudmersive Private Cloud Virus Scan, Document Conversion, OCR, NLP, Image Recognition, Speech, DLP and CoreAI APIs on Azure Kubernetes Service (AKS) with the Cloudmersive deployment pack. CoreAI runs on its own dedicated GPU node. You provide a few settings, and a single automated deployment does the rest: it creates the Azure infrastructure, installs the services, and exposes them over HTTPS on a hostname you choose. The only manual step afterwards is a DNS record for your hostname.

There are two ways to run the deployment. Both create the same resources and produce the same result.

• Deploy to Azure opens a guided wizard in the Azure portal. You fill in a few pages, select your certificate file, and click Create. Nothing needs to be installed on your computer.
• Bicep uses the same template from the command line. Choose this if you manage your Azure infrastructure as code, want to review or change the template, or want to run the deployment from a pipeline.

The deployment takes about 60 to 90 minutes. Most of that time is spent by the Windows nodes downloading the container images for the first time.

At a glance: the cluster's node types

The cluster has three node pools. Each pool has a single job, and the services are pinned to the pool they belong on.

• Linux system pool (system). This pool runs Azure Linux. By default it has two Standard_D4s_v5 nodes, each with 4 vCPUs and 16 GB of memory. It runs the Kubernetes system components, the Application Gateway for Containers controller and the Key Vault CSI driver. No Cloudmersive API runs here.
• Windows pool (win22). This pool runs Windows Server 2022. By default it has four Standard_E8s_v5 nodes, each with 8 vCPUs and 64 GB of memory. It runs every Cloudmersive API except CoreAI.
• GPU pool (gpu). This pool runs Ubuntu Linux. By default it has one Standard_NC40ads_H100_v5 node with 40 vCPUs and one NVIDIA H100 NVL GPU with 94 GB of GPU memory. It runs only CoreAI.

With the defaults, the cluster has 7 nodes, 92 vCPUs, about 640 GB of system memory and one H100 GPU. The AKS cluster uses the Standard pricing tier, which includes the uptime SLA. The GPU node is by far the largest part of the monthly cost, so use the Azure pricing calculator to estimate the cost for your region before you deploy.

Windows node pool

The Windows pool is sized to run all of the non-GPU Cloudmersive APIs side by side. Four Standard_E8s_v5 nodes give 256 GB of total memory, which is the recommended amount. Each Windows node needs at least 16 GB of memory. The wizard offers 4 vCPU sizes such as Standard_E4s_v5 (32 GB) and Standard_D4s_v5 (16 GB) for small or test deployments, and larger sizes such as Standard_E16s_v5 for heavy workloads.

Use v4 or v5 sizes for this pool. The Windows Server 2022 node image is a Generation 1 VM image, and v6 sizes support Generation 2 only, so a v6 size fails with a Hypervisor Generation error.

The Windows pool can use a fixed node count or the cluster autoscaler. When autoscaling is on, the defaults are a minimum of 4 nodes and a maximum of 6 nodes. Each Windows node has a 256 GB managed OS disk to hold the container images.

GPU node pool

The GPU pool is the part of this deployment that needs the most planning, because GPU sizes are available only in some regions and need their own quota.

What CoreAI needs. CoreAI needs one NVIDIA GPU with at least 80 GB of GPU memory, and it runs as a single instance.

Supported GPU sizes. The wizard offers the four sizes below. All of them meet the 80 GB requirement.

• Standard_NC40ads_H100_v5 (default). This size has one NVIDIA H100 NVL GPU with 94 GB of GPU memory, 40 vCPUs and 320 GB of system memory. It uses the NCadsH100v5 quota family.
• Standard_NC24ads_A100_v4. This size has one NVIDIA A100 PCIe GPU with 80 GB of GPU memory, 24 vCPUs and 220 GB of system memory. It uses the NCADS_A100_v4 quota family.
• Standard_NC80adis_H100_v5. This size has two NVIDIA H100 NVL GPUs with 94 GB of GPU memory each, 80 vCPUs and 640 GB of system memory. It uses the NCadsH100v5 quota family.
• Standard_NC48ads_A100_v4. This size has two NVIDIA A100 PCIe GPUs with 80 GB of GPU memory each, 48 vCPUs and 440 GB of system memory. It uses the NCADS_A100_v4 quota family.

Standard_NC40ads_H100_v5 is the recommended size. Standard_NC24ads_A100_v4 also meets the requirement and is offered in more regions, so it is the usual choice when the H100 size is not available to you. Because CoreAI runs as a single instance on one GPU, the two-GPU sizes leave the second GPU unused; choose them only if Cloudmersive Support recommends it for your workload.

Count and disk. The default is one GPU node, and one is enough because CoreAI runs as a single instance. The pool does not autoscale. Each GPU node has a 1024 GB managed OS disk by default, because CoreAI needs a large amount of disk space. You can choose between 256 GB and 2048 GB, but 1024 GB is recommended.

How the pool is isolated. The GPU pool carries the node label nvidia.com/gpu=true and the taint nvidia.com/gpu=true:NoSchedule. Only CoreAI is configured to run on nodes with this label and taint, so no other workload is ever placed on the expensive GPU node.

Drivers. AKS installs the NVIDIA driver on Ubuntu GPU nodes automatically. The deployment then installs the NVIDIA Kubernetes device plugin (version v0.14.5 by default) on the GPU pool only. The device plugin is what makes the nvidia.com/gpu resource visible to Kubernetes, and without it CoreAI cannot start.

Warm-up. After the CoreAI image has been downloaded, CoreAI needs about ten more minutes to start up. The AI APIs return errors until it is ready, while the other APIs work normally.

Quota you need

The region you choose needs enough vCPU quota for every pool. With the defaults, you need the following.

• Esv5 family: 32 vCPUs. The four Standard_E8s_v5 Windows nodes use this family.
• NCadsH100v5 family: 40 vCPUs. The Standard_NC40ads_H100_v5 GPU node uses this family.
• Dsv5 family: 8 vCPUs. The two Standard_D4s_v5 Linux system nodes use this family.

If you choose the A100 size instead, you need 24 vCPUs of NCADS_A100_v4 quota in place of the H100 quota. If you turn on Windows autoscaling, the Esv5 quota must cover the maximum node count, which is 48 vCPUs with the defaults. GPU quota is often zero on new subscriptions and can take a few days to approve, so request it on the Quotas page of the Azure portal well before you deploy. A missing GPU quota is the most common reason this deployment fails.

What the deployment creates

All resources are created in one resource group that you choose.

• Virtual network. The network holds the cluster nodes and the gateway. It gets two subnets, or four when private endpoints are enabled.
• AKS cluster. The cluster has the three node pools described above.
• Application Gateway for Containers. The gateway is the public HTTPS entry point. It presents your TLS certificate and forwards requests to the Cloudmersive services inside the network. Nothing in the cluster has its own public IP address.
• Key Vault. The vault stores your TLS certificate, the Windows node administrator password and your Cloudmersive Node ID.
• Managed identities. Four managed identities handle every call between Azure services, so no passwords or service principals are created.
• Deployment script. A one-time configuration step installs the gateway controller, the NVIDIA device plugin and the Cloudmersive services inside the cluster. It runs again every time you run the deployment.
• Container registry (optional). When enabled, the Cloudmersive images are copied into an Azure Container Registry in your subscription and pulled from there with a managed identity.
• NAT Gateway (optional). When enabled, all outbound traffic from the cluster leaves through one stable public IP address.

Before you start

Have the following ready:

• Your Cloudmersive Node ID. It is shown on your node's Manage Deployment page in the Cloudmersive portal, as described in Step 1. It identifies your private cloud node and is not a secret.
• A hostname and a TLS certificate. Decide which hostname your applications will call, for example api.contoso.com, and have a TLS certificate for that name. The sections The public hostname and TLS certificate options explain both choices in detail.
• Azure permissions. You need permission to create a resource group and role assignments in the subscription. The Owner role works, as does Contributor together with User Access Administrator. If you use a certificate from an existing Key Vault, you also need permission to create role assignments on that vault.
• Azure quota. You need the vCPU quota listed in Quota you need, including the GPU quota.
• A supported region. The region must support Application Gateway for Containers, Windows Server 2022 node pools and the GPU size you choose. The GPU size is the most restrictive of the three, so check it first.
• Outbound access. The cluster needs outbound Internet access to reach Cloudmersive's management and update services, to download the container images and the Helm chart, and to download the NVIDIA device plugin manifest from GitHub. If your organization restricts outbound traffic, contact Cloudmersive Support for the list of addresses to allow.

The public hostname

The public hostname is the single name your applications use to call every Cloudmersive API in this deployment, for example api.contoso.com. All of the APIs share it and are told apart by their path, such as /virus/..., /convert/... or /llm/....

The hostname is used in three places, and all three must agree:

1. Your TLS certificate. The certificate must be issued for this name, either exactly or through a wildcard such as *.contoso.com.
2. The gateway. The gateway listens only for requests addressed to this exact name. A request that arrives under any other name, including the gateway's own Azure address, is not routed to the services. You therefore cannot test the deployment by calling the gateway's Azure address directly.
3. Your DNS. After the deployment, you create a CNAME record from this name to the gateway's Azure address, which the deployment reports as the frontendFqdn output. That address is generated by Azure, ends in .alb.azure.com, and cannot be chosen.

The hostname must be a fully qualified lowercase name such as api.contoso.com. Use a name below your domain rather than the bare domain (contoso.com), because DNS does not allow a CNAME record on a zone apex. You do not need to own the DNS zone in Azure; any DNS provider that can create a CNAME record works.

The hostname is a public DNS name, and the gateway behind it is reachable from the Internet. The section Public and private networking explains what can and cannot be made private.

TLS certificate options

All traffic to the gateway uses HTTPS. The gateway presents your certificate and decrypts the traffic, then forwards each request to the services inside the virtual network. Choose one of three certificate sources.

Upload a PFX file

This is the default and the right choice for most production deployments. You provide the certificate as a .pfx file that includes the private key, together with its password. The deployment imports it into the Key Vault it creates, under the name cloudmersive-tls.

In the wizard, you select the file with a file picker. With Bicep, you pass the file base64-encoded on the command line, as shown in Path B. The file and its password are never written to the parameter file, and Azure does not keep them after the deployment.

When the certificate is close to expiry, you import the renewed certificate as a new version of cloudmersive-tls, as described in Renewing or replacing the TLS certificate. No redeployment is needed.

Use a certificate in an existing Key Vault

Choose this if your organization already manages the certificate in one of its own Key Vaults, for example because the vault renews the certificate automatically. The certificate stays in your vault and is not copied. The deployment gives two of its managed identities read access to that vault: the cluster's Key Vault CSI driver gets the Key Vault Secrets User role, and the configuration step gets the Key Vault Certificate User role.

This option has the following requirements:

• The vault must use the Azure role-based access control permission model, because access is granted through role assignments. Vaults that use access policies are not supported by this option.
• The account running the deployment must be allowed to create role assignments on that vault.
• If the vault has private endpoints or a firewall, the cluster and the deployment script must be able to reach it.

In the wizard, you pick the vault and certificate from a list. With Bicep, you set existingKeyVaultResourceId and existingKeyVaultCertificateName. When the certificate is renewed in your vault under the same name, the gateway picks up the new version within a few minutes.

Self-signed (testing only)

The deployment creates a self-signed certificate for your hostname in its own Key Vault. The certificate is valid for 12 months and is kept when you run the deployment again. Browsers show a warning for it, and API clients must be configured to skip certificate validation. The deployment's configuration output also lists a warning to remind you. Use this option only for a quick test, and replace the certificate with a real one before production use.

Redirecting HTTP to HTTPS

Redirect plain HTTP (port 80) to HTTPS is selected by default. With it, the gateway also listens on port 80 for your hostname and answers every plain HTTP request with a permanent redirect (301) to the HTTPS address. If you clear it, the gateway does not listen on port 80 at all. Leave it selected unless you have a specific reason to turn it off.

Public and private networking

The deployment always creates a new, dedicated virtual network. It does not deploy into an existing virtual network. Several parts of the deployment can be public or private, and each one is controlled separately. The four layers are explained below, from the most visible to the least.

1. The API endpoint (the gateway)

The gateway's frontend is always public. Your applications reach the Cloudmersive APIs over the Internet through your hostname, and this deployment pack has no option for an internal-only gateway frontend. Behind the gateway, everything is private: the nodes and the services have no public IP addresses.

If your applications must reach the APIs only over a private network, contact Cloudmersive Support to discuss the options for your environment.

2. The Kubernetes API server

The Kubernetes API server is what kubectl and the Azure portal's Kubernetes pages talk to. It does not carry any Cloudmersive API traffic. There are three choices:

• Public and unrestricted. This is the default. Anyone can reach the API server's address, but every call still requires Microsoft Entra ID sign-in and an Azure role.
• Public, limited to your IP ranges. Enter your organization's public IP ranges under API server authorized IP ranges in the wizard, or set authorizedIpRanges in Bicep. Only those ranges can reach the API server.
• Private. Select Private API server in the wizard, or set enablePrivateCluster to true in Bicep. The API server then has no public endpoint. The deployment still works, because the configuration step runs inside the cluster. To use kubectl afterwards, you need network access to the virtual network, for example over VPN, ExpressRoute, a peered network or a jump host.

3. Key Vault, the container registry and the deployment storage account

By default, these three services have public endpoints protected by Azure sign-in and roles. The Private endpoints option places them behind private endpoints inside the virtual network and turns their public endpoints off. Read the Private endpoints section of this guide before you turn this on, because it changes how you manage the certificate from the Azure portal.

4. Outbound traffic

The cluster always needs outbound Internet access, as described in Before you start. There are two ways to provide it:

• AKS load balancer. This is the default. Outbound traffic leaves through the cluster's load balancer.
• NAT Gateway. Outbound traffic leaves through one stable public IP address. Choose this if a firewall elsewhere must allow your cluster's traffic by IP address, for example to reach your own storage or services.

Address ranges

The defaults create the virtual network 10.240.0.0/16 with a node subnet of 10.240.0.0/22 and a gateway subnet of 10.240.4.0/24, and they use 10.241.0.0/16 for Kubernetes services. With private endpoints enabled, two more subnets are added at 10.240.5.0/27 and 10.240.5.32/27. Change these ranges only if they overlap a network you plan to connect to this one through peering or VPN. If you plan to make the API server private or to use private endpoints, you will almost certainly connect a network, so check for overlaps first.

With the default classic Azure CNI mode, every pod takes an address from the node subnet. The default /22 subnet has room for the default node counts with plenty of headroom. If you plan to scale far beyond the defaults, choose a larger node subnet or the Overlay CNI mode, in which pods do not use virtual network addresses.

Common combinations

• A quick evaluation. Keep every default. Everything except the cluster nodes has a public endpoint protected by Azure sign-in.
• A typical production deployment. Keep the defaults, and limit the API server to your organization's IP ranges. Add a NAT Gateway if your firewalls need a fixed outbound address.
• A locked-down deployment for an organization with private connectivity into Azure. Turn on the private API server and private endpoints, and use a NAT Gateway. Peer the virtual network or connect it through VPN or ExpressRoute so that administrators can still manage it. The API endpoint itself stays public.

Step 1: Open the deployment options in the Cloudmersive portal

1. Sign in to the Cloudmersive portal at https://portal.cloudmersive.com.
2. Go to Private Cloud and open your node's Manage Deployment page.
3. Click the Azure Kubernetes Service tab.
4. Choose the deployment type in the Deployment Type list:
   • ARM - Deploy to Azure is selected by default. Continue with Path A.
   • Bicep shows the download for the Bicep pack. Continue with Path B.

Your Cloudmersive Node ID is shown on both options. Copy it now; you will need it in the next step.

Path A: Deploy to Azure

A1. Start the wizard

Click the Deploy to Azure button. The Azure portal opens in a new tab with the deployment template and its wizard already loaded. Sign in to Azure if you are asked to.

On the first page, choose the subscription, create a new resource group or select an empty one, and choose the region. Choose a region where your GPU size is available and where you have quota for it.

A2. Basics page

• Name prefix is used at the start of every resource name. The default is cmpcai. It must be 2 to 10 characters long, use only lowercase letters and digits, and start with a letter. If you deploy more than one Cloudmersive deployment into the same resource group, give each one a different prefix.
• Cloudmersive Node ID is the value you copied in Step 1.
• Public hostname is the name your applications will call, as described in The public hostname.

A3. TLS certificate page

Choose a Certificate source, as described in TLS certificate options:

• Upload a PFX file shows a file picker. Select your .pfx file and enter its password.
• Use a certificate in an existing Key Vault lets you pick a certificate that is already stored in one of your Key Vaults.
• Self-signed (testing only) creates a certificate for testing only.

Leave Redirect plain HTTP (port 80) to HTTPS selected unless you have a reason to turn it off.

A4. Cluster page

The defaults on this page match the node types described at the top of this guide.

• Windows node pool. Choose the Windows node size and the number of nodes, or select Autoscale the Windows node pool and set the minimum and maximum.
• Linux system node pool. The default of two Standard_D4s_v5 nodes is sufficient.
• GPU node pool. Choose the GPU node size, the GPU node count and the GPU node OS disk size. Keep Standard_NC40ads_H100_v5 if it is available to you, or choose Standard_NC24ads_A100_v4 if it is not. Keep one node and a 1024 GB disk.
• Grant my user cluster admin access is selected by default. It gives the account running the deployment the Azure Kubernetes Service RBAC Cluster Admin role, so you can view the cluster's workloads in the Azure portal and connect with kubectl afterwards. If you clear it, those views return an access error until someone assigns you a role.
• Advanced contains the AKS pricing tier, the Kubernetes version and the Windows node administrator account. If you leave the administrator password blank, a strong password is generated and stored in the Key Vault.

A5. Network page

This page holds the settings described in Public and private networking: the address ranges, the Azure CNI mode, the network policy, the outbound connectivity, the private API server, the API server authorized IP ranges and the private endpoints. The defaults suit an evaluation or a typical production deployment.

A6. Registry and services page

• Create an Azure Container Registry and pull images from it with a managed identity is off by default, and the images are pulled directly from Cloudmersive's container registry. Turn it on if your policies require images to be pulled from a registry in your own subscription. The registry must use the Premium SKU when private endpoints are enabled.
• Key Vault name and Container registry name are generated from the name prefix when left blank.
• Cloudmersive Helm chart version is the Cloudmersive release to install. It defaults to the current release at the time the deployment pack was published.
• Router replicas, Kubernetes namespace and Chart download URL override should be left at their defaults unless Cloudmersive Support asks you to change them.

A7. Tags page

Add any tags your organization requires. They are applied to every resource the deployment creates.

A8. Create the deployment

Click Review + create. Azure validates your choices. When validation passes, click Create.

The deployment takes about 60 to 90 minutes. You can follow its progress on the deployment page in the Azure portal. When it shows that your deployment is complete, continue with Step 2.

Path B: Bicep

B1. Download the pack

On the Bicep option of the Azure Kubernetes Service tab, click Download Bicep pack, and unzip the file. The pack contains the template (main.bicep), a parameter file (main.bicepparam), the template's supporting files and a README.

B2. Edit the parameter file

Open main.bicepparam and set at least hostName to your public hostname. Review the other values, which match the defaults described in Path A. The parameters you are most likely to change are listed below.

• hostName (required). This is the hostname on your TLS certificate.
• namePrefix (default cmpcai). This is the prefix for resource names, 2 to 10 lowercase letters or digits starting with a letter.
• tags (no default). These tags are applied to every resource.
• tlsCertificateSource (default import). Use import to upload a PFX file, existingKeyVault to use a certificate in one of your Key Vaults, or selfSigned for testing.
• httpToHttpsRedirect (default true). This setting redirects plain HTTP on port 80 to HTTPS.
• windowsNodeVmSize (default Standard_E8s_v5). This is the size of the Windows nodes.
• windowsNodeCount (default 4). This is the number of Windows nodes. Alternatively, set windowsNodeAutoscale to true with windowsNodeMinCount and windowsNodeMaxCount.
• systemNodeVmSize (default Standard_D4s_v5) and systemNodeCount (default 2). These set the Linux system pool.
• gpuNodeVmSize (default Standard_NC40ads_H100_v5). This is the size of the GPU node. Check that it is offered in your region.
• gpuNodeCount (default 1). This is the number of GPU nodes.
• gpuNodeOsDiskSizeGb (default 1024). This is the OS disk size of each GPU node.
• nvidiaDevicePluginVersion (default v0.14.5). This is the version of the NVIDIA device plugin.
• helmChartVersion (default: the current release). This is the Cloudmersive release to install.
• deployContainerRegistry (default false). Set this to true to copy the images into your own Azure Container Registry.
• outboundType (default loadBalancer). Set this to natGateway for one stable outbound IP address.
• enablePrivateCluster (default false). Set this to true for a private Kubernetes API server.
• authorizedIpRanges (default empty). These ranges limit access to a public API server.
• enablePrivateEndpoints (default false). Read the Private endpoints section before turning this on.
• vnetAddressPrefix, aksSubnetPrefix, agcSubnetPrefix and serviceCidr. These set the address ranges described in Public and private networking.

Secrets are not stored in the parameter file. Your Cloudmersive Node ID and the certificate are passed on the command line in the next step. Every parameter has a description in main.bicep.

B3. Run the deployment

Open Azure Cloud Shell in the Azure portal and choose Bash, or use a terminal where the Azure CLI is installed and signed in. Upload your .pfx file and the unzipped pack to the same folder, change to that folder, and run the following commands. Replace the resource group name, region, Node ID and certificate password with your own values, and choose a region that offers your GPU size.

az group create --name cloudmersive-ai-rg --location eastus2

az deployment group create \
  --resource-group cloudmersive-ai-rg \
  --template-file main.bicep \
  --parameters main.bicepparam \
  --parameters cloudmersiveAccessKey='<your Cloudmersive Node ID>' \
               tlsCertificatePfxBase64="$(base64 -w0 certificate.pfx)" \
               tlsCertificatePfxPassword='<pfx password>'

If you set tlsCertificateSource to existingKeyVault or selfSigned, leave out the two tlsCertificatePfx parameters. For existingKeyVault, also set existingKeyVaultResourceId and existingKeyVaultCertificateName in the parameter file.

To check that the GPU size is offered in a region before you deploy, run the following command. An empty result, or a result with restrictions listed, means that the size cannot be used there.

az vm list-skus --location eastus2 --size Standard_NC40ads_H100_v5 \
  --query "[].{size:name, restrictions:restrictions[].reasonCode}" -o table

The deployment command returns when the deployment is complete, after about 60 to 90 minutes.

Step 2: Point your hostname at the gateway

The deployment's frontendFqdn output is the address of the Application Gateway for Containers. Create a CNAME record in your DNS zone from your public hostname to that address.

• Deploy to Azure: open the deployment in the Azure portal, select Outputs, and copy frontendFqdn.
• Bicep: run the following command.

az deployment group show \
  --resource-group cloudmersive-ai-rg \
  --name main \
  --query properties.outputs.frontendFqdn.value -o tsv

DNS changes can take a few minutes to take effect.

Step 3: Verify the installation

1. Browse to https://<your hostname>/. You should see the Cloudmersive Private Cloud landing page.
2. Send a test request to one of the non-AI APIs, for example https://<your hostname>/virus/scan/file. All of the APIs are available on the same hostname under their own paths, such as /virus/..., /convert/..., /llm/..., /speech/..., /dlp/... and /fraud-ai/....
3. Send a test request to one of the AI APIs, such as an /llm/... endpoint. If it returns an error, CoreAI may still be warming up; wait about ten minutes and try again.

The deployment's configuration output summarizes the in-cluster configuration step. Its gpuNodeReady value shows whether the GPU was schedulable, and its coreAiReady value shows whether CoreAI was running, at the moment the deployment finished. Its warnings list names a kubectl command to run for each problem it found.

Managing the deployment

Connecting to the cluster

If you kept Grant my user cluster admin access selected, you can view the cluster's workloads in the Azure portal and connect with kubectl. Replace <prefix> with your name prefix.

az aks get-credentials --resource-group cloudmersive-ai-rg --name <prefix>-aks
kubectl get pods --namespace cloudmersive
kubectl get nodes -l nvidia.com/gpu=true

The deployment's getCredentialsCommand output contains the exact az aks get-credentials command for your deployment. If you chose a private API server, run these commands from a computer with access to the virtual network.

To give another person access to the cluster, assign them the Azure Kubernetes Service RBAC Cluster Admin role on the cluster. Role assignments can take a few minutes to take effect.

az role assignment create \
  --role "Azure Kubernetes Service RBAC Cluster Admin" \
  --assignee <user object ID or email address> \
  --scope $(az aks show --resource-group cloudmersive-ai-rg --name <prefix>-aks --query id -o tsv)

The Cloudmersive services run in the cloudmersive namespace.

Updating the Cloudmersive services

Each deployment runs a specific, versioned release of the Cloudmersive Helm chart. To update, run the deployment again with a newer chart version. Only the services are upgraded; the infrastructure is left as it is.

• Deploy to Azure: open the original deployment in the Azure portal, click Redeploy, change Cloudmersive Helm chart version to the newer version, and deploy. Azure does not keep certificate files or passwords from the earlier deployment, so select your PFX file and enter its password again.
• Bicep: run the same az deployment group create command with the additional parameter helmChartVersion=<newer version>.

Scaling

To change the number of Windows nodes, run the deployment again with a new node count or new autoscale settings. Keep one GPU node unless Cloudmersive Support advises otherwise, because CoreAI runs as a single instance.

Renewing or replacing the TLS certificate

When you uploaded a PFX file or used a self-signed certificate, the certificate is stored in the Key Vault the deployment created, under the name cloudmersive-tls. To renew or replace it, import the new certificate as a new version of cloudmersive-tls. The gateway starts using it within a few minutes, and no redeployment is needed.

• Azure portal: open the Key Vault, select Certificates, select cloudmersive-tls, click New Version, and upload the .pfx file.
• Azure CLI: run the following command.

az keyvault certificate import \
  --vault-name <key vault name> \
  --name cloudmersive-tls \
  --file renewed.pfx \
  --password '<pfx password>'

The Key Vault name is shown in the deployment's keyVaultName output. Running the deployment again with a new PFX file has the same effect.

When you used a certificate from an existing Key Vault, renew it in that vault under the same name, and the gateway picks up the new version automatically.

Private endpoints

The private endpoints option places the Key Vault, the container registry and the deployment script's storage account behind private endpoints inside the virtual network, and turns off their public endpoints. The deployment and the services keep working, because they run inside the network.

What changes for you is the Azure portal. The Key Vault's Secrets and Certificates pages and the container registry's Repositories page are read directly from your browser. From a network that is not connected to the virtual network, they show an error saying that public network access is disabled. Renewing the certificate through the Azure portal is then only possible from a computer with access to the virtual network, for example over VPN, ExpressRoute, a peered network or a jump host. Running the deployment again with a new PFX file still works from anywhere.

Turn this option on only if your organization already has private connectivity into its Azure networks. When private endpoints are enabled together with a container registry, the registry must use the Premium SKU. Turning the option off later re-enables public access, but leaves the private endpoints and their DNS zones in place until you delete them.

Removing the deployment

To remove everything, delete the resource group. The cluster's node resource group, which is named <resource group>-<prefix>-aks-nodes, is deleted together with the cluster. Deleting the deployment stops the GPU node's charges, which are the largest part of the cost.

The Key Vault is created with purge protection, so after the resource group is deleted the vault remains in a soft-deleted state for 90 days and its name cannot be reused during that time. If you deploy again within 90 days into a resource group with the same name, use a different name prefix or set a different Key Vault name.