Applications Azure

ChirpStack on Ubuntu 24.04 on Azure User Guide

Last updated: 2026-07-19 | Product: ChirpStack on Ubuntu 24.04 LTS on Azure

Overview

This image runs ChirpStack 4.19, the leading open source LoRaWAN Network Server, on Ubuntu 24.04 LTS. ChirpStack provides the complete LoRaWAN stack in a single server: the network server and application server, multi tenant device and gateway management, device profiles, adaptive data rate, downlink queueing, MQTT and HTTP integrations, firmware update over the air (FUOTA) and a full gRPC and gRPC web API, all driven from a clean, modern web console. ChirpStack is the control plane your LoRa gateways and sensors connect to.

cloudimg delivers ChirpStack fully installed and reverse proxied behind nginx over HTTPS, with PostgreSQL 16, Redis 7, the Mosquitto MQTT broker and the ChirpStack Gateway Bridge already configured and managed by systemd, so a complete LoRaWAN network server is operational within minutes of launch.

What is included:

ChirpStack 4.19 installed from the official ChirpStack apt repository as native systemd services
PostgreSQL 16 for application and device data, and Redis 7 for device session and device queue state
The Mosquitto 2 MQTT broker, bound to loopback (not exposed to the network)
The ChirpStack Gateway Bridge, which lets real LoRa gateways using the Semtech UDP packet forwarder or BasicStation connect over UDP 1700
The ChirpStack server bound to 127.0.0.1:8080 and fronted by nginx on port 443 with a per VM self signed TLS certificate
Six systemd units enabled and active: postgresql, redis-server, mosquitto, chirpstack, chirpstack-gateway-bridge and nginx
Secure by default: no administrator account and no shared secret ship in the image. ChirpStack's well known default admin / admin login is rotated to a unique per VM password on first boot, along with the database password, the API/JWT signing secret and the TLS certificate, all written to a root only file
A fully patched Ubuntu 24.04 LTS base with unattended security upgrades enabled
24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is the recommended size for evaluation and small networks; for large fleets choose a size with more memory. NSG inbound: allow 22/tcp from your management network and 443/tcp for the web console. Port 80/tcp is optional (it only issues a redirect to HTTPS). If you will connect real LoRa gateways using the Semtech UDP packet forwarder, also allow 1700/udp from your gateways.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for ChirpStack by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTPS (443). Then Review + create then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name chirpstack \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

# Open the HTTPS port so you can reach the web console
az vm open-port --resource-group <your-rg> --name chirpstack --port 443 --priority 900

Step 3 - Retrieve the per VM admin password

Nothing secret is baked into the image. ChirpStack normally ships with a default admin / admin console login; on this image that default is rotated away on the very first boot. A one shot service (chirpstack-firstboot.service) generates a fresh database password, a fresh API/JWT signing secret, a fresh TLS certificate and a unique administrator password, all unique to your instance, and writes them to /root/chirpstack-credentials.txt, readable only by root. SSH in as azureuser and read them:

$ sudo cat /root/chirpstack-credentials.txt
# ChirpStack - generated on first boot by chirpstack-firstboot.service.
# These credentials are unique to THIS VM. Store them somewhere safe.

chirpstack.url=https://20.55.10.42/
chirpstack.admin.user=admin
chirpstack.admin.pass=Xq7pR2mK9wU4nZ8vB3hL6yD1

# Canonical keys consumed by the cloudimg smoke verifier + guide substitution:
CHIRPSTACK_ADMIN_PASSWORD=Xq7pR2mK9wU4nZ8vB3hL6yD1
CHIRPSTACK_URL=https://20.55.10.42/

The rotation service is ordered before the ChirpStack server and the nginx console, so the console only ever becomes reachable once the default password has already been replaced. The username stays admin; the password above is an example, and your instance will have its own unique value.

The chirpstack first boot service is enabled and its script header describing the per VM secret and admin password rotation

Step 4 - Confirm the services are running

Check that PostgreSQL, Redis, Mosquitto, the ChirpStack server, the gateway bridge and nginx are all active:

sudo systemctl is-active postgresql redis-server mosquitto chirpstack chirpstack-gateway-bridge nginx

All six report active. The ChirpStack API and the MQTT broker bind to loopback only (127.0.0.1:8080 and 127.0.0.1:1883); nginx publishes the console on 443 (and a redirect on 80), and the gateway bridge listens for gateways on UDP 1700:

sudo ss -tlnp | grep -E ':(80|443|8080|1883) '

The six ChirpStack services reporting active and the listening ports, with the API and MQTT broker bound to loopback and nginx on 443

Step 5 - Confirm the web console over HTTPS

The console is served over HTTPS on port 443 with a per VM self signed certificate. A request to the HTTPS endpoint returns 200, and the plain HTTP port 80 returns a 301 redirect to HTTPS. The API and MQTT ports are not reachable from the network.

curl -k -s -o /dev/null -w 'HTTPS %{http_code}\n' https://127.0.0.1/

curl -s -o /dev/null -w 'HTTP %{http_code}\n' http://127.0.0.1/

The console returning 200 over nginx TLS, the HTTP port redirecting to HTTPS, and the API and MQTT broker bound to 127.0.0.1

Because the certificate is self signed, your browser will show a certificate warning on first visit; accept it to proceed, or install /etc/nginx/tls/chirpstack.crt as a trusted certificate. Replace it with a certificate for your own domain for production (see the final step).

Step 6 - Sign in to the web console

Browse to https://<vm-ip>/ and sign in as admin with the password from /root/chirpstack-credentials.txt. ChirpStack opens on the login page.

The ChirpStack console sign in page served over HTTPS

After signing in you land on the dashboard, which summarises your active devices, active gateways and device data rate usage, with the Network Server and Tenant navigation down the left. The screenshots in this guide show ChirpStack populated with a small set of example objects; a freshly deployed instance starts empty and ready for you to model your own network.

The ChirpStack dashboard after signing in, showing active device, gateway and data rate summary tiles

Step 7 - Create applications, device profiles and devices

Under Applications you group the devices that share an integration, for example a fleet of environmental sensors or asset trackers. Each application lists its devices with their DevEUI, name and device profile.

The Applications list showing example applications with their descriptions

Open an application to see its Devices tab. A device is identified by its 64 bit DevEUI and is bound to a device profile, which pins the LoRaWAN region (EU868, US915 and so on), MAC version and class. Create device profiles under the tenant's Device Profiles, then add devices to an application and provision their keys for OTAA activation.

An application's Devices tab showing an example device with its DevEUI and device profile

Step 8 - Use the gRPC API

ChirpStack v4 exposes a gRPC and gRPC web API on the same port as the console (there is no separate JSON REST server in the core binary). The image bakes grpcurl so you can drive the API from the shell. Log in with your per VM admin password to obtain a JWT, then pass it as an authorization: Bearer header. This example logs in, lists tenants and lists the applications in the default tenant:

$ PW=$(sudo grep '^CHIRPSTACK_ADMIN_PASSWORD=' /root/chirpstack-credentials.txt | cut -d= -f2-)

$ JWT=$(grpcurl -plaintext -d "{\"email\":\"admin\",\"password\":\"$PW\"}" \
        127.0.0.1:8080 api.InternalService/Login | jq -r .jwt)

$ grpcurl -plaintext -H "authorization: Bearer $JWT" -d '{"limit":10}' \
        127.0.0.1:8080 api.TenantService/List | jq -r '.result[].name'
ChirpStack

$ TID=$(grpcurl -plaintext -H "authorization: Bearer $JWT" -d '{"limit":10}' \
        127.0.0.1:8080 api.TenantService/List | jq -r '.result[0].id')

$ grpcurl -plaintext -H "authorization: Bearer $JWT" \
        -d "{\"tenantId\":\"$TID\",\"limit\":10}" \
        127.0.0.1:8080 api.ApplicationService/List | jq -r '.result[].name'
Asset Trackers
Environmental Sensors

The gRPC API returning a JWT for the per VM admin, then the tenant and application lists

The default admin / admin login is rejected on your instance, and an unauthenticated API call is rejected as well: only the per VM password issues a working token. Use grpcurl -plaintext 127.0.0.1:8080 list to browse the available services (Tenant, Application, DeviceProfile, Device, Gateway and more), and grpcurl ... describe <service> for their methods. You can also create long lived API keys from API Keys in the console.

Step 9 - Connect a LoRa gateway

Real LoRa gateways connect through the bundled ChirpStack Gateway Bridge, which listens for the Semtech UDP packet forwarder on UDP 1700 and translates it to the local MQTT broker. Point your gateway's packet forwarder at this VM's public IP on UDP 1700 (open 1700/udp in the NSG from your gateways first), then add the gateway under the tenant's Gateways using its Gateway EUI. BasicStation is also supported. The Mosquitto broker itself stays bound to loopback, so it is never exposed to the network.

Step 10 - Enable HTTPS with your own domain

The image ships with a per VM self signed certificate so the console works over TLS immediately. For production, point a DNS record at the VM's public IP and replace the certificate at /etc/nginx/tls/chirpstack.crt and /etc/nginx/tls/chirpstack.key with a certificate for your domain (for example one obtained with certbot, or terminate TLS at Azure Application Gateway in front of the VM). Reload nginx after replacing the certificate:

$ sudo systemctl reload nginx

Administration and support

The ChirpStack configuration lives in /etc/chirpstack/ (chirpstack.toml plus the per region region_*.toml files); enable or disable LoRaWAN regions with the network.enabled_regions list and restart with sudo systemctl restart chirpstack. The gateway bridge configuration is in /etc/chirpstack-gateway-bridge/. The admin password and every per VM secret live in /root/chirpstack-credentials.txt.

This image is a repackaged open source software product with additional charges for cloudimg support services. Our engineers provide 24/7 support for deployment, upgrades, TLS termination with your own domain, gateway onboarding, MQTT exposure and integration, LoRaWAN region configuration and scaling. ChirpStack is a trademark of its respective owner; use of the name here is purely to identify the software this image packages.