In many UniFi installations the Cloud Key is the heart of the network — and the single point everything depends on. When that small box dies, disappears from the server room or simply loses power, the first question is always the same: is the whole network down now? The good news first: no. The bad news: without a plan, a hardware failure turns into a full day of manual work. This guide explains what a UniFi Cloud Key failure actually breaks, what to do first, and how to move your network to a controller that needs no local hardware at all.
What actually happens when the Cloud Key dies
Access points, switches and gateways do not stop working just because the controller is gone. Ubiquiti’s own documentation is clear about this: if the host is unreachable, adopted devices keep running on the last configuration they received. SSIDs stay on air, VLANs stay in place, clients keep connecting.
What you lose is the management layer — and you miss it faster than you’d expect:
- No configuration changes: no new SSID, no firewall rule, no port profile adjustment.
- No adoption of new or factory-reset devices.
- No firmware updates.
- No statistics, no client list, no alerts — you’re running blind.
In other words: you have time, but not unlimited time. As long as nothing else breaks, the network carries on. The moment an access point reboots badly or someone resets a device, there is no instance left to pick it back up.
The first steps after the failure
Before you order replacement hardware, settle three questions.
1. Is it really the Cloud Key?
A controller showing up as offline isn’t automatically dead. Check power and the PoE port, the patch cable, the switch port, and whether the device still pulls an IP address via DHCP. A stalled update looks exactly like a total loss from the outside.
2. Where is your backup?
This is the question everything else hangs on. There are two kinds of backup, and they lead to different recovery paths:
- System backups (cloud): if enabled under Settings > Control Plane > Backups, UniFi automatically creates a cloud backup every week and before each major update. Those backups are stored in the UI account of the console owner, and only the owner can manage them. You can review all backups linked to an account at
account.ui.com/backups. - Network backup (*.unf): the backup file of the UniFi Network application, downloadable from the same Settings > Control Plane > Backups page. It holds your network configuration and is the key to migrating onto any other Network host.
The catch applies to both: you can only download them while the console is still running. After the failure, you are left with whatever was saved automatically beforehand. Our guide on UniFi controller backup and restore covers this in more detail.
3. Failure or theft?
If the Cloud Key was stolen, this is no longer purely a hardware issue. The device holds your network configuration including wireless settings and client data, which makes it something your security and data protection process should see. Treat the credentials as compromised: rotate wireless passphrases, review admin accounts, disconnect affected accounts. Restoring operations and handling the security incident are two separate jobs — but both land on your desk.
Path 1: replace the hardware
The obvious route: buy a new console, restore the backup, carry on. Ubiquiti supports this explicitly, including across models — but if you move to a different model of Cloud Gateway, Cloud Key or UNVR, the new device must run UniFi OS 3.1 or higher. You can restore the backup during the setup process or afterwards under Settings > Control Plane > Backups. If you don’t want everything back, uncheck “Restore All Applications and Settings” and pick individual apps, settings and admin configurations instead.
Two limitations are worth knowing. First, existing Protect recordings cannot be transferred between UniFi consoles — they stay on the original host until its storage is removed or reformatted. With a dead or stolen device, that footage is effectively gone. Second, you are buying the same single point of failure a second time.
Path 2: a controller without local hardware
The controller doesn’t have to sit in your server room. The UniFi Network application runs just as well on a server in a data centre — self-managed or as a hosted, managed controller. Your on-site network then consists only of devices that hold nothing irreplaceable: if an access point fails, you swap it and the controller reconfigures it. A second Cloud Key simply isn’t needed.
Restoring the backup
The documented route is to restore the Network backup file (*.unf) into the new Network application under Settings > Control Plane > Backups. Make sure the target application is up to date — a backup from a newer version cannot be restored into an older installation, so check version numbers before you start.
Pointing your devices at the new controller
This is where a planned migration and an emergency differ. In a planned move, you enable the “Override Inform Host” toggle in the old Network application and enter the address of the new host, telling your devices where to report from now on. If the Cloud Key is dead or stolen, that old application no longer exists — so the devices have to learn about their new controller some other way.
Ubiquiti documents this as Layer 3 adoption. The prerequisite in every case is unrestricted connectivity between device and Network application over TCP port 8080. Helpfully, a UniFi device cycles through all available inform options — whichever responds first adopts it.
| Method | How it works | Best when … |
|---|---|---|
| DNS record | Make your local DNS resolve the hostname unifi to the new Network host | … you control local DNS — the cleanest option |
| DHCP option 43 | Hex-encoded on most third-party firewalls: by IP, e.g. 0104c0a8030a for 192.168.3.10, or the inform URL as a hex string | … you need to move many devices at once |
| SSH / set-inform | Run set-inform http://<host>:8080/inform on the device | … it’s a handful of devices and you’re on the local network |
For the SSH route you need the device credentials. UniFi network devices have SSH enabled by default; before adoption the defaults are ui/ui (ubnt/ubnt on older devices), and after adoption the controller assigns a random string. You’ll find those credentials in the Network application under UniFi Devices > Device Updates and Settings > Device SSH Authentication — so they come back with your restored backup. Our guide to Layer 3 adoption walks through every method.
When a device reports “Managed by Another Console”
This message appears when a device still considers a different UniFi instance to be its owner — for example after a console was restored. Ubiquiti lists several ways out: restore the console from a backup in which the device was already managed; factory reset the device and re-adopt it; or reassign it through the UniFi Network mobile app — which only the account owner can do, and only if they previously signed into the app while the device was managed.
For a factory reset, hold the reset button for 5 to 10 seconds until the LEDs indicate the restore has begun, keeping the device powered throughout. One detail matters here: the physical reset button does not remove the device from the applications it was adopted to — that is done through the “Manage” section of the device settings.
No backup at all — now what?
Without a backup the configuration is gone, but the hardware isn’t. The route is: set up a new controller, factory reset every device, re-adopt them, then rebuild SSIDs, VLANs, firewall rules and port profiles. Tedious but doable — for a mid-sized network, plan in hours rather than minutes, and document as you go this time.
Making the next failure a non-event
You can’t prevent hardware from failing, but you can decide what it costs you:
- Enable system backups. A single checkbox under Settings > Control Plane > Backups decides whether a hardware defect costs an hour or a day.
- Keep a copy elsewhere. Download a *.unf file regularly and store it outside that same server room.
- Know who owns the console. Cloud backups live in the owner’s UI account. If that person leaves the company, access to your backups may well leave with them.
- Move the controller off site. With the Network application running in a data centre, break-ins, power cuts and hardware defects on site stop being controller problems.
Conclusion
A broken or stolen Cloud Key doesn’t shut your network down — it takes away your control over it. Whether that becomes a brief incident or a long working day is decided before the failure: by system backups being switched on, by a *.unf file you can actually reach, and by whether your controller still depends on one box in a cabinet at all.
That is exactly what clevendo does: we run and maintain managed UniFi controllers in a German data centre, keep them updated and backed up, so a hardware failure at your site never touches your management layer. If you already have a backup, the migration is usually done in under an hour. Get in touch and we’ll look at your case together — you’ll find an overview of what we do on our homepage.
Frequently asked questions
Does my Wi-Fi keep working if the Cloud Key fails?
Yes. Adopted UniFi devices keep running on the last configuration they received when the host is unreachable. You just can’t change anything, adopt devices, roll out updates or see any statistics until a controller is back.
Where do I find my UniFi cloud backups?
If system backups are enabled under Settings > Control Plane > Backups, UniFi automatically stores a backup in the console owner’s UI account every week and before each major update. You can review all backups linked to that account at account.ui.com/backups. Only the owner can manage them.
Can I restore a Cloud Key backup onto different hardware?
Yes. When moving to a different model — Cloud Gateway, Cloud Key or UNVR — the new device must run UniFi OS 3.1 or higher. Restore during the setup process or later under Settings > Control Plane > Backups. To migrate to a controller without local hardware, use the Network backup file (*.unf) instead.
How do I tell my access points that the controller has moved?
While the old application still runs, use the “Override Inform Host” toggle. Once it’s gone, use Layer 3 adoption: a DNS record for the hostname unifi, DHCP option 43, or SSH with set-inform http://<host>:8080/inform. In every case TCP port 8080 must be reachable without restrictions.
Are my Protect recordings still available after a Cloud Key failure?
Existing recordings cannot be transferred between UniFi consoles — they stay on the original host until its storage is removed or reformatted. If the device is dead or stolen, that footage is effectively unavailable.
