The Controller Nobody Wanted to Run: Why a Three-Office Firm Stopped Hosting Its Own Wi-Fi Brain

In short: The UniFi controller software is free. Running it continuously for years, backing it up, upgrading it without breaking Wi-Fi, and answering for it at 3 a.m. is not. A company with three or more sites is not really choosing where the controller runs — it is choosing who is accountable for it.

The Cheapest Line in the Quote Is the One Nobody Costed

A company with offices in three cities buys Ubiquiti UniFi access points. The reasoning is sound and extremely common: the hardware is good, the price is defensible, the interface is comprehensible to a competent generalist, and the management software is free.

Eighteen months later the estate looks like this. Site one runs a controller on a small virtual machine somebody built and nobody has patched. Site two has a hardware Cloud Key in a comms cabinet, bought because it was easier than arguing about the server. Site three's access points were adopted into a laptop-based install during the fit-out and have been effectively unmanaged since the contractor left. Three sites, three control planes, one company, and no single answer to "what is our wireless configuration."

Nothing dramatic has gone wrong. That is the point. The controller is the part of a wireless deployment that fails quietly, over a long period, and only becomes visible when someone needs it — during an outage, during an audit, or during the week a new office has to open.

This article is deliberately not about one country. The access-point decision is local; this decision is not.

What a Controller Actually Is, and Why "Free" Is the Expensive Word

A UniFi access point is not a standalone device that you configure and forget. It is a managed device, and the thing that manages it is the UniFi Network controller — software that holds your SSIDs, your VLANs, your per-site policies, the topology of what is connected to what, and the statistics that tell you whether the network is behaving.

Adopt an access point into a controller and it becomes part of a managed estate. Leave it without one and it is an isolated box someone configured once, on a day nobody wrote down.

A note on vocabulary, because it will come up the moment you talk to anyone technical: Ubiquiti has been moving away from the word "controller." The current naming is UniFi OS Server for the self-hosted package and Site Manager for the cloud view. Almost nobody searching for this problem types those words — they type "controller," which is why this article does too. If a supplier only ever uses the new names, they are describing the product; if they only ever use the old one, they may not have looked at it recently. You want someone who knows both.

Here is the sentence that causes the problem: the controller software is free. It is true, and it is the most expensive true statement in the whole decision, because it makes the software look like the cost. The software is not the cost. The cost is that the software has to run — continuously, for the life of the network, on something, maintained by someone, with backups that work and upgrades that do not break Friday.

The Three Ways to Run One, With What Each Actually Costs

Self-host it

• What it looks like on paper: Free software on a server you already have.
• What it actually requires: A Java and MongoDB environment — the official minimum is MongoDB 3.6, bundled with the installer — where even a small network needs roughly 1 to 1.5 GB of RAM just for the controller. You open and harden TCP 8443, 8080 and 8843, and UDP 3478 and 10001.
• What you are signing up for: Upgrades, backups, hardening and availability, all yours, indefinitely. Ubiquiti's own guidance is not to self-host if you cannot keep it running continuously — which is a vendor telling you the honest thing, and worth taking seriously.
• Scope limit: A self-hosted install runs UniFi Network only.
• Who it genuinely fits: A team with a dedicated network engineer who is happy to own that server and will still be there in three years.

Buy a hardware Cloud Key on site

• What it looks like on paper: One box, works out of the day it arrives, no server project.
• What it actually costs: A UniFi Cloud Key Gen2 Plus retails around US$239.99, one-time, and you generally need one per site. Ubiquiti's own hosted controller is a further option, from US$29 per month for up to 1,000 devices. *(Both are public vendor prices observed 2026-09-10, shown for comparison only — they are not Brocent quotes, and they are Ubiquiti's products, not ours.)*
• What you are signing up for: Upgrades and backups still need a person. Fixed resources. A single point of failure sitting in a cabinet in an office, subject to the power, cooling and general dignity of that cabinet.
• Its one genuine advantage: If you also want UniFi Protect (video) or Access (doors), this is the only path — see the scope section below, because that is architecture, not salesmanship.
• Who it genuinely fits: Single-site operations, and anyone who needs Protect or Access anyway.

Have someone run it for you

• What it looks like on paper: A monthly line item.
• What it actually replaces: The server, the patching, the backup regime, the upgrade anxiety, and the question of who answers when it is down.
• What Brocent's version costs: US$1.20 per access point per month, on a 12-month contract, excluding tax — the current published offer, quoted under promo code `YE26-UNIFIAP` and read from the live pricing source on 16 September 2026. Offers have windows; check the managed wireless network page rather than trusting a date-stamped figure in a blog post. The standing list price for controller hosting outside an offer window is a custom quote.
• Who it genuinely fits: Multi-site companies, and anyone whose IT function is one or two generalists rather than a network team.

The reason to lay the three out this way is that they are usually compared on price, and price is the least interesting axis. Self-hosting is free and costs the most. A Cloud Key is cheap once and costs again every time something happens to it. What actually differs between the three is who is accountable, and that is a question you answer once and live with for years.

What Breaks at Three Sites That Does Not Break at One

Single-site wireless is forgiving. If the controller is down, somebody notices within a day and reboots something. Multi-site is where the model shows its shape, and three specific things go wrong.

The estate drifts. Sites are configured at different times by different people with different assumptions, and each configuration is locally reasonable. Then a salesperson travels between offices and the Wi-Fi behaves differently in each — different SSID naming, different VLAN behaviour, a guest network that is properly separated in one office and nominally separated in another. Nobody decided this. It accumulated.

Firmware upgrades get deferred indefinitely. Not because anyone is negligent, but because the person who would do it correctly understands what happens if it goes wrong, and there is never a good Tuesday. So the estate sits on an ageing firmware baseline, and the eventual upgrade is larger, riskier and more disruptive than the ten small ones that were skipped — which is the precise mechanism by which deferred maintenance becomes an outage.

When Wi-Fi degrades, there is no history to look at. This is the underrated one. The complaint is always "the Wi-Fi is bad," and it is always subjective, and without retained statistics it is unanswerable. Was channel utilisation high at that hour? Did that access point restart? Did client count spike in the meeting room? A controller that has been running and retaining data answers these questions in minutes. A controller that was rebuilt six months ago answers none of them, so the conversation reverts to guessing, and the fix becomes "buy another access point" — which sometimes works, for reasons nobody can explain, which is the worst possible outcome for a company's ability to make the next decision.

Brocent's Perspective: A Control Plane Is an Operations Problem, Not a Software Problem

Every comparison of hosting options starts by asking *where the controller runs*. That is the wrong first question. It is answerable, it feels technical, and it settles nothing.

The useful questions are these three:

1. Who is accountable for it at 3 a.m.? Not who *could* fix it — who is contractually responsible for noticing, and what happens if they do not.

2. Who upgrades it, and inside what process? A change that runs through a ticket, a window and a rollback plan is a different risk from a change someone makes because it seemed fine.

3. What happens when it is down, and how would you know? If the answer is "someone would eventually mention the Wi-Fi is weird," the control plane is not being operated. It is being hosted.

That distinction — hosted versus operated — is the whole argument. Anyone can host software. Operating it means monitoring with alerts that become tickets rather than emails, a change process with a record, a backup you can actually restore from, and a number on availability that someone has committed to.

For what it is worth, this is also why the wireless control plane is such a useful thing to buy first. It is small, it is measurable, and it teaches a company what "managed" actually means in practice — someone watching it overnight, a change that goes through a window instead of a group chat, a report that says what happened and what to do about it. That is the same engine a full managed IT plan runs on. Wireless is the sample; the plan is the meal.

What Changes When Someone Else Runs It

Specifically, and without the marketing register:

• Adoption and configuration. Access points are adopted into the managed controller; SSIDs and VLANs are defined once and pushed per site or per floor; guest portal (voucher and other methods) and RADIUS / 802.1X are configured for you. A new site clones a mature site's policy instead of being configured from scratch.
• Alerts become tickets. Offline access points, reboot loops and PoE faults are watched around the clock and raised into the service desk with someone accountable for closing them — rather than arriving in an inbox that may or may not be read.
• Upgrades run as changes. Firmware goes in batches, inside an agreed maintenance window, with a configuration backup taken first, never the whole estate at once. Each one is assessed, confirmed, executed, verified and recorded.
• Configuration is backed up daily and retained three years. Which means a mis-click or a device swap has a way back to any given day, not just to the last time somebody remembered to export.
• Isolation is logical, and we say so. Not a separate server per client: tenant boundaries inside a shared platform that scope both data and permissions. Your sites, devices, topology, SSIDs, keys and logs belong to your tenant; your accounts resolve only that scope; engineer access is granted per client and logged. The underlying runtime is shared — which is part of why a per-access-point price can be what it is. If your compliance requires a dedicated instance or a specific data jurisdiction, that is a conversation to have before the quote, not an assumption to make. Be wary of any provider whose answer to this question is just "completely separate."
• There is a number and a report. A 99% controller availability commitment, and a monthly availability report that states what happened, what it means and what to do about it — a conclusion rather than a screenshot of graphs.
• And two buying models. Keep the access points you already bought and register them, or take the hardware inside the subscription with maintenance and replacement included. The controller, the monitoring, the change process and the report are identical either way; the only variable is who owns the hardware. The network and server maintenance pricing page carries the track this sits in, and the Ubiquiti pricing page carries the hardware side.

What a Hosted Controller Cannot Do

This section exists because the honest version of it is more useful than the sales version, and because getting it wrong would waste your time.

UniFi is not one piece of software. It is several applications, and only UniFi Network — the wireless and switching controller — can be self-hosted or third-party-hosted at all. Protect (video), Access (doors) and Talk (telephony) run only on Ubiquiti's own UniFi OS console hardware. Ubiquiti's own self-host package, UniFi OS Server, does not change this: it currently covers Network, InnerSpace and Identity, and those three are not among them. Access has a physical constraint on top — every door needs an Access Hub on site to actually release the lock, and no amount of cloud changes that.

That is Ubiquiti's product architecture. It is not a ceiling on any provider's platform, and any provider who offers to "upgrade to support Protect" is describing something that does not exist. If you need video or door access, a UniFi OS console goes in your office — which can be specified, supplied, deployed and maintained for you, as a hardware purchase rather than a change to controller hosting.

One thing worth knowing, and it runs in your favour: UniFi OS Server runs one instance per client, with no multi-tenancy and none of the role separation a service provider needs. That is precisely why a management layer — tenant boundaries, permission tiers, change process, reporting — has to be built on top of it, rather than every client maintaining their own copy of the same problem.

Comparison: Three Ways to Run a UniFi Controller

Self-hosted controller

• Cost shape: Free software, your server, your 2 a.m.
• What you own: The Java/MongoDB environment, the open ports, the hardening, the upgrades, the backups, the availability.
• Best case: A capable network engineer who enjoys this, and a server that is already being patched properly for other reasons.
• Worst case: The person who built it leaves, and the estate is now managed by software nobody wants to touch.

Hardware Cloud Key on site

• Cost shape: Roughly US$239.99 one-time per site at public retail (observed 2026-09-10, Ubiquiti's price, not ours), plus a person's time forever.
• What you own: A physical box per site, its power, its failure, and its replacement.
• Best case: One site, or a genuine need for Protect or Access, where the console is required regardless.
• Worst case: Five sites, five boxes, five separate configurations and no consolidated view — which is the estate-drift problem bought at retail.

Hosted and operated for you (the Brocent model)

• Cost shape: Per access point, per month — currently US$1.20 per access point per month on a 12-month contract, excluding tax, under the offer above (read 16 September 2026; verify before quoting it back at anyone).
• What you own: The access points. They stay your assets, and the configuration is exportable if you leave.
• Best case: Three or more sites, a small IT function, and a real need for someone to be accountable overnight and at audit time.
• Worst case — the honest one: If you have one site, a network engineer on staff, and no reporting requirement, you may simply not need this. A provider who cannot say that is not worth buying from.

Frequently Asked Questions

What is a UniFi controller and why does it need hosting?

It is the software that configures and monitors your UniFi access points centrally — SSIDs, VLANs, policies, topology and statistics all live in it. The software itself is free, but it has to run somewhere continuously: a server you build and maintain (Java plus MongoDB, ports opened, upgrades and backups yours), a hardware Cloud Key on site, or a hosted controller someone else operates. Ubiquiti now calls the self-hosted package UniFi OS Server, but the search-side vocabulary and most people's working vocabulary is still "controller."

Do the access points have to be bought from the provider?

They do not, at least not here. UniFi access points you already own can be adopted directly, and controller hosting is priced per access point regardless of where the unit came from. If you also want new units supplied and deployed, that is a separate hardware purchase rather than a condition of the service. It is a fair question to ask any provider early, because the answer tells you whether you are buying a service or a hardware contract with a service attached.

If the office loses internet, does the Wi-Fi stop working?

No. UniFi access points keep forwarding traffic using the configuration already pushed to them when the controller is unreachable. What is affected is management and statistics — you lose the ability to change things and to see what is happening, not the ability for staff to use the network. This matters because it is the single most common objection to a cloud-hosted control plane, and the objection is based on a misunderstanding of what the controller does. It is a control plane, not a data path.

Will a firmware upgrade take the network down?

It should not, and the reason is process rather than luck. Upgrades run in batches inside an agreed maintenance window, with a configuration backup taken beforehand, and never across a whole estate at once during working hours. Every upgrade goes through the same change process as any other change — assessed with a rollback plan, confirmed with you, executed, verified and recorded — and the outcome appears in that period's report. The risk you are actually avoiding is not a bad upgrade; it is an upgrade nobody planned.

Can you host UniFi Protect and Access too?

No — and neither can anyone else, which is the more useful half of the answer. Ubiquiti allows Protect, Access and Talk to run only on its own UniFi OS console hardware; they are not available as self-hosted or third-party-hosted software, and UniFi OS Server covers Network, InnerSpace and Identity rather than these three. Access additionally needs an Access Hub on site for every door. If you need video or door access, a console goes in your office, and that is a hardware purchase rather than a change to how controller hosting is priced.

Is my network data separated from other clients?

Yes, by logical isolation — and it is worth stating that precisely rather than vaguely. The platform runtime is shared, which is part of why a per-access-point price is possible at all. Within it, the tenant is a hard boundary: your sites, devices, data, credentials and logs are scoped to your tenant, your accounts resolve only that scope, and provider engineer access is granted per client and logged. If your compliance position requires a dedicated instance or a specific data jurisdiction, raise it before the quote so it can be scoped rather than assumed.

Can I move off it later and take the configuration with me?

Yes, and this is the question that should decide a close call. The access points are your assets throughout. On termination the configuration can be exported and the devices adopted back into a controller you run yourself, or into a hardware Cloud Key. A hosted control plane should never become a way of holding your network hostage — ask explicitly what the exit looks like, and be suspicious of an answer that is vague about it.

Is this cheaper than a Cloud Key?

Over a short enough horizon, no: a one-time box always beats a subscription on a spreadsheet with a two-year column. The comparison only becomes meaningful when you include what the box does not include — the person who upgrades it, the backup that has to exist, the replacement when it fails, the absence of a consolidated view across sites, and the fact that you need one per site. At three or more sites the arithmetic usually turns; at one site it frequently does not. Run it on your own site count rather than on anyone's example.

We already have a managed wireless setup at one site. Does this replace it?

Not necessarily — it consolidates it. The usual pattern is that one site is in reasonable shape and the others are not, and the value is in bringing them onto one control plane with one policy set rather than re-doing the good site. If you want to see what this looks like as a real scenario rather than as a product description, we have written it up from a multi-site operator's point of view in managed wireless at a Hong Kong serviced office operator.

Where This Leaves the Decision

If you already own UniFi access points, you have already made the hard decision. What remains is smaller than it feels, and it is not a technical choice — it is a choice about accountability. Someone has to run the control plane, watch it, upgrade it, back it up and answer for it. The only real question is whether that someone is on your payroll, in a cabinet at one of your offices, or under a contract with a number attached.

The wireless control plane is usually the cheapest place a company finds out what "managed" means. If it goes well there, the same monitoring, the same change process and the same reporting are what a full per-user managed plan is built from — and the pricing page publishes what that costs per user, per month, in the markets where Brocent publishes rates.

Send a site count and an access-point count and you can have a real number back. Talk to us.