One Controller, Every Venue: Running a Self-Hosted UniFi Network Server on a VPS

The Architecture Multi-Venue Operators Converge On

Run guest WiFi across more than two or three venues and the per-venue controller model starts to hurt. Every site has its own Cloud Key or console to update, its own admin credentials, its own reachability problem for the captive portal platform, and its own way of drifting out of sync with the others. The pattern experienced operators converge on instead: one self-hosted UniFi Network Server on a VPS, publicly reachable by design, with one UniFi site per venue and the venue hardware reduced to access points and switches that phone home.

The benefits compound. Adoption of a new venue is minutes, not a hardware order. The portal platform integrates against one controller URL with per-site scoping. Configuration templates, admin access, and upgrades happen once. And because the controller already lives on the internet, the entire reachability problem that occupies the UDM Pro guide and the Cloudflare Tunnel guide simply does not exist.

The tradeoff is that you are now operating a small server. This guide covers doing that responsibly.

Sizing and Base Setup

A modest VPS carries a surprising number of sites. For up to roughly 10 venues and 50 devices, 2 vCPUs, 4 GB of RAM, and 40 GB of SSD storage is a comfortable baseline; the Network Server is a Java application backed by MongoDB, and memory is the resource it actually cares about. Choose a current Debian or Ubuntu LTS image, and check Ubiquiti's release notes for the MongoDB versions your Network Server release supports before installing; mismatched MongoDB versions are the single most common self-hosting install failure.

Basic order of operations:

1. Provision the VPS with a static public address and set up SSH key authentication, no password logins.
2. Install MongoDB at a supported version, then the UniFi Network Server package from Ubiquiti's repository.
3. Confirm the service starts and answers on port 8443, complete the setup wizard, and immediately create a named admin and disable anything you will not use.
4. Take your first backup before you configure anything else, so you know the restore path works.

The Port Map

Open exactly what the system needs and nothing else:

• 8080 TCP: the inform port. Every AP and switch at every venue talks to this. It must be open to the world, or at minimum to your venues' egress addresses if they are static
• 8443 TCP: the management UI and API. This is the sensitive one: restrict it at the firewall to your own addresses plus the addresses your portal platform calls from
• 3478 UDP: STUN, used by devices for connectivity checks. Leave it open
• 8880 and 8843 TCP: the controller-hosted guest portal ports. With an external portal these see little traffic, but the redirect machinery can still reference them, so leave them reachable
• MongoDB's port: bound to localhost only. It should never be reachable externally, and it is worth explicitly verifying that it is not

Put a proper certificate on 8443. A reverse proxy that terminates a free automated certificate and passes through to the controller is the least-painful approach, and it upgrades every admin session and API call from self-signed to real TLS.

One Site Per Venue

Inside the Network application, create a separate site for each venue. Resist the temptation to run everything in one site with naming conventions; sites are the isolation boundary that keeps venue configurations, VLANs, portal settings, and statistics from bleeding into each other, and they are how VoqadoWiFi scopes each location. Name sites in a scheme you can read a year from now.

Per site, configure the guest SSID, guest policy, VLAN, and the external portal exactly as in the UniFi external captive portal guide. In VoqadoWiFi, each venue becomes a location pointing at the same controller URL with its own site name, so guest data, portal branding, and analytics stay cleanly per-venue.

Adopting Remote Hardware

Venue devices need to find a controller that is no longer on their LAN. This is layer 3 adoption, and you have three mechanisms, in descending order of elegance:

DNS. Create a record named unifi in the DNS domain the venue's DHCP hands out, pointing at your VPS. Factory-reset devices resolve that name and adopt automatically. If you control DNS at the venues, this is the cleanest method and it makes future replacements plug-and-play.

DHCP option 43. Encode the controller address in DHCP. Works well when the venue router supports it, which UniFi and Omada gateways both do.

Manual set-inform. SSH to the AP on its default credentials and issue set-inform pointing at your VPS inform URL, then confirm adoption in the controller and issue it once more so the setting persists. This is the fallback that always works, and the one you will use when adopting hardware that previously belonged to a local controller.

Migrating an existing venue: export a site backup from the old controller where possible, import it on the VPS, then re-inform the devices. Schedule it for a quiet morning; devices drop and rejoin during the move.

Operating It Like You Mean It

Backups. Enable the controller's scheduled auto-backups, then copy them off the VPS on a schedule. A backup that lives only on the server it protects is a hope, not a backup.

Updates. OS security patches on a regular cadence. Controller updates deliberately: read the release notes, snapshot or back up first, update at the start of a quiet week, and re-run one guest login test per venue afterwards. Firmware for venue devices rolls out from the same console; stagger it so you never update every venue the same night.

Monitoring. Watch three things: the service is up, disk has headroom because MongoDB grows with retained statistics, and each site's devices show connected. An AP that loses its inform connection keeps broadcasting but stops being manageable, and the first symptom is often that new guests stop appearing in your dashboard.

Access. Named admin accounts per human, a dedicated local API account for the portal platform with no MFA, and SSH locked to keys. The controller is now central infrastructure for every venue; treat its credentials accordingly.

The Economics

A capable VPS runs 10 to 20 dollars a month and replaces a hardware controller per venue, the truck rolls to maintain them, and the per-site reachability engineering. Against that, VoqadoWiFi pricing stays simple: Growth at 49 dollars a month, with the free Starter tier available for validating a first venue end to end. For an operator at five venues, the whole stack, server included, typically costs less per month than a single day of one venue's marketing spend, and it produces the owned guest list that spend never did.

When the server is up and the first site is adopted, the marketing layer is the fast part. Create your account, add the first location, and the first venue can be capturing opted-in guests the same day.