#Azure VM settings

8 messages · Page 1 of 1 (latest)

sterile thunder
#

I'm going to deploy OpenClaw on an Azure VM, and I'd like to know the recommended deployment settings: Image, size, inbound ports, authentication type, etc.

wanton riverBOT
#

Recommended Azure setup, based on the OpenClaw docs:

  • Image: Canonical:ubuntu-24_04-lts:server:latest
    • If you want reproducibility, pin a specific image version instead of latest.
  • VM size: Standard_B2as_v2 is the documented starter size
    • Good default for light to moderate use.
    • Scale up if you plan heavier automation, lots of channels, or extra services.
  • Disk: 64 GB OS disk, StandardSSD_LRS
  • VM public IP: none
    • The docs recommend no public IP on the VM.

Inbound ports / network

  • 22/TCP only from Azure Bastion subnet
  • Deny SSH from Internet
  • Deny SSH from other VNet sources
  • Do not expose port 18789 publicly
    • Keep OpenClaw bound to loopback
#
  • Access it via Azure Bastion + SSH, or Tailscale/SSH tunnel

Auth

  • VM login: SSH key auth, preferably ed25519, not password auth
  • Gateway auth: token auth is the safest default
    • gateway.auth.token / OPENCLAW_GATEWAY_TOKEN
    • Password auth is supported, but token is the better default
  • Model/provider auth: for an always-on VM, API keys are the most predictable
    • If your org already has it, the Azure guide specifically calls out GitHub Copilot as a nice option

My practical recommendation

  • Ubuntu 24.04 LTS
  • Standard_B2as_v2
  • 64 GB Standard SSD
  • No public VM IP
  • Azure Bastion for admin access
  • Gateway on loopback only
#
  • Token auth for the gateway
  • Provider API key auth on the VM

One important Azure-specific note: Azure Bastion Standard is expensive, often more than the VM itself. If cost matters, that’s the first thing I’d reconsider.

Docs:

If you want, I can also turn this into a copy-paste Azure portal checklist.

sterile thunder
#

So inbound port rules should have public inbound ports set to None?
Many of the options you listed is not in the VM initial settings. This will be something only people on our domain/VPN should be able to connect to. The create virtual machine settings list Authentication type (SSH public key or password), Username, SSH public key source, SSH Key type, Key pair name, and inbound port rules. There is also a security type to select, with the options being standard, trysted launch virtual machines, and confidential virtual machines. Any direction on those?

wanton riverBOT
#

Let me check Azure’s current security type guidance so I don’t hand-wave that part.

#

Yes, for that Azure Create VM screen, I’d set Public inbound ports = None.

If this is only for people on your domain/VPN, my recommended choices are:

  • Authentication type: SSH public key
  • Username: any non-root admin user, for example openclaw or azureuser
  • SSH public key source:
    • Use existing public key if your org already manages SSH keys
    • otherwise Generate new key pair
  • SSH key type: Ed25519 if Azure offers it, otherwise RSA
  • Key pair name: anything descriptive, like openclaw-prod-key

Security type

  • Trusted launch virtual machines = best default
  • Confidential virtual machines = only if you specifically need confidential-computing / stronger isolation and are okay with extra cost + size/image constraints
  • Standard = only if Trusted Launch causes compatibility issues with your chosen image/size
#

So in practice: pick Trusted launch.

Inbound/networking

  • In the initial VM wizard: Public inbound ports = None
  • After deployment, if you need private access over VPN:
    • allow TCP 22 from your VPN/private CIDR
    • do not open 18789 publicly
    • honestly, I’d still keep OpenClaw on loopback and use SSH tunnel rather than exposing 18789 directly, even on a private network

Image / size

  • Image: Ubuntu 24.04 LTS
  • Size: Standard_B2as_v2 is the documented starter default
  • Disk: 64 GB SSD is a sensible default

So the short version for the Azure form is:

  • Image: Ubuntu 24.04 LTS