UniFi Network for coworking Wi-Fi

This guide scopes UniFi Network to a reversible guest/staff Wi-Fi pilot on approved Ubiquiti hardware. It is not a network design, compatibility guarantee, or evidence that a site cutover or restore has run.

1. Coworking outcome

Provide reliable guest and staff Wi-Fi with approved separation from management and infrastructure networks. UniFi augments configuration and troubleshooting; it does not replace network engineering, incident ownership, or member support.

2. Pilot scope

Stage one guest and one staff SSID on test networks in one isolated area using synthetic/test clients. Keep incumbent Wi-Fi available and exclude captive-portal identity, payment, door access, life safety, and production-wide adoption.

3. Fit

Good fit: a venue deliberately using UniFi hardware with a network operator, surveyed cabling/coverage, maintenance windows, configuration backups, spare planning, and independent recovery access.

4. Non-fit and alternatives

Poor fit: a hardware-neutral open-source requirement, an unstaffed network, an untested zero-downtime migration, or client monitoring without an approved purpose. Compare hardware-neutral networking or a managed network provider when ecosystem lock-in or operator duty is unacceptable; retain the incumbent network during evaluation.

5. Coworking use cases

• Separate approved guest, staff, management, and infrastructure traffic.
• Apply consistent, human-approved network intent across locations.
• Correlate device/uplink health with member-reported Wi-Fi incidents.

Client identity, automated blocking, and critical building dependencies are excluded.

6. Tasks reduced or augmented

UniFi can centralize supported device configuration, health visibility, backups, and staged firmware work. It cannot choose RF/topology/firewall policy, judge member conduct, prove application usability, repair cabling, or authorize an outage.

7. Human decisions and approvals

Network and facilities owners approve topology/hardware; privacy approves telemetry; the change owner approves device adoption, firmware, maintenance, rollback, and expansion; communications approves member messages. No agent may autonomously block clients, alter policy, or publish an outage.

8. Owners and RACI

Name an accountable change owner, responsible network operator, facilities contact, privacy reviewer, incident commander, communications owner, and recovery witness. The operator executes changes; reviewers must independently verify segmentation, telemetry, and rollback evidence.

9. Prerequisites

Inventory controller/device models and versions, uplinks, ISP handoff, cabling, PoE, IP ranges, DHCP/DNS, VLANs, SSIDs, firewall rules, physical locations, current coverage/capacity evidence, admin access, recovery credentials, and failback. Resolve undocumented dependencies first.

10. Skills and effort boundary

The pilot needs switching, VLAN, DHCP, DNS, routing, firewall, wireless survey, firmware, backup/restore, and incident skills. The catalog’s 1-3 days is an unverified estimate; survey, cabling, compatibility, remediation, and witnessed rollback may take longer.

11. Deployment choice

Choose a supported controller form only after checking current device/controller compatibility in official help. Record operator, location, credentials, cloud dependency, support path, and update method. Do not adopt production devices into a pilot controller before rollback approval.

12. Architecture and dependencies

Map clients, APs, switches, gateway, controller, management network, DHCP/DNS, ISP, power, monitoring, captive portal if separately approved, and recovery access. Mark which functions survive controller loss and verify those semantics on selected versions rather than assuming them.

13. License and edition boundary

UniFi Network is proprietary free-to-use controller software in the Ubiquiti ecosystem, not OSI-approved open source. Recheck license/use terms at the official download source; this guide establishes no entitlement or support right.

14. Total cost boundary

Record paid APs/switches/gateways, controller appliance/self-host/optional hosting, survey, cabling, installation, replacement stock, power, updates, monitoring, recovery drills, support, outage labor, and eventual hardware replacement. No current price, free tier, or support level is verified.

15. Data map

Data	Purpose	Minimum handling	Exit record
Device/site configuration	Network operation	Named admins; protected backups	Supported backup plus readable topology
Client connection metadata	Troubleshooting	Approved fields and retention only	Retention/deletion record
Optional client identification	Optional visibility	Disabled unless privacy-approved	Setting and purpose record
Admin/change records	Accountability	Restricted reviewers	Access/change register

Payment, membership, CRM, and access-control records are out of scope. Client identifiers can be personal data.

16. Privacy and retention

Document purpose, notice/lawful basis where applicable, access, retention, and deletion for connection metadata. Disable optional identification/analytics without approval. Never use network observations for eligibility, discipline, pricing, employment, or identity decisions.

17. Security baseline

Isolate management, restrict controller administration, use strong individual credentials and supported authentication, protect recovery access separately, use encrypted administration, minimize exposure, and apply supported updates. Segmentation is accepted only after guest/private and guest/guest tests prove intended behavior.

18. Compliance and expert review

The operator owns privacy, lawful monitoring, radio, lease, and local network obligations; settings are not compliance proof. Require a network engineer for production firewall/routing, RF/capacity, multi-site, HA, migration, or critical dependencies, and privacy/legal review for identification, long retention, or captive portals.

19. Integration boundary

No captive portal, identity, door, monitoring, ISP, or other integration is catalog-verified. Record each connector’s official compatibility source, versions, credentials/scopes, data, failure behavior, owner, disable switch, and manual fallback before enabling it.

20. Configuration baseline

Record exact controller/device versions, topology, IP/VLAN plan, DHCP/DNS, firewall intent, SSID/security/radio settings, management access, device locations, approved telemetry/retention, update policy, monitoring, backup, and rollback. Keep secrets outside this repository.

21. Smallest useful experiment

Following official help, stage the two test SSIDs and approved segmentation in one area. Use representative test devices, preserve incumbent Wi-Fi, and avoid adopting production hardware or dependencies.

22. Implementation sequence

1. Freeze current topology, settings, versions, and access paths.
2. Verify hardware/controller compatibility from current official sources.
3. Stage controller and test hardware without production adoption.
4. Apply approved test networks, SSIDs, firewall intent, and minimum telemetry.
5. Run isolation, workflow, coverage/capacity, loss, restore, and failback tests.
6. Obtain network, facilities, privacy, recovery, and change sign-off.
7. Expand one area at a time only while acceptance remains true.

23. Migration and rollout

Pilot in parallel with incumbent Wi-Fi, communicate the test area and fallback, freeze unrelated network changes, and migrate bounded areas with post-change checks. Do not remove old service until coverage, capacity, member workflows, administration, recovery, and rollback are accepted.

24. Required test plan

Test guest-to-guest/private isolation, staff access, DHCP/DNS, VPN/video/voice/printing, representative devices, roaming, coverage/capacity, ISP/controller/power loss, admin recovery, backup restore, and incumbent failback. Record versions, topology, expected/observed result, tester, date, and sanitized evidence.

25. Acceptance criteria

No prohibited cross-network access occurs; approved member workflows and site thresholds pass; optional telemetry matches approval; named admins and recovery access work; controller backup restores in isolation; incumbent failback succeeds; all owners sign. Any unexplained access or critical workflow failure blocks expansion.

26. Success metrics

Track pre-approved coverage, association/reconnect, critical workflow completion, incident/response, help-desk, backup age, and recovery observations against a measured baseline. Dashboard green status alone is not improvement evidence and no staffing savings are assumed.

27. Monitoring and alerting

Monitor controller/device reachability, uplinks, power, DHCP/DNS, approved capacity signals, backups, and independent internet/application checks where practical. Every alert needs an owner, severity, runbook, maintenance suppression, escalation time, and human impact validation.

28. Operating cadence

Review inventory, unsupported versions, configuration drift, failed backups, admin access, telemetry retention, recurring coverage faults, spares, and ISP/vendor contacts on defined cadences. Re-test representative member workflows after material network, firmware, or dependency changes.

29. Failure modes and response

Plan for ISP/DNS/DHCP/controller/power loss, failed adoption, bad firewall/VLAN/radio policy, certificate/admin lockout, firmware regression, and backup incompatibility. The incident commander validates scope, selects failback/repair, preserves approved evidence, and authorizes communication; no agent isolates a member from telemetry alone.

30. Backup procedure

Create a controller backup using current version-matched guidance and store an encrypted off-controller copy with checksum, controller version, topology, device/location inventory, critical policy intent, and separately protected recovery credentials. Backup creation without restore is unverified recovery.

31. Restore drill

Restore a copied backup only to an isolated compatible target. Verify sites, admins, devices, VLAN/SSID mapping, firewall intent, and a test-device workflow without unexpectedly adopting production devices. Record observed time; never overwrite the only working controller for a drill.

32. Upgrade, rollback, and exit

Read compatibility/release notes, back up, test the exact controller/firmware sequence on representative hardware, approve a window, and stage rollout. Stop for access, segmentation, or workflow failure and use the pre-approved compatible configuration/hardware failback; downgrade is not assumed. Exit requires a vendor-neutral topology/inventory and tested replacement plan because a controller backup is not hardware-neutral.

33. Sources, evidence, and unknowns

Reviewed 2026-07-17: UniFi Wi-Fi, software downloads, and official help. Evidence is documentation review only.

Untested: compatibility, hosting/license/support terms, prices, firmware and controller-loss behavior, exact telemetry controls, backup portability, RF coverage/capacity, integrations, certifications, restore time, rollback time, and production operation. Treat all as open gates until evidenced at the venue.