Ops runbook
Onboarding a property, step by step
Most properties only need the first section below — guest WiFi, a branded captive portal, and marketing capture — which is entirely self-service. Everything after that is an opt-in add-on for properties that specifically also want staff network access or run an on-prem PMS, and it's real infrastructure work. Don't assume a new property wants any of it; ask.
Guest WiFi, captive portal & marketingthe default — most properties stop here
Fully self-service. No WireGuard, no RADIUS, none of the infrastructure below this section applies.
Scope, in one sentence
This tier is only the guest-facing captive portal and marketing data capture — it doesn't touch network security, VLANs, or staff access. The property's own vendor hardware still does the actual WiFi encryption and client access control; Waypoint captures who signed in and, where the vendor supports it, tells that hardware to let the device online.
What the property gets
- A branded captive portal (logo, colors, welcome copy, and — via the splash-page designer — background style, button color, and font) guests see when they join WiFi.
- A choice of guest sign-in method: name + email, room number + surname (matched against a real PMS booking or a manually-entered room list), loyalty number + surname, or an event code.
- Consent capture at sign-in (marketing opt-in vs. WiFi-only), feeding directly into marketing sync.
- Marketing sync: a direct Mailchimp connection, or a generic webhook to any other marketing/CRM tool — either, both, or neither.
- Exportable guest data (CSV) and an optional automatic retention/purge policy — off by default, opt-in per property.
- Dashboard analytics: sign-ins over time, opt-in rate, sign-in method breakdown, top countries, a monthly activity calendar.
What we need from the property — all self-service
- Their guest-network vendor's credentials (UniFi, Meraki, Aruba, Ruckus, Omada, pfSense, MikroTik, or FortiGate), entered directly in the Connections tab — picking a vendor there reveals that vendor's own field list and setup notes.
- The actual device-side step, which is separate from entering credentials: on their vendor's own console, point the guest network's captive/external portal at the URL the Connections tab shows for this property. Concretely, for UniFi that's Network app → guest hotspot settings → “External Portal Server”; every other vendor has an equivalent field under a different name. Nothing above this step takes effect on real devices until it's done — nothing in the dashboard can do it for them, since it lives on hardware we don't have access to.
- Optionally, a Mailchimp API key + list ID, or a webhook URL, if they want marketing sync.
- Optionally, PMS booking-lookup credentials (Mews, Cloudbeds, or Opera Cloud via OHIP) for Room sign-in tied to real reservations — a manually-entered room list works fine otherwise.
Full per-vendor walkthroughs (exact console field names, firmware/app-version minimums, and known gotchas like UniFi's console-ID/site-ID lookup) live at /admin/faq and in the main README — this checklist stays at the ops-runbook level rather than duplicating eight vendors' setup screens.
Two separate network paths
The single most likely source of confusion when onboarding a property. Keep them straight.
A property configures path 1 on their WiFi controller. Setting up path 2 is a joint exercise: they need a WireGuard-capable device on their network; we configure our side to route only that one device's IP through the tunnel — never their whole LAN.
Staff 802.1X (via FreeRADIUS)optional
Reference: freeradius/staff-8021x-setup.md for the actual config syntax.
- A WireGuard-capable device on their networkA dedicated small box, or their existing firewall/router if it supports WireGuard — pfSense has a package for this.
- A WireGuard keypairGenerate it for them from the property's Connections tab — the WireGuard tunnel card produces a ready-to-import
.conffile, nowg genkeyneeded on their end. If they'd rather their private key never touch our servers, they can still generate their own and send only the public key instead. - Their AD server's real LAN IPUsed only inside the tunnel — never exposed publicly.
- A dedicated, low-privilege AD bind accountRead-only access to the staff OU. Explicitly not a domain admin account — the single most important item on this list to get right.
- The base DN of the staff OUe.g. ou=Staff,dc=hotelname,dc=local
- Their AD's CA certificateOr their internal CA's cert if self-signed — needed for LDAPS trust verification.
- Their staff WiFi controller's IPFor the RADIUS client registration (network path 1).
- Generate the property's WireGuard keypair from the Connections tab (or receive their public key, if they generated it themselves), then add their peer server-side, scoped via a /32
AllowedIPsto only the AD server's IP — never their whole LAN. - Add a
client {}block in FreeRADIUS'sclients.confwith a freshly generated shared secret, shared back for their controller's RADIUS-server settings. - Add a named
ldap-<propertyslug>module instance + the realm-routing block insites-available/inner-tunnel.
Ask the property's IT contact to do, on their end:
- Import the WireGuard config into their deviceDownload it from the Connections tab (or, on the manual path, build it from our box's public key + endpoint) — routes only their AD server's IP through the tunnel.
- Enter the RADIUS shared secret + our public IPInto their WiFi controller's RADIUS-server settings for the staff SSID, configured for WPA2/3-Enterprise (802.1X).
- Windows staff laptops: push a GPO wireless profileOr configure a third-party supplicant supporting EAP-GTC — Windows' native supplicant doesn't do this out of the box. macOS/iOS/Android need no special configuration.
Verify the tunnel
Use the Connections tab's Test VPN button once the peer is added server-side — it checks for a recent handshake without needing to SSH into the box. Falls back cleanly to a manual wg show if the sidecar backing that button isn't deployed yet.
pfSense shortcut
If their edge device is already pfSense, the pfSense-pkg-WireGuard package gives them a GUI path for the tunnel and peer config instead of a raw wg0.conf edit.
Captive-portal fallback (sidecar)optional
Reference: staff-directory-sidecar/README.md.
Same AD requirements as the 802.1X checklist above (WireGuard peer, bind account, base DN, CA cert) — this reuses the box's existing tunnel access, not a separate tunnel. No RADIUS client registration needed — this is a plain HTTPS call from Waypoint's backend, not a RADIUS exchange. Nothing additional to ask the property for beyond what's already gathered for 802.1X.
Live in the app now as a fifth guest-portal sign-in method, Staff WiFi — a per-property toggle on the Connections tab (off by default). Turn it on only once the AD requirements above are actually in place; the sidecar and the config-generator card below both fail cleanly (a clear error, not a crash) if you flip it on too early.
Status
Wired into a real request flow and browser-verified end to end against a property with no sidecar actually deployed (confirms the clean rejection path). Not yet verified against a real property's AD or a real deployed sidecar reachable over the internet — see the sidecar's own README for what's still open.
Legacy on-prem Opera PMSoptional, legacy only
Reference: radiator/staff-radius.cfg's header comment for the config shape.
Only relevant to properties on the older, on-prem Opera PMS — not Opera Cloud, which uses a completely different integration path (OHIP REST, via the normal PMS Connections-tab flow, no Radiator involvement at all).
- A WireGuard-capable deviceCan be the same device used for staff AD access if the property also wants 802.1X.
- A WireGuard keypairSame generate-it-for-them process as the 802.1X checklist — a separate tunnel address and peer, even if it's the same physical device.
- The Opera/Fidelio PMS server's LAN IP and IFC8 interface portProperty-specific — likely needs their PMS vendor/reseller's help to confirm and to configure the PMS side to accept the interface link.
- Their guest WiFi controller's IPFor a RADIUS client registration on Radiator — a separate registration from FreeRADIUS's, even if it's the same physical controller.
Decide before onboarding
If guest auth is proxied through Waypoint's branded portal (recommended), the property's guest experience doesn't change at all — same branded sign-in page, same consent/analytics. If the WiFi controller talks straight RADIUS to Radiator instead (bypass), their controller's captive portal needs to be pointed at Radiator directly, and Waypoint loses branding, consent, and analytics for that property's guests entirely. Decide this before the first legacy-PMS property — it changes what you ask their IT team to configure.
Suggested order for the first pilot property
Only relevant once a property has actually confirmed it wants something from the add-ons above — most properties never reach this section at all.
- Decide the scope802.1X, the legacy-PMS path, or both.
- Stand up the WireGuard peer firstRegardless of feature — it's the one piece every other step depends on. Generate the property's keypair from the Connections tab, add the peer server-side, then confirm with the dashboard's Test VPN button (or a manual wg show handshake / ping) before anything else is built on top of it.
- Gather AD or PMS access details in parallelBind account, base DN, CA cert, or PMS server IP/port — doesn't need to wait on step 2 finishing.
- Build the real per-property config blocksFreeRADIUS's ldap-<slug> module and/or Radiator's Handler block.
- Register the WiFi controller(s) as RADIUS clients lastOnce the backend config is confirmed working — this is the step that actually turns on real device traffic.
- Run the verification tiers before going liveAlready documented in each service's own reference doc — confirm before telling the property it's ready for real staff or guests.