cueSystem network setup#

cueSystem is wired-Ethernet by design — a cue light system is a real-time safety-relevant piece of kit, and WiFi is the wrong substrate for "the SM hits Go and three people fire props within 100 ms". That said, the clients (laptops in the booth, tablets at FOH, phones in the wings) can perfectly happily sit on the venue's wireless network so long as it's the same broadcast domain or there's a route to the cueServer. This wiki covers all of that.

The quick start gets you onto the simple defaults. Read this if your venue already has a network with multiple devices on it, VLANs, captive portals, or you want to lock cueSystem down further.

What it talks, and on which ports#

There are no outbound connections to the public internet — cueSystem is fully local. It doesn't phone home, doesn't need a cloud account, and works on an air-gapped venue LAN.

Default network behaviour#

When the cueServer boots:

1. It requests a DHCP lease. Hostname advertised: cueserver.
2. If DHCP succeeds, that's the address everyone uses (visible as cueserver.local on networks that support mDNS — virtually all modern home / venue routers do).
3. If DHCP fails twice (back-to-back), the cueServer falls back to a static address — see below — and starts its own DHCP server so the cueDesk can still get an address on a "no infrastructure" setup.

The cueDesk does the same thing for client mode (DHCP first, fall back to a self-assigned link-local in the 169.254.0.0/16 range), but the desk never runs its own DHCP server.

Static fallback#

If DHCP is unavailable on the LAN:

When the cueServer is in fallback-DHCP-server mode, its status LED switches to pulsing amber. That's a useful signal in the booth: if you see amber, it means cueSystem is keeping itself running but the venue's own DHCP server isn't reachable — worth telling IT after the show.

You can disable the fallback DHCP server from Settings → Network → Fallback if you don't want it to take over a misconfigured LAN.

Setting a manual static IP#

If your venue has a fixed-address policy, set a manual static from Settings → Network → IP mode:

After applying, the cueServer reboots; the cueDesk re-discovers within a few seconds.

Typical wiring topologies#

The most common setups, in increasing complexity:

Single switch, single subnet#

                          ┌──────────────┐
            ┌─── port ────│  cueServer   │
            │             └──────────────┘
            │
 ┌──────────┴──────┐      ┌──────────────┐
 │  venue switch   ├─port─│   cueDesk    │
 └──────────────┬──┘      └──────────────┘
                │
                └── port ──── booth laptop, FOH tablet, etc.

Everything on the same VLAN. The default config "just works" — DHCP from the venue router, mDNS for cueserver.local. This is what most amateur and small-pro venues should run.

Dedicated production VLAN#

If your venue already separates production traffic from house WiFi:

• Put cueServer + cueDesk + production laptops on the production VLAN.
• House WiFi clients (FOH tablet, backstage phone) need a route into the production VLAN — either a port-based exception on your switch, or a layer-3 route on your firewall. mDNS does not cross VLANs without an mDNS reflector (most enterprise APs / firewalls have one — Ubiquiti's "mDNS reflector", Meraki's "Bonjour gateway", etc.).
• If you can't enable mDNS reflection, set a static IP for the cueServer and have remote clients bookmark it directly (http://10.42.0.5/ etc.).

Production VLAN with WiFi-only stations#

The most common modern setup. Wired cueServer + cueDesk on a production VLAN, but the SM wants to use an iPad and the ASM has a phone. Two things to get right:

1. The WiFi must be the same SSID as a network with a route into the production VLAN. House WiFi -> guest VLAN -> firewalled off from production won't work.
2. Battery-conserving mDNS suppression on the AP may eat the discovery. Either enable mDNS reflection or hand out the cueServer's IP explicitly.

For shows where WiFi reliability is critical we strongly recommend running cabled connections to the SM desk and any FOH op — WiFi packet loss during a Go is no fun.

Air-gapped (no venue LAN)#

Sometimes you're in a black box without any infrastructure. cueSystem still works:

1. Plug cueServer + cueDesk into a cheap unmanaged switch (any £15 5-port box).
2. Power both with USB-C.
3. The cueServer's fallback DHCP server hands addresses to the desk + any laptops you also plug in. mDNS still works because it's just multicast — no router or DNS server needed.
4. Connect a laptop or tablet via Ethernet adapter and visit http://cueserver.local/ (or http://10.20.0.1/).

If you want WiFi clients on an air-gapped network, plug a small access point (any consumer AP in AP-only mode) into the same switch; it'll pick up DHCP from the cueServer just like the laptop did.

Network troubleshooting#

"cueDesk's status LED stays cyan" — desk can't find the cueServer#

In this order:

1. Visit http://cueserver.local/ from a laptop on the same LAN. If that fails too, mDNS isn't working — the desk is doing the same lookup. Find the cueServer's IP from your router's DHCP list and try http://<ip>/ instead.
2. Make sure both devices are on the same VLAN. Managed-switch port-isolation is the usual culprit.
3. Verify the cueServer is up — its front LED should be steady green (or pulsing amber if it's in fallback-DHCP-server mode).
4. As a last resort, pair manually from cueServer Settings → Devices → paste the desk's serial.

Browser disconnects mid-show#

The browser UI uses a WebSocket. If your network has aggressive idle-timeouts on TCP connections (some captive portals do this), connections drop after a few minutes of "no cue activity". A standby Stand By followed by Clear is enough to keep the channel marked alive every few minutes; or whitelist the cueServer's IP in the captive portal's bypass list.

Two SMs accidentally connected to two different cueServers#

If you have more than one cueServer on the same LAN — which is unusual but possible during a venue migration — cueserver.local will resolve to whichever responded first. Rename one of them in Settings → Network → Hostname so they're easy to tell apart, and have your operators use the full host (http://cueserver-mainstage.local/ etc.).

Security posture#

• No authentication by default. cueSystem ships open on the assumption that the venue LAN is trusted. Anyone with network access can fire cues — which is almost always what you want during tech.
• Add a passcode from Settings → Operators if non-production users share the LAN.
• mDNS doesn't escape the broadcast domain. External browsers (e.g. a remote tech consulting over a VPN) can still reach the cueServer by IP if your firewall lets them, but neither device "phones out".
• No firmware-update path is exposed to the WAN — updates are pushed to the cueServer over the LAN from a laptop.

What to read next#

• cueDesk operator reference — exact button + LED behaviour for the hardware desk.
• cueSystem quick start — if you haven't got the basics yet.