If a Proxmox host is already humming away in your rack, adding a UniFi controller feels like a non-event: just one more VM. Technically that holds up – Ubiquiti explicitly lists virtual machines as a platform for the UniFi OS Server. In practice, a handful of details decide whether the install runs quietly for years or keeps costing you afternoons: how the VM is attached to the network, how you handle snapshots and clones, and who is awake when the host goes down. This guide walks through the documented path to running UniFi OS Server on Proxmox and is honest about where the limits are.
What Ubiquiti actually says about virtualisation
UniFi OS Server is the current self-hosting software and replaces the older UniFi Network Server. Ubiquiti describes it as something you can deploy on x86, x64 and ARM64 servers, in virtual machines or on edge appliances – choosing CPU, memory and storage to match your workload, and using virtualisation clusters for high availability. So virtualisation is not a grey area; it is an intended deployment model.
One expectation to set straight, though: Ubiquiti documents installation per operating system, not per hypervisor. There is no official Proxmox walkthrough and no Ubiquiti-provided Proxmox image. You install a supported Linux in a VM and UniFi OS Server inside it – everything below that line is your responsibility.
What the VM needs
The minimum requirements are modest. Translated into Proxmox terms:
| Resource | Ubiquiti’s requirement | In Proxmox |
|---|---|---|
| CPU | x86-64 processor (ARM64 is supported as well) | 2 vCPU is a sensible starting point |
| Memory | at least 2 GB | assign it fixed rather than ballooning down to the floor |
| Storage | at least 10 GB free | plan generously – logs and statistics grow |
| Network | wired Ethernet, 100 Mbps | virtio NIC on a Linux bridge |
| Operating system | Ubuntu 24.04 or later, Debian 13 or later, or a comparable modern distribution | a lean server install, no desktop |
Ubiquiti notes that the specification has to scale with the number of devices you adopt and manage. Treat the minimums as a floor, not a target – the upside of a VM is precisely that you can add RAM and disk later.
Installation step by step
- Create the VM: Debian 13 or Ubuntu 24.04 as a server install, NIC set to
virtio, attached to bridgevmbr0(more on that below). Give it a static address or a DHCP reservation – that IP will show up again in adoption and firewall rules. - Install the dependencies: UniFi OS Server requires Podman and slirp4netns (1.2 or newer):
sudo apt-get update && sudo apt-get install podman slirp4netns - Fetch the installer: copy the download link for your architecture from Ubiquiti’s official download or releases page and pull the file into the VM with
curlorwget. - Make it executable and run it:
chmod +x <installer>sudo ./<installer> - Initial setup in the browser: open the console, create your account, set up the network application, then adopt your devices.
Budget for the things Proxmox does not hand you: unattended security updates inside the guest, reliable time synchronisation, and monitoring that tells you when the service stops answering.
Networking: bridge it, don’t NAT it
This is where virtualised controllers most often come apart. UniFi devices are normally found through Layer 2 discovery, which means the controller and the devices have to sit in the same broadcast domain. Put the VM behind a NAT bridge or in its own routed segment and your access points simply will not see it.
The clean approach is a Linux bridge that places the VM directly into the management VLAN where your UniFi devices live. If your Proxmox host works with VLAN tags, set the matching tag on the virtual NIC.
If the controller genuinely has to live in a different subnet, Layer 3 adoption is the answer: SSH into the device and run set-inform http://<host-ip>:8080/inform, use DHCP option 43 with the controller’s address, or – on supported models – zero-touch provisioning. Our guide to Layer 3 adoption of UniFi access points covers the details.
Ports that have to be open
For discovery, adoption and the guest portal, TCP 8080, TCP 8843, UDP 3478 and UDP 10001 need to be reachable on the guest – in the VM’s own firewall and, if you use it, in the Proxmox firewall too. These belong on your local network, not on the internet.
For remote management through the UniFi Site Manager, the VM needs outbound connections on TCP 443 and TCP 8883. No inbound port forwarding is required. If a firewall or your ISP’s equipment blocks that outbound path, Site Manager cannot reach the self-hosted instance.
The limits – four things worth knowing
1. Never clone a VM running UniFi OS Server
This is the Proxmox-specific trap, because cloning and templates are everyday tools there. Ubiquiti states plainly that VMs running UniFi OS Server should not be cloned, except for high-availability or failover installations. The reason: cloned VMs reuse the same remote access tokens for Site Manager and Fabrics, which leads to unexpected behaviour. If you need a second instance, build it fresh instead of duplicating an existing one.
A template of the bare operating system before the UniFi install is unaffected – so clone the empty guest at most, never the finished controller.
2. Snapshots are not backups
A Proxmox snapshot captures machine state on the same host and is genuinely useful for rolling back a bad update. It does nothing for you if the host or its storage fails. Ubiquiti provides its own system backups, which you enable and restore under Settings > Control Plane > Backups; automated backups are generated weekly and ahead of major updates. Use both – and keep the backup somewhere that does not die with the host. Our guide on backup and restore goes deeper.
3. The controller has to run continuously
Ubiquiti is unambiguous here: to view and manage adopted devices, the UniFi OS Server must keep running at all times. If it goes offline, devices carry on with their last known configuration – but management, statistics and any changes are gone. If you cannot guarantee continuous operation, Ubiquiti itself points to a Cloud Key or hosted UniFi as the alternative.
For Proxmox that means the controller inherits every risk of the host: maintenance windows, a power cut at the site, a dead uplink. A high-availability cluster softens that, but adds hardware and maintenance of its own.
4. Support stops at the VM boundary
Ubiquiti documents UniFi OS Server for the listed operating systems. Everything underneath – hypervisor, bridge, storage, backup chain, host updates – is Proxmox territory, and therefore yours. When something breaks, you first have to work out whether it is UniFi or the platform. Our breakdown of the real cost of self-hosting shows how that effort adds up over three years.
When Proxmox is the right call – and when it isn’t
| Makes sense on Proxmox | Think twice |
|---|---|
| The host already runs 24/7 and is actively maintained | The host is a lab box that gets switched off |
| Virtualisation know-how and monitoring exist in-house | The network is looked after on the side, with no clear owner |
| Data is meant to stay on-premises by policy | The site has no dependable power or internet |
| Controller and UniFi devices share the same network | Multiple sites with no permanently reachable central location |
| Backup and restore are established and tested | Nobody wants to be on call for the controller at night |
Conclusion
UniFi OS Server runs well in a Proxmox VM – provided you bridge it into the right network, keep the required ports open, never clone the finished instance, and treat snapshots as a supplement rather than a backup. What Proxmox will not do for you is the day-to-day operation: host updates, monitoring, restore tests, and the question of who responds when nobody can reach the console on a Sunday evening.
If you want to keep control of the configuration but hand over the operations, we host managed UniFi controllers in a German data centre – GDPR-compliant, with updates, backups and monitoring included. Get in touch and we’ll tell you whether a move makes sense for your network.
Frequently asked questions
Does Ubiquiti officially support running UniFi OS Server in a VM?
Yes. Ubiquiti explicitly names virtual machines as a platform for UniFi OS Server, alongside x86, x64 and ARM64 servers and edge appliances. Installation is documented per operating system rather than per hypervisor, though – there is no dedicated Proxmox guide from Ubiquiti.
Why can’t my access points find the controller in the VM?
Usually it’s the VM’s network mode. Standard adoption relies on Layer 2 discovery, which requires the controller and the devices to share a broadcast domain. Bridge the VM into the management VLAN – or use Layer 3 adoption via set-inform, DHCP option 43 or zero-touch provisioning.
Can I clone the VM as a template for more installations?
No. Ubiquiti says VMs running UniFi OS Server should not be cloned, except for high-availability or failover installations, because cloned VMs reuse the same remote access tokens for Site Manager and Fabrics and behave unpredictably. Set up additional instances from scratch.
Is a Proxmox snapshot enough as a backup?
Not on its own. A snapshot lives on the host and is worthless if the host or its storage fails. Also enable the system backups under Settings > Control Plane > Backups and keep a copy in a second location.
How much should I actually give the VM?
The documented floor is an x86-64 processor, 2 GB of RAM, 10 GB of free storage and a wired 100 Mbps connection. Ubiquiti notes the specification has to grow with the number of managed devices, so plan RAM and storage with headroom from the start.
