How to Manage Multiple UniFi Sites Remotely

The moment you manage UniFi at more than one location — a home plus parents’ house, a few small offices, vacation property, clients — the questions change. It stops being “how do I set up a network” and becomes “how do I manage several, from anywhere, without turning each one into an exposed target.” This guide is the model for multi-site and remote UniFi: how sites work, which architecture fits, and how to get remote access right.

UniFi sites and controllers: choose the management boundary

UniFi’s terminology trips people the moment they go multi-location. Inside the UniFi Network Application, a site is a logically separate managed network with its own devices, settings, networks/VLANs, and rules. One controller can host multiple sites. A site is not the same as a controller, and it’s not the same as a physical building by definition — it’s an administrative grouping.

Why this matters before you scale: people conflate “another location” with “another controller” and stand up redundant infrastructure they didn’t need, or they dump unrelated locations into one site and get a tangle. Decide deliberately:

• Multiple sites on one controller — locations managed as separate sites under a single controller you reach centrally.
• Separate controllers per location — each location runs its own (often a console on-site).

These are genuinely different architectures with different failure modes. Pick on purpose.

UniFi multi-site management with one central controller

A single controller (self-hosted, or a hosted instance) hosts a site per location. Devices at each location adopt back to that central controller.

Strengths: one pane of glass; manage every location from one place; consistent admin; no per-site console to maintain.

Trade-offs: the controller is now central and critical — if it’s unreachable, you’ve lost management of every site at once (devices keep passing traffic, per controller hosting options, but you can’t change anything anywhere). Remote-location devices must reach the controller across the internet, which is a Layer 3 adoption scenario every time (devices and controller on different networks), exactly the pattern from adoption troubleshooting. And the central controller must be reachable by those remote devices and by you — safely, which is the recurring theme below.

This fits a fleet you administer centrally and want uniform: several small offices, or one admin running many locations. Uniform is easier to claim than to hold, because the settings that drift first are the per-WLAN radio ones — band steering, minimum RSSI, fast roaming, DTIM. Decide those once against UniFi advanced wireless settings and apply the same profile to every site, rather than tuning each location by hand.

UniFi remote management with a console at each site

Each location runs its own controller — typically a UniFi OS console on-site (a gateway/Dream Machine family device or a Cloud Key).

Strengths: each site is independent. One site’s controller failing doesn’t blind the others. Local adoption is the simple Layer 2 case. Each console handles its own remote access through Ubiquiti’s official portal, so you didn’t build a central exposed thing. If a site has cameras, an on-site console keeps recording local and resilient.

Trade-offs: you maintain separate controllers and their configurations. UniFi Site Manager provides a shared dashboard and update management across those sites; separate consoles do not mean separate sign-in portals. There is still more local hardware to maintain.

This fits independent locations (your house, parents’ house, a cabin) where blast-radius isolation and dead-simple local adoption beat centralization — usually the right call for a small number of unrelated sites.

Secure UniFi remote access: Site Manager or VPN

Across both architectures the recurring failure is the same one from Protect planning and controller hosting, and at multiple sites it’s multiplied: people port-forward a controller or console to the internet so they can manage it remotely. Don’t. Every exposed location is an internet-facing admin surface, and now you have several.

Do it the safe ways instead:

• UniFi OS consoles provide official remote access through Ubiquiti’s portal. You manage the site remotely without opening inbound ports. For a controller-per-site model this is the clean default and a strong reason to favor on-site consoles for scattered locations.
• VPN into each site (or into a hub site) and manage the controller as if local. Follow the UniFi VPN remote access guide for the tunnel options. This keeps the management plane off the public internet entirely.
• For a central controller, do not expose its admin port. Reach it over a VPN or an authenticated reverse proxy, never a raw port-forward. The convenience of “just forward the port” is exactly how multi-site becomes multi-exposure.

Decide remote access as its own deliberate layer, per site, separate from where the controller runs. Multiplying locations multiplies this mistake if you don’t.

UniFi Layer 3 adoption for remote sites

Devices on another routed network use UniFi Layer 3 adoption. Provide a reachable controller address through the planned routed or VPN path; broadcast discovery does not cross the boundary. The reasoning from adoption troubleshooting applies, amplified by distance (you can’t just walk over and reseat a cable):

• Remote devices must be told where the controller is (a Layer 3 pointer such as a DHCP option or DNS for that site), since broadcast discovery never crosses the internet.
• A pragmatic pattern: adopt devices locally first (on a bench or local network they can reach the controller from) and pre-stage them before they’re shipped/installed at the remote site, rather than debugging adoption blind over a WAN.
• Expect “managed by other”/stale-credential cases on any reused gear, and plan a supported migration or an authorized reset before remote adoption — diagnosing that remotely is painful, so pre-empt it.

Multi-site adoption pain is almost always unmanaged Layer 3 expectations plus no physical access. Plan for both before the device is far away.

UniFi Site Manager permissions and recovery

In UniFi’s admin workflow, administrators can receive permissions across selected sites or different permissions per site. Review the sites each administrator needs and keep application access limited to that role.

Record where each site’s controller runs and keep its UniFi controller backup and recovery plan with the site inventory. Before a remote maintenance window, confirm that the intended administrator can open the correct site and that someone can recover local access if a network change interrupts management.

Choosing your UniFi multi-site model

1. Internalize that “site” is an admin grouping, not automatically a building or a controller. Decide sites and controllers as separate questions.
2. Few unrelated locations, want isolation and simple local adoption → controller per site (on-site consoles), official remote access each.
3. A fleet you administer centrally and want uniform → one controller, multiple sites, accepting it’s now a critical central dependency.
4. Whatever you choose, never expose a controller/console by port-forward. Official remote access or VPN, decided per site.
5. For central control, plan Layer 3 adoption and pre-stage remote devices rather than adopting blind over the internet.

Multi-site UniFi is very workable once you separate three things people merge: site vs controller, centralized vs isolated management, and (above all) hosting vs remote access. Keep those distinct and a fleet of UniFi sites is calm. Blur them and every location becomes its own incident. For the foundations this builds on, see controller hosting options, adoption troubleshooting, and the rest of our UniFi guides.

Related across the network

• How Matter, Thread and Border Routers Fit Together — matterhomelab.com
• UniFi Adoption Failed: How to Fix Stuck Devices — ubiquitiguide.com