Where to Run the UniFi Network Application
UniFi OS Console vs self-hosted controller vs hosted controller — how the UniFi Network Application actually works, what each hosting option costs you, and how to choose without repainting yourself into a corner.
The first real decision in a UniFi deployment isn’t which access point to buy. It’s where the UniFi Network Application — the controller software that adopts, provisions, and manages your devices — is going to live. Get this wrong and you either lose your configuration history, can’t reach your network remotely, or end up migrating controllers later, which is avoidable work.
What the controller actually is (and isn’t)
A common misconception: people assume UniFi devices need the controller running at all times to pass traffic. They don’t. Once a UniFi access point or switch is adopted and provisioned, it keeps forwarding traffic, serving Wi-Fi, and applying its last-known configuration even if the controller is completely offline.
What the controller is for:
- Adopting new devices and pushing configuration to them
- Firmware upgrades
- Statistics, topology maps, and historical charts
- Centralized settings (SSIDs, VLANs, firewall rules on a gateway)
So the controller is a management plane, not a data plane. This matters because it means a controller that’s occasionally offline degrades visibility and management, not connectivity. That changes how much you should worry about its uptime.
The three places it can run
1. A UniFi OS Console (Cloud Gateway, Dream Machine family, Cloud Key)
Ubiquiti sells dedicated hardware that runs UniFi OS, with the Network Application as an app on top. This includes the Cloud Gateway line, the Dream Machine family, and the Cloud Key.
Strengths: It’s the path of least resistance. The console is always on, handles its own updates, integrates remote access through Ubiquiti’s official portal without you exposing anything, and bundles routing/firewall if it’s a gateway model.
Tradeoffs: It’s dedicated hardware you buy and depend on. If the device fails, management is down until you restore a backup to a replacement. Storage for UniFi Protect (if the model supports cameras) is constrained by what the box holds.
For most homes and small offices, a UniFi OS console is the right answer. It’s the option with the fewest ways to get it wrong.
2. Self-hosted Network Application (your own server/VM/container)
The Network Application is also distributed as software you can run yourself on a Linux host, a VM, or a container.
Strengths: No dedicated appliance to buy. You control backups, version pinning, and resources. Good if you already run a homelab or a small server and want the controller as one more service.
Tradeoffs: You own the maintenance — OS patching, application upgrades, database health, and backups. Remote access is your problem to solve safely (see below). If the host is also doing other jobs, controller maintenance windows now collide with everything else on that host.
This is the right choice when you already operate infrastructure and want to keep the controller in it — not something to stand up only to run UniFi unless you specifically want to.
3. Hosted / third-party controller
You can also run the Network Application on a small cloud instance, or use a managed UniFi hosting provider.
Strengths: Always-on controller reachable from anywhere without touching your home network’s inbound rules. Useful for managing multiple sites you don’t physically sit at.
Tradeoffs: A recurring cost and an external dependency. Adoption of devices behind NAT requires extra steps (the devices have to find the controller). For a single home network this is usually more moving parts than it’s worth.
The remote-access question, separated from hosting
People conflate “where the controller runs” with “how do I reach it from outside.” Keep them separate:
- A UniFi OS Console offers official remote access through Ubiquiti’s portal. You don’t open inbound ports.
- A self-hosted controller does not automatically get safe remote access. Do not simply port-forward the controller’s management port to the internet — that exposes an admin interface directly. Reach it over a VPN into your network, or a reverse proxy with authentication in front of it. The clean default is: VPN in, then talk to the controller as if you were local.
Treating remote access as a property of hosting leads people to expose self-hosted controllers unsafely. Decide hosting and remote access as two questions.
Migration is possible but not free
You can move a configuration between controllers using the site export / backup-restore workflow: the Network Application produces a backup file, and a fresh controller of a compatible version can restore it, after which devices re-adopt to the new controller. It works, but it’s a deliberate maintenance operation, not a casual click. The practical takeaway: pick a hosting model you can live with for years, not one you’ll want to escape in six months.
How to choose
| Situation | Recommended |
|---|---|
| Home or small office, want it to just work | UniFi OS Console (gateway or Cloud Key) |
| Already run a homelab/server, want one more service | Self-hosted Network Application |
| Managing multiple remote sites | Hosted controller |
| You only need Wi-Fi, no routing from UniFi | Cloud Key or small console; keep existing router |
If you’re unsure, a UniFi OS console is the choice with the fewest sharp edges. Self-hosting is excellent when you already have somewhere appropriate to host it — not as a reason to build that somewhere.
Once the controller question is settled, the next decisions follow: protect the configuration with controller backups and a disaster-recovery plan, adopt a sane firmware and update strategy, and move on to the physical layer — access point placement and VLAN segmentation. Browse the rest of our UniFi guides for the full path.
Related
UniFi Backups, Migration, and Disaster Recovery
What a UniFi controller backup actually contains, why devices keep working when the controller dies, and a recovery and migration plan that doesn't rely on luck or re-typing your whole config.
A Sane UniFi Firmware and Update Strategy
When to update UniFi controller and device firmware and when to wait, why updating everything at once is the risky path, and an order of operations that avoids self-inflicted outages.
Managing Multiple UniFi Sites and Remote Networks
How UniFi's site model really works, the difference between multi-site on one controller and separate controllers, and how to reach remote networks without exposing anything.