Where to Run the UniFi Network Application

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.

Managing more than one network changes the hosting decision. Compare a central controller with separate consoles in UniFi multi-site remote management.

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.

If more than one location is in scope, the hosting decision changes shape entirely — one controller with several sites, or a controller per site, is a different question with different failure modes, worked through in managing multiple UniFi sites and remote networks.

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 across the network

• SAN Fundamentals: Fabrics, Zoning, and LUN Masking — sanstorageguide.com
• iSCSI SAN Setup: Targets, Initiators, Multipath — sanstorageguide.com