Two offices, three branches and a warehouse – each with its own UniFi controller and its own login. The moment someone asks which firmware is actually running where, a network that simply grew becomes an administrative problem. UniFi has better answers than that. There are several documented ways to manage UniFi multiple sites from one place, and they differ considerably in effort, permission handling and cost. This guide sorts them out and shows which approach fits which situation.
First, the vocabulary: site, console, application
Most confusion comes from mixing up three different things:
- Site – a logically separate, managed network environment with its own devices, its own networks/VLANs and its own rules. A site is not necessarily a building; it is an administrative unit.
- Console – the hardware or host that runs UniFi OS: a Cloud Key, a Cloud Gateway (the UDM family and relatives) or a UniFi OS Server.
- Application – UniFi Network, Protect, Access, Talk. These run on a console.
Ubiquiti states the key rule plainly: only one instance of each UniFi application can run on any given site. And if you are not using Cloud Gateways, you should run only a single instance of UniFi Network at a given site – so no Cloud Key and self-hosted controller pointed at the same network in parallel.
The three architectures at a glance
| Approach | How it works | Fits when … |
|---|---|---|
| One Network application, several sites | A single central controller holding one site per location; devices check in over the internet | … you want uniform administration and the locations do not need their own console |
| One console per location | Every location runs its own hardware; UniFi Site Manager provides the overarching view | … a Cloud Gateway is on site anyway, or local autonomy is required |
| Mixed model | Large locations with their own console, small branches as sites in the central controller | … your locations differ a lot in size – in practice the most common case |
Option 1: several sites in one Network application
The UniFi Network application manages more than one site. You create a site per location, adopt the devices there and switch between them in the interface. Each site carries its own configuration – wireless networks, VLANs, firewall rules, port profiles.
That is also the most important limitation: sites are deliberately separate. A change in location A does not automatically appear in location B. If you maintain the same guest SSID across five branches, you maintain it five times – unless you work with device templates via Fabrics (more on those below).
How do remote devices reach the central controller?
Once the controller no longer sits in the same LAN, you are doing a layer 3 adoption. The prerequisite in every case is unrestricted reachability between the device and the Network application over TCP port 8080. After that you point the devices in the right direction – with a DNS record for the hostname unifi, with DHCP option 43, or over SSH using set-inform. The details are in our guide to layer 3 adoption of UniFi access points.
Bringing existing locations together
For installations that already exist there is the Site Export wizard: it exports a site including configuration and devices from one Network application so another one can manage it. Three things are worth knowing beforehand:
- Only super administrators may run the export.
- The target application has to run the same version as the source, or a newer one.
- The export is not a backup substitute – admin accounts and credentials are not included.
Option 2: a console per location, centralised through Site Manager
Where a Cloud Gateway or Cloud Key is installed anyway, administration stays local – and the UniFi Site Manager at unifi.ui.com provides the overarching view. Every site you own or have been granted admin access to appears there automatically; no extra configuration is needed. Three functions matter most in multi-location operations:
- Update Manager – view and initiate all updates across all your sites from one place instead of clicking through five interfaces.
- ISP Viewer – central analysis of latency, packet loss and uptime across all deployments. That tells you whether the problem sits at the branch or at the provider.
- Grouping – if several consoles are installed at one location, Site Manager can group them so you manage them together instead of switching back and forth.
The price of this approach: every location holds hardware that can fail, age and be stolen. We described what that means in practice in our guide to a Cloud Key failure.
Getting permissions right: admins, roles, Fabrics
Multiple locations almost always means multiple people in charge. An admin needs a UI Account for that, created at account.ui.com. When adding them you can assign them to a single site or to several sites – so the facility technician in one city only sees that city.
For larger environments Ubiquiti additionally introduced UniFi Fabrics: a layer on top of Site Manager that groups multiple sites under a shared trust and identity domain. Roles are defined centrally once and applied consistently across all sites, instead of being repeated per location. On top of that come policy orchestration, centralised API endpoints and device templates. Worth knowing:
- UniFi OS 4.4 or newer is required.
- No additional equipment is needed to create a Fabric or add a site to one.
- A Fabric is created directly in Site Manager; Ubiquiti recommends one Fabric per trust domain, typically defined by a distinct Identity Provider integration.
- The IdP binding itself requires a suitable console within the Fabric – among others UDM Pro, UDM SE, UDM Pro Max, EFG, UCG-Fiber or UNVR Pro.
Connecting the locations: Site Magic
Central administration is one thing, a continuous network another. That is what Site Magic, the SD-WAN feature in UniFi, is for: it builds encrypted tunnels between compatible UniFi gateways and is configured in Site Manager under Settings > SD-WAN, either as hub-and-spoke or as a mesh. The documented requirements:
- UniFi Network Application 9.0.108 or newer and gateway version 4.1.3 or newer.
- The hub needs at least one device with a public IP address.
- All hubs and spokes share the same UI Account owner, or are managed within the same Fabric by Fabric admins.
- SD-WAN can only be managed by the owner.
Most Cloud Gateways qualify as spokes (the Express is excluded), as do Independent Gateways managed with a Cloud Key, a UniFi OS Server or Official UniFi Hosting. One point that is easy to overlook while planning: overlapping subnets across locations make any site-to-site connection painful. A clean IP plan – location A on 10.10.x, location B on 10.20.x – costs half an hour up front and saves days later.
Where multi-site projects actually go wrong
- No IP concept. Three branches all on 192.168.1.0/24 can be administered separately, but never sensibly connected.
- Everything crammed into one site. Running locations as separate sites is not a formality – it separates configuration, statistics and permissions.
- Permissions as an afterthought. If everyone involved is created as a super admin, walking that back later is hard. Assign roles per site from the start.
- The controller lives in a branch office. Then administration of every location depends on the internet line and the power supply of that one building.
Conclusion
There is no single right answer for multiple locations, but there is a clear logic to it: sites separate the configuration, Site Manager gives you the overview across everything, Fabrics handle identities and roles once you reach a certain size, and Site Magic connects the networks. What you should settle before any of it is unglamorous and decisive – a clean IP plan, clear responsibilities, and the question of where the controller actually lives.
That last question is the one we take off your plate. clevendo runs managed UniFi Network controllers in a German data centre, so your locations are administered centrally and none of them carries the controller for all the others. Get in touch and we will look at your site structure together.
Frequently asked questions
Can one UniFi controller manage multiple locations?
Yes. The UniFi Network application manages several sites – logically separate network environments, each with its own devices, networks and rules. For devices at remote locations to reach the central controller you need a layer 3 adoption, which requires unrestricted reachability over TCP port 8080.
What is the difference between a site and a console?
A site is a logically separate, managed network environment with its own configuration. A console is the hardware or host running UniFi OS and the applications – a Cloud Key, a Cloud Gateway or a UniFi OS Server, for example. Only one instance of each UniFi application can run on a given site.
Can I run two controllers at one location?
Ubiquiti’s recommendation: if you are not using Cloud Gateways, run only a single instance of UniFi Network at a given site – so not a Cloud Key and a self-hosted controller in parallel. If several consoles are installed at one location, Site Manager lets you group them and manage them together.
Can I move an existing location into a central controller?
Yes, using the Site Export wizard. It exports a site including configuration and devices so another Network application can manage it. The export is restricted to super administrators, the target application must run the same version or newer, and admin accounts and credentials are not included.
What do I need for Site Magic?
UniFi Network Application 9.0.108 or newer and gateway version 4.1.3 or newer. The hub needs at least one device with a public IP address, and all hubs and spokes must share the same UI Account owner or be managed within the same Fabric by Fabric admins. SD-WAN is configured in Site Manager and can only be managed by the owner.
Do I need UniFi Fabrics for multiple locations?
Not necessarily. Fabrics pay off when roles and identities need to be managed uniformly across many sites – roles are defined once and applied consistently. UniFi OS 4.4 or newer is required; no additional equipment is needed to create a Fabric or add a site to one.
