A collection of practical advice for running a cloud-hosted UniFi OS console on the CloudSOE image, on either cloud.
Adopting devices over the WAN
A console in AWS or Azure is not on your devices’ L2 network, so automatic discovery won’t find it. Point each device at the console’s inform endpoint instead. SSH to the device (default UniFi device credentials ubnt/ubnt on factory-fresh hardware) and run:
set-inform http://<console-public-ip>:8080/informThen accept the adoption in the console UI. Two things must be true for this to work:
- port 8080/TCP (and 3478/UDP for STUN) is open from the device’s network to the console,
- the console’s public IP is stable — use an Elastic IP on AWS or a Static public IP on Azure, otherwise every stop/start orphans your devices.
Remote access with your Ubiquiti account
Because you signed in with a Ubiquiti account during the setup wizard, the console can also be reached through Ubiquiti’s remote-access portal without exposing 11443 to the whole internet. If you rely on that, tighten the 11443 rule in your security group / NSG to your own addresses only.
Right-size the instance
The build targets 2 vCPU / 8 GB (t3.large on AWS, Standard_D2as_v4 on Azure) which comfortably runs a console for a typical site. Watch memory first — if htop shows sustained pressure with many devices and clients, step up one size. Disk: the image ships with 40 GB and UniFi OS Server wants roughly 20 GB free, so don’t shrink it, and grow it before long-term statistics fill it up.
Troubleshooting the console
sudo systemctl status uosserver
sudo journalctl -u uosserver --no-pager -n 200
sudo uosserver statusThe console runs as rootless podman containers under the uosserver user created by Ubiquiti’s installer — a restart of uosserver.service restarts the containers cleanly. Updates are handled by uosserver-updater.service; check its journal if the console version looks stale.
Troubleshooting first boot
The only first-boot job on this image is cosmetic: uosserver-firstboot writes the instance’s public IP into the login banner. If the banner still shows a placeholder:
systemctl status uosserver-firstboot
journalctl -u uosserver-firstboot --no-pagerIt’s safe to re-run — remove its marker and restart:
sudo rm /var/lib/uosserver-firstboot.done
sudo systemctl restart uosserver-firstbootThe MOTD shows the wrong IP
The login banner captures the public IP at first boot. If you later attach a new Elastic IP / public IP, the banner will be stale (the console itself is unaffected — but your devices’ inform address is not; see the WAN adoption section above). Edit /etc/motd to update it.
Test the UI from outside
On Azure especially, a VM often cannot reach its own public IP from within. Always verify from your own machine:
curl -skI https://<public-ip>:11443/A 200 or a redirect means the console is up and the self-signed certificate is being served — see the configuration guide for the full port reference.