Install AutoMQ on Azure

Overview

Before using AutoMQ BYOC, install the AutoMQ console in your Azure subscription. You use the console to create, manage, and monitor AutoMQ clusters. Starting from 8.x, the AutoMQ console is distributed and started as a Docker image. New environments should use this Docker installation process. For an existing 7.x environment, see Azure BYOC Console Upgrade Guide to v8.x.

Prerequisites

Prepare the following resources:

An Azure subscription and Resource Group.
A Virtual Network and a Subnet for the console VM. The Subnet must reach the Docker registry and AutoMQ Cloud. If the VM has no Public IP, configure a NAT Gateway or another egress path.
A dedicated User-assigned Managed Identity for the console (Console UAMI).
Network access from an approved operations source to port 8080 on the console VM.

Steps

Step 1: Register the environment in AutoMQ Cloud

Sign in to AutoMQ Cloud.
Create an Azure BYOC Environment and follow the wizard to enter the environment name, Region, and related information.
Copy the complete Docker startup command generated by the installation wizard.

The command contains the complete Base64 CONFIG, CLOUD_PROVIDER=azure, initial administrator settings, and exact image address. Run the generated command directly. Do not decode, split, or manually assemble CONFIG.

Step 2: Prepare the console VM

Check the VM configuration

Create an Ubuntu VM in the prepared Subnet. We recommend:

At least 2 vCPUs, 8 GiB memory, and a 20 GiB system disk.
A separate persistent disk mounted at a stable host path for console data. Configure automatic mounting after a VM restart, and confirm that the directory exists and is writable by Docker before starting the console.
Egress to the Docker registry, AutoMQ Cloud, and Azure APIs.
Ingress to TCP 8080 only from approved operations networks.

Create and bind the Console UAMI

Create a dedicated Console UAMI and bind it to the console VM. The following Azure CLI commands are an example:

RESOURCE_GROUP="<console-resource-group>"
IDENTITY_NAME="<console-uami-name>"
VM_NAME="<console-vm-name>"

az identity create --resource-group "$RESOURCE_GROUP" --name "$IDENTITY_NAME"
CONSOLE_UAMI_ID=$(az identity show \
  --resource-group "$RESOURCE_GROUP" \
  --name "$IDENTITY_NAME" \
  --query id -o tsv)
az vm identity assign \
  --resource-group "$RESOURCE_GROUP" \
  --name "$VM_NAME" \
  --identities "$CONSOLE_UAMI_ID"
az vm show --resource-group "$RESOURCE_GROUP" --name "$VM_NAME" --query identity

The VM must use this Console UAMI as the only Managed Identity caller for the console. The az vm identity assign command adds an identity; it does not remove an existing system-assigned identity or other UAMIs. Review the final az vm show output and remove other VM identities before startup unless the generated configuration explicitly selects the Console UAMI. Grant the later System Initialization permissions to this identity.

Install and start Docker

sudo apt-get update
sudo apt-get install -y docker.io
sudo systemctl enable --now docker
sudo docker version

Start the AutoMQ console

Run the complete Docker startup command from Step 1. Before running it, confirm that its host mount source is on the mounted persistent disk and that the container target remains /root. Otherwise, rebuilding the VM or replacing its system disk can lose console data. Check the container after startup:

sudo docker ps
sudo docker logs -f "<container-name-or-id>"

When the container is healthy and port 8080 is reachable, open the AutoMQ console in your browser. Sign in with the initial administrator credentials from the generated command and reset the bootstrap password when prompted.

Step 3: Complete System Initialization

After the first login, open System Initialization and use the Terraform configuration generated on that page to grant permissions to the existing Console UAMI. The generated configuration does not create or replace the Console UAMI. The roles, scopes, and commands shown on the page are the source of truth for the current release. The generated permissions follow these boundaries:

Permission group	Scope	Purpose
Required resource discovery	Subscription	Read-only discovery of Resource Groups, AKS, VM/VMSS, VNet/Subnet, Storage, Private DNS, UAMI, and role metadata.
Required Blob data access	The specified Ops or Data Blob container	Reads, writes, and deletes Blob objects used by AutoMQ.
Required AKS access	The specified AKS cluster	Reads the AKS cluster and obtains a `clusterUser` credential. It does not grant Kubernetes API management permissions.
Customer-Provided DNS records	The specified Private DNS Zone	Reads the VNet link and manages the A/CNAME records owned by an Instance.
Managed resource lifecycle	Console Resource Group	When Managed resources are selected, creates and maintains Storage, Private DNS, UAMI, and Federated Identity Credential resources.
Managed RBAC delegation	Subscription, with the condition generated by the page	When Managed resources are selected, allows the console to create only the role definitions and ServicePrincipal role assignments required by AutoMQ.

AKS credential access and Kubernetes authorization are separate. If Azure RBAC for Kubernetes Authorization is enabled, grant the Console UAMI the Kubernetes role shown by the console at the target AKS scope. Otherwise, have a cluster administrator create and maintain the required Kubernetes ClusterRoleBinding. See Deploy to Azure AKS for both authorization paths. Apply only the permissions generated for the selected resource mode and scopes, then return to System Initialization to verify them. Resources selected later during Instance creation may require additional permissions scoped to those resources. Do not grant those permissions in advance, and do not replace the generated least-privilege roles with Subscription-level Contributor.

Terraform quick start

To prepare the console, AKS, and example resources together, see the AutoMQ Azure Terraform example. The example is intended as a quick start. Before production use, restrict network access, protect Terraform state, and review all custom roles and scopes against your organization policy.

Next steps

Deploy to AKS: See Deploy to Azure AKS to prepare AKS and Azure Workload Identity and create an AutoMQ Instance.
Use AutoMQ through the WebUI: See Experience AutoMQ to create and manage an Instance.
Use AutoMQ through Terraform: See the AutoMQ Terraform Provider to manage AutoMQ resources.

Overview

Getting Started

Deploy on Kubernetes

Subscriptions and Billings

Manage Environments

Manage Identities and Access

Managing AutoMQ

Migrate to AutoMQ

Manage Security

Kafka Connect

Monitoring & Alert

Table Topic

Best Practice

Eliminate Inter-Zone Traffics

Release Notes

Support

Appendix

Overview

Prerequisites

Steps

Step 1: Register the environment in AutoMQ Cloud

Step 2: Prepare the console VM

Check the VM configuration

Create and bind the Console UAMI

Install and start Docker

Start the AutoMQ console

Step 3: Complete System Initialization

Terraform quick start

Next steps

​Overview

​Prerequisites

​Steps

​Step 1: Register the environment in AutoMQ Cloud

​Step 2: Prepare the console VM

​Check the VM configuration

​Create and bind the Console UAMI

​Install and start Docker

​Start the AutoMQ console

​Step 3: Complete System Initialization

​Terraform quick start

​Next steps

Overview

Prerequisites

Steps

Step 1: Register the environment in AutoMQ Cloud

Step 2: Prepare the console VM

Check the VM configuration

Create and bind the Console UAMI

Install and start Docker

Start the AutoMQ console

Step 3: Complete System Initialization

Terraform quick start

Next steps