How to Deploy OpenClaw on Azure - Bastion and Linux VM Guide

The Azure guide stands out because it bakes network hardening into the setup instead of treating it as cleanup. OpenClaw documents an Azure Linux VM deployment that uses Azure CLI, a VNet with subnet-level NSG rules, and Azure Bastion so the VM itself does not need a public IP address.

What the official docs support

The docs cover end-to-end Azure provisioning: resource providers, resource group, NSG, VNet, VM subnet, AzureBastionSubnet, Bastion public IP, the VM itself, and the OpenClaw installer. That makes it a strong guide if you want a plain VM deployment but still want your cloud networking posture to start from a safer place.

I would use this path when a team already runs in Azure and wants a deploy that matches enterprise network habits. Bastion-only SSH access, explicit NSG priorities, and no public IP on the VM give you a much cleaner story than dropping a management dashboard onto the internet and hoping auth carries the whole risk budget.

What you need first

• An Azure subscription with compute and network permissions
• Azure CLI plus the ssh extension
• An SSH key pair
• About 20 to 30 minutes for infrastructure and install

Recommended setup flow

The pattern is create the network first, then the VM, then use Bastion to install OpenClaw without ever giving the VM a public IP.

1. Sign in with az login, install the ssh extension, and register the Microsoft.Compute and Microsoft.Network providers if your subscription has not used them before. The docs tell you to wait until both providers show Registered before moving on.
2. Set your deployment variables for resource group, location, VNet CIDRs, NSG name, VM name, Bastion names, and SSH key. The docs also call out that AzureBastionSubnet must be at least /26, which is the sort of requirement worth honoring up front.
3. Create the NSG and add the documented inbound rules so SSH from the Bastion subnet is allowed while SSH from the public internet and the rest of the VNet is denied. The guide explains the priority ordering clearly, which helps when you audit the rule set later.
4. Create the VNet, attach the NSG to the VM subnet, create the VM with no public IP, and then provision Azure Bastion with Standard SKU and tunneling enabled. The Bastion deployment can take a while, so this is the part where patience is normal.
5. Use az network bastion ssh to reach the VM, run the OpenClaw install script inside the shell, and verify with openclaw gateway status after onboarding finishes. From there you can continue hardening or adding channels through the normal OpenClaw flow.

az login
az extension add -n ssh
az provider register --namespace Microsoft.Compute
az provider register --namespace Microsoft.Network

Access, safety, and operational notes

The biggest Azure-specific win in the docs is that the VM itself stays off the public internet. Bastion handles managed SSH, and your NSG rules only allow that Bastion subnet to reach port 22. That keeps remote administration much tighter than a normal public-IP VM setup.

The guide also nudges you to choose VM size and disk size based on workload rather than habit. Azure regions and quotas vary, so the docs explicitly recommend listing available SKUs and checking usage quotas before you assume a favorite size will actually be available.

How to verify it is working

After installation, verify the gateway locally on the VM, then validate that your Bastion SSH path still works after a logout and reconnect. That confirms both the OpenClaw install and the Azure access model are stable enough for ongoing operations.

Common gotchas

• Azure Bastion provisioning can take several minutes, which is normal
• The VM should be created without a public IP in the documented setup
• The Bastion subnet must be sized correctly, at least /26

If you want the operator version with tighter rollout checklists, safer defaults, and more production patterns, The OpenClaw Playbook is the easiest shortcut.