Deploy to Azure

Deploy Dispatch onto a single Ubuntu 24.04 VM in Azure with one click. An ARM template provisions the VM and networking; on first boot, cloud-init runs the official install.sh, which installs Dispatch (using its bundled SQLite database - no database server to install) as a systemd service with a self-signed dashboard certificate.

This is a plain ARM template, not an Azure Marketplace listing - nothing to install or certify; it just automates a normal VM install. The template and full parameter reference live in deploy/azure/ in the repo.

What it creates

A VM plus a public IP (with a DNS name), NIC, and a network security group - and, unless you choose an existing VNet on the deploy form’s Networking tab, a new VNet. The NSG (attached to the NIC) opens:

Port	For	Open to (default)
22	SSH (admin)	Internet
8420	Dashboard (HTTPS)	Internet
25, 587	SMTP submission (apps to Dispatch)	VNet only
8025	HTTP ingestion API	VNet only

By default the mail-submission ports (SMTP + API) are reachable only from within the VM’s VNet - never the internet. Widen this with the submissionSource parameter (a CIDR, or Internet) only if your apps send from outside the VNet.

Key parameters

• dispatchAdminPassword - the dashboard admin password; you log in with this at https://<host>:8420.
• adminPasswordOrKey + authenticationType - your SSH public key (recommended) or an admin password.
• dispatchVersion - the release to install (default: the current version).
• vmSize - defaults to Standard_B2s (2 vCPU / 4 GB).
• Virtual network - on the Networking tab, choose Create new or Use existing. Picking Use existing gives cascading dropdowns - resource group -> virtual network -> subnet - populated from your subscription, so you select real resources instead of typing names. Selecting an existing VNet never modifies that subnet’s own NSG; the Dispatch rules are attached to the VM’s NIC. From the CLI, set vnetNewOrExisting=existing plus vnetName, vnetResourceGroup, and subnetName (see the deploy/azure/ reference).

After deployment

Install runs on first boot (a few minutes). Then open the deployment’s dashboardUrl output (https://<dns-name>:8420), accept the self-signed-certificate warning, and log in with the admin password you set. Add a relay, then point your apps at the VM’s FQDN on 25/587 (SMTP) or 8025 (HTTP API). SSH in and run journalctl -u dispatch -f to watch the logs.

Azure blocks outbound port 25

Azure blocks outbound TCP 25 by default (anti-spam). This does not affect Dispatch when you relay through a provider’s API or a smart host on 587 - the normal setup. It only matters if you try to deliver directly to recipient mail servers on port 25.

Lock it down for production

The SMTP/API submission ports are restricted to the VNet by default (submissionSource) - never internet-exposed - and Dispatch’s CIDR allow-list defaults to private ranges too, so it is not an open relay. For production, keep submission VNet-scoped (or a tight CIDR), and tighten the NSG source ranges (or the in-app access control) to just the networks your apps send from, and install a real TLS certificate under System -> Settings.

Prefer to build it yourself, or deploy elsewhere? See the Linux install - the Azure template runs exactly that install.sh under the hood.