Best PracticesMulti-Site Venue Deployment

Multi-Site Venue Deployment

How to author a show once and run it across multiple permanent installations — local control on each site, plus centralized cloud monitoring and remote command from anywhere.

The model

You author shows on your studio laptop in Desktop Mode. Each venue runs PRISMATIK in Venue Mode — the same installer, the same binary, with a runtime flag flipped that boots the operator-grade interface instead of the dashboard. Each venue runs its own local schedule + Art-Net output + process watchdog. They optionally heartbeat to the PRISMATIK cloud so you can monitor and command them from my.prismatik.run/dashboard/venues.

On a single site with multiple machines (control room + FOH + GreenRoom rack), they form a mesh via mDNS — one designated hub holds the authoritative schedule, the others run as spokes. The hub can push schedule changes to all spokes at once.

              ┌───────────────────────────────────┐
              │  Your studio laptop (Desktop Mode) │
              │  - authors shows                   │
              │  - exports project folders         │
              └────────────┬──────────────────────┘
                           │
              ┌────────────▼──────────────────────┐
              │  Cloud: my.prismatik.run          │
              │  - Venues dashboard               │
              │  - Remote commands                │
              └────────┬─────────┬────────────────┘
                       │         │
        ┌──────────────▼─┐    ┌──▼──────────────┐
        │  Venue A       │    │  Venue B        │
        │ ┌───────────┐  │    │ ┌────────────┐  │
        │ │ Hub       │  │    │ │ Hub        │  │
        │ │ (mDNS)    │  │    │ │ (mDNS)     │  │
        │ └─────┬─────┘  │    │ └─────┬──────┘  │
        │   ┌───▼──┐     │    │   ┌───▼──┐      │
        │   │Spoke │     │    │   │Spoke │      │
        │   └──────┘     │    │   └──────┘      │
        └────────────────┘    └─────────────────┘

Authoring → Deploying — the round trip

On your studio laptop (Desktop Mode)

  1. Build the show — schedule, output config, process watch, hold-screen branding, startup auto-launch.
  2. Save the show. PRISMATIK serializes a venueConfig snapshot into show.json.
  3. Use Project Folder Workflow to put the project in a sync’d folder, or just zip + transfer.

On the venue machine (first-time setup)

  1. Install PRISMATIK like any normal desktop install.
  2. Open Venue Mode Setup → Enable Venue Mode → Restart.
  3. On next boot, PRISMATIK opens the Venue Shell (hold screen → operator UI).
  4. Open the show. PRISMATIK detects the embedded venueConfig and applies it — schedule runner recalculates, output snaps to the right state for current time-of-day.
  5. Restart once more so the OS-level startup integration kicks in (PRISMATIK auto-launches with the machine; companion media server auto-launches with PRISMATIK).

That’s it. Site is live.

Multi-machine on one site (Hub / Spoke)

When you have multiple PRISMATIK instances at the same venue (e.g. control rack + FOH redundant pair + a green-room status display), they should form a session mesh:

Choosing a hub

The hub is the authoritative instance — its schedule wins, its overrides propagate. Pick whichever machine is most reliable / closest to the operator workflow. FOH and control rack are common choices.

Creating the session (on the hub)

  1. Venue Mode → Config → Network
  2. Create Session → name it (MainStage, Lobby, etc.) → set a 4-digit PIN → role = Hub

Joining (on each spoke)

  1. Venue Mode → Config → Network
  2. Available Sessions lists nearby instances via mDNS — should auto-detect the hub
  3. Click → enter the PIN → role = Spoke

Verifying the mesh

Open Flow Tool → Live Topology on the hub. You should see:

  • Yourself in the centre (green, crown icon = host)
  • Each spoke around you (green = in session, with edge to centre)

Red node = a peer that hasn’t been heard from in 60s. Check the LAN.

Cloud sync (optional but recommended)

Each Venue Mode instance can heartbeat to dashboard.prismatik.run (the PRISMATIK Venue Cloud API). Enable it in Config → Cloud → toggle on → enter the API token from your org.

What you get:

  • Live online/offline status of every venue in your account at my.prismatik.run/dashboard/venues
  • Remote command queue — send “Force On”, “Force Off”, “Reload show”, “Restart instance” from anywhere
  • Last-heard timestamps and basic health (CPU/mem) per instance

Cloud sync is per-instance opt-in. If a particular site shouldn’t talk to the cloud (security policy, fully offline), leave it off. Local mesh + local control still work.

Day-2 ops

Pushing a schedule change to all venues

If all venues are in one cloud account: edit the schedule on your studio laptop → save → use the cloud dashboard’s Push Schedule action. Each venue receives the update on its next heartbeat (within 30s) and applies it.

If venues are isolated (no cloud): you ship a new project folder by hand (USB, sync folder, scp). Operator opens the new show.

Override for an unscheduled event

  1. Cloud dashboard → pick the venue → Override → pick state + fade duration → send.
  2. Venue picks it up on next heartbeat (≤30s) and applies.
  3. Override persists across reboots. Send “Back to Auto” when you want the schedule to resume.

Diagnosing a venue that went offline

  1. Cloud dashboard → last-heard timestamp on the venue → if >2 minutes, something’s wrong on-site.
  2. Check the venue’s mDNS visibility from another LAN machine (Flow Tool Live Topology).
  3. If LAN-visible but cloud-offline → outbound HTTPS to AWS API Gateway is blocked. Talk to venue IT.
  4. If LAN-invisible → machine is off, network is down, or PRISMATIK crashed. Process watchdog handles the third case; the other two need site presence.

Replacing a venue machine

  1. Image the new machine with PRISMATIK installed.
  2. Copy the project folder (with venueConfig snapshot) onto it.
  3. Enable Venue Mode → Restart.
  4. Open the show — config applies, schedule recalculates.
  5. Join the session mesh (Config → Network → Available Sessions → pick + PIN).
  6. Done. The new machine inherits all the venue’s behavior automatically.

Common pitfalls

“mDNS doesn’t cross subnets.” True. Multi-machine sessions only work if all participants are on the same LAN subnet. For multi-site you need the cloud sync, not mDNS.

“Override won’t clear after reboot.” By design — overrides persist. Set explicitly to Auto to release the schedule.

“Two hubs after a network partition heals.” Rare but possible. The session that started later usually loses host role on next heartbeat. If both persist, both leave and one re-creates.

“Watchdog kept restarting Ai and now the whole machine is in a reboot loop.” Set restart-attempt limits sensibly: e.g. “restart after crash, but if 3 restarts in 10 minutes, escalate to OS reboot once and then stop.” Default thresholds prevent runaway loops but verify.

Related

Working on a Show from Two MachinesProject Folder Workflow