Ubiquiti’s UniFi networks are everywhere: offices, professional firms, hospitality, manufacturing. And everywhere the same question keeps getting postponed: where should the controller run? On the CloudKey in the rack, on a virtual machine, on Ubiquiti’s official hosting or on a managed service? It is not a detail for tinkerers: the controller is the management plane of the entire network, and where it lives determines who updates it, who backs it up and where its data ends up. Let us look at the four options with honest pros and cons — and the criteria for choosing.
The controller is a critical asset, not an accessory
It is worth being explicit about what actually lives inside a UniFi controller, because «the network configuration» does not do it justice. Inside there are three categories of sensitive things:
- The people. Every connected device is tracked by MAC address and associated access point, with timestamps: the controller knows who is on site, since when, and in which area of the building — employees, owners, guests. This is not abstract telemetry: it is a presence and movement map of people, with GDPR implications and sensitive angles under workplace remote-monitoring rules.
- The cameras. Where the ecosystem includes UniFi Protect, access to the console is also access to the video surveillance: live views and recordings. Whoever gets into the management platform sees what the cameras see.
- The defences. Firewall rules, routing rules, access policies, VPNs, segmentation: the controller and the gateway are the complete map of how the company defends itself — and, read in reverse, of how to attack it. Plus the network configuration: SSIDs, VLANs, users, captive portal.
Whoever compromises the controller has not breached «a management tool»: they know where the people are, they see the cameras and they know the defences. Whoever loses it without a backup rebuilds everything by hand. That is the level of criticality with which to decide where it runs and who answers for it.
That this is no theoretical risk is confirmed by the May 2026 Operational Summary from CSIRT Italia, which reports five critical CVEs in UniFi OS — the platform behind UDM, UDM-Pro, UDM-SE, UDR, UNVR and Cloud Gateway. Like any management software, the controller needs disciplined patching: a controller installed once and forgotten in the rack is exactly the kind of legacy system attackers look for.
The four options compared
| Option | Who updates | Who backs up | Where the data lives | Best for |
|---|---|---|---|---|
| CloudKey / on-site hardware | You | You | On site | Small networks with a real IT owner |
| Self-hosted (UniFi OS Server) | You (OS + controller) | You | Wherever you choose | Structured IT teams, multi-site |
| Official UniFi Hosting | Ubiquiti | Ubiquiti | US provider (CLOUD Act); region not selectable | Zero hardware, self-managed network |
| Managed by a European IT provider | The provider | The provider | Provider’s cloud, in the EU under EU jurisdiction | Delegating controller and network |
The first two options fit in one line: on-site hardware is another device to maintain (and if ransomware encrypts the network, the management plane goes with it); self-hosting makes you the service provider, and holds only if that responsibility has an explicit owner. For most companies, the real choice is between the last two — and there the difference is not technical: it is jurisdiction.
Jurisdiction: Ubiquiti is American, and it matters
Ubiquiti is a US company. Official UniFi Hosting is therefore a service run by a provider subject to US jurisdiction — with one precise consequence: the CLOUD Act, the 2018 federal law, allows US authorities to order a provider under their jurisdiction to hand over the data it holds, wherever the servers are physically located. This is not legal hair-splitting: read against the list above — the presence map of people, the cameras, the firewall rules — it means that data ultimately answers to a non-European legal system.
What changes if you entrust the controller to an Italian or European companycertified to ISO/IEC 27001, 27017 and 27018, with data in EU datacentres? Three concrete things. First: the provider answers to European jurisdiction — a foreign authority’s request cannot be imposed on it directly, and goes through judicial cooperation channels. Second: the processing stays entirely within the GDPR perimeter, with no extra-EU transfer to justify — easier to write in the records of processing and to defend in a DPIA. Third: ISO/IEC 27018 specifically governs the protection of personal data in the cloud — exactly the category of data the controller holds.
Said without flag-waving: for many companies the provider’s jurisdiction is irrelevant, and that is a legitimate choice. But for those with constraints — enterprise clients running due diligence, public sector, employee presence data and video surveillance — knowing which law can reach your data is the deciding criterion, before any technical comparison. One operational note: even with the controller in Europe, remote access via unifi.ui.com goes through the Ubiquiti cloud account — it is optional, and those who want the full perimeter disable it and access locally or over VPN.
The criteria that really matter
Who takes the backups — and where they end up
The controller backup is the most important asset of the network, and it must live outside the controller itself. A backup that only exists on the device it is supposed to protect is not a backup.
Who applies the updates
May’s five CVEs do not patch themselves — and not at 2 a.m. when it suits you, unless someone schedules it. Patching needs an owner, with a calendar.
Where the data resides — and who can reach it
Not just network data: the presence map of people, guest data and, with Protect, the video surveillance. Residency (EU?) and the provider’s jurisdiction both matter: US providers are subject to the CLOUD Act, wherever the servers are.
Who manages the network
Hosting solves where the software runs, not who answers when the warehouse Wi-Fi disappears. If the answer is "nobody", hosting is not the problem.
The practical traps, from field experience
Four things you learn by managing UniFi networks, not by reading brochures.
- Autobackups live on the controller.By default, automatic backups stay on the controller’s own disk: lose the machine and you lose them too. They must be copied out — to separate storage or the cloud — on a schedule, not by hand when someone remembers.
- Controller and firmware must be updated in the right order.Controller first, then device firmware: a controller that is too old will not recognise new access points, and firmware that is too new may not talk to a controller frozen for years. This is why «I don’t update it so nothing breaks» eventually breaks.
- Migration is painless only when prepared. Moving the controller (CloudKey to VM, VM to cloud) is done with a site export and device re-adoption; when automatic adoption does not latch, you fall back to set-inform via SSH on the individual device. With a good backup it is half a day; without one, it is a reconfiguration.
- Wi-Fi survives without the controller, the services do not. If the controller stops, access points keep broadcasting with their last configuration — which is exactly why the problem goes unnoticed for weeks. But captive portal, vouchers, statistics and provisioning stop immediately: you notice the day you need them.
The fourth option, taken all the way
For completeness, our model: the controller in our European cloud on ISO/IEC 27001 infrastructure, with network management around it — and controller backups treated like any serious backup: off the machine, verified, restorable. For clients with a management contract, controller hosting is included.
Sources
- Ubiquiti Help Center — «Getting Started with Official UniFi Hosting» and «Self-Hosting a UniFi Network Server»
- ACN / CSIRT Italia — Operational Summary May 2026 (24 June 2026)
Read more
Frequently asked questions
Answers to the most common questions about where and how to host the UniFi controller.
For a business network, effectively yes. Individual access points can run standalone from the app, but without a controller you lose centralised management, provisioning, statistics, optimised roaming, coordinated updates and multi-site configurations. The controller is the management plane of the network: the question is not whether to have one, but where it runs and who takes care of it.
No: access points and switches already adopted keep working with the last configuration they received. But you lose everything else: management, statistics, alerts, provisioning of new devices, captive portal and vouchers if used. And above all: a controller that is off receives no security updates. Best practice is a controller that is always on, updated and monitored.
You start almost from scratch: devices must be re-adopted and the configuration — networks, VLANs, SSIDs, rules, users — rebuilt by hand. The controller backup (.unf file, or scheduled automatic backups) is the most important asset of the entire UniFi network: it must be taken regularly and stored outside the controller itself. It is the first thing we check when we take over an existing network.
For many organisations it is a legitimate, convenient option: no hardware, access from unifi.ui.com, up to 1,000 devices. Three things to weigh: the documentation does not state where the data resides nor lets you choose the region (a real issue for those with GDPR or contractual data-residency constraints); control over update timing is limited; and above all it remains hosting, not management — configuration, hardening, monitoring and the network lifecycle stay with you.
The controller runs in our European cloud, on infrastructure managed according to ISO/IEC 27001: automatic backups, scheduled updates, monitoring and secure access, with no CloudKey or on-site server to maintain. But the point is not just hosting: we manage the network — configuration, segmentation, device firmware, alerts. For clients with a management contract, controller hosting is included in the service.