BackstageOS – Unified Live Production, Local-First Architecture, and the End of the Siloed Rig
1. Introduction: The Backstage Patchwork Nightmare
Right then, pull up a chair, grab a stool, and let me get this round in. What are you having? A pint of bitter? Excellent choice. Let us settle in by the hearth and talk about how we actually run live performances, because if you have ever stood behind the tech table during a major theatrical opening, you already know that the emperor has no clothes—and worse, the lighting console is on a different VLAN than the soundboard while the prompt book is getting soaked in coffee behind a pillar.
It is ten minutes to half-hour. The house lights are at fifty percent, the foyer is buzzing with the murmur of arriving patrons rustling through programmes, and backstage is a scene of organized chaos. The lighting designer is huddled over a massive, proprietary lighting console that cost as much as a family car. The sound operator is staring intently at a completely separate digital audio workstation, double-checking headphone mixes and reverb tails. Cue playback is sitting on a standalone laptop running dedicated cue software, while the video rig is off in its own closed-ecosystem media server world, outputting through a matrix switcher. Meanwhile, the deputy stage manager is holding a thick, dog-eared paper binder full of call sheets, pencil annotations, and timing notes, trying frantically to cross-reference cue calls against a chaotic barrage of urgent messages incoming on WhatsApp groups and closed-hardware intercom belt packs.
If you have spent five minutes backstage before curtain call on a major show, you know the exact brand of quiet, cold panic I am talking about. It is a proper nightmare. We are running million-pound live productions on a brittle patchwork of isolated technological silos. Lighting does not know the set geometry; sound does not know the video cues; and the master paperwork lives in a completely different universe from the actual execution hardware. If an assistant stage manager misplaces a binder, if a local wireless router hiccups, or if a proprietary USB licensing dongle falls out of its socket, the whole house of cards threatens to come tumbling down.
The underlying structural issue is plain for anyone with eyes to see: live production—whether theatre, arena touring, broadcast television, or corporate events—relies on tools that simply refuse to speak to one another without custom, hand-crafted glue, MIDI translation boxes, and endless manual re-entry. Worse still, eye-watering licensing costs, extortionate proprietary dongle requirements, and recurring subscription fees price out independent theatre companies, community fringe groups, and educational venues entirely.
So, what if we threw out that legacy patchwork? What if, instead of gluing ten proprietary systems together with duct tape and prayers, a live production ran on a single, local-first, peer-to-peer operating system? Imagine an open architecture built around one shared production graph—a system that scales seamlessly from a solo technician running a fringe show off a single laptop, all the way up to a venue-wide mesh of dedicated hardware appliances coordinating multi-stage festivals.
That is the core architectural philosophy behind conceptual models like BackStageOS, VenueOS, and the Maestro hardware line. To be clear, these are not finished, off-the-shelf commercial products you can buy off a shelf today; rather, they represent a grand architectural framework for how live production software ought to be designed from the ground up.
So, drink up. Let us take an exhaustive, deep-dive guided tour through the core architectural pillars, data models, network topologies, and philosophical takeaways behind this unified digital stagecraft revolution.
2. Vision and Market Thesis: One Operating System for the Show and the Building
Live production software is currently dominated by expensive, proprietary product suites that lock users into closed ecosystems. Smaller production companies, fringe theatre troupes, community groups, and educational venues are entirely priced out of professional-grade tools. Meanwhile, across the software engineering landscape, open-source, AI-assisted reimplementations of once-proprietary creative tools are becoming mature, stable, and entirely viable.
The market thesis of BackStageOS is built on four bedrock convictions: First, an open, affordable alternative is desperately wanted by a large, underserved market segment that cannot justify five-figure software licensing fees. Second, the true product differentiator is integration—having one graph, one runtime, and every subsystem designed to work together from day one—rather than any single standalone feature. Third, individual apps that are adoptable on their own but integrate seamlessly into the wider stack provide the correct go-to-market path, meaning nobody has to buy the whole operating system just to use a single tool. Fourth, an open operating system paired with commercial hardware appliances, alongside professional support and hosted services, forms a coherent, sustainable funding model.
The product family spans three distinct tiers sharing a single core graph, runtime, mesh, and identity stack. BackStageOS is the production operating system covering every stage of a show from pre-production through broadcast. VenueOS is the venue operating system handling building software like digital signage, box office, point of sale, and facility systems. Finally, Maestro represents the physical hardware console product line.
This vision merges two conceptual research and development streams: the Carnaby Media Hub, which envisions a rich, single-site facility with dedicated consoles, and the Festival Mesh, which focuses on distributed, resilient, portable, and multi-site touring infrastructure.
3. Architecture Part I: The Two-Plane Split (Authoring Graph vs. Execution Runtime)
Here is a classic trap that software developers fall into the second they decide to build a modern collaboration tool for the stage: they assume that because live teams need to edit cue stacks together in real time, the live execution engine should run directly on top of a live collaborative database.
If you try that in a theatre, you will destroy your show. A bit of a cock-up, as we say down the pub.
In a modern collaborative document editor, you typically use Conflict-Free Replicated Data Types, or CRDTs, to allow multiple users to edit data offline or across a network and merge those edits asynchronously. CRDTs are brilliant for document editing. But if you put a CRDT directly inside the real-time cue execution loop during a live performance, network jitter or asynchronous state resolution will introduce micro-delays. In live theatre, a millisecond of network jitter on the hot path means a blackout lands late or a sound effect misfires.
The solution is an absolute structural boundary: the strict separation between the Authoring Plane, which is the graph, and the Execution Plane, which is the runtime.
To understand how the architectural stack flows from top to bottom, imagine a series of distinct layers. At the very top are the user surfaces—desktops, department consoles, Maestro hardware, and mobile tablets—which act as views and editors onto the graph and runtime. Directly beneath them sits the Authoring Plane, powered by the local-first production graph using CRDTs and containing core and pluggable domain namespaces. Beneath authoring is the Placement layer, which handles node manifests and maps abstract intent to hardware capabilities. Below placement are the Input/Output engines handling lighting protocols like sACN and Art-Net, audio via AES67 and Dante, video via NDI and SDI, and control via OSC and MIDI. At the absolute foundation is the Mesh layer, providing peer-to-peer transport and a content-addressed storage fabric.
The production graph serves as the point of contact for everything. It is local-first, multi-user, and asynchronous, holding every authored fact including script annotations, cue stacks, fixture profiles, schedules, and design assets. Every department edits here, and every surface reads from here.
When a show is armed, the relevant slice of the graph is compiled into a deterministic show file. The runtime loads that file and runs the cue engine and timeline. There is zero CRDT processing on the hot path, ensuring absolute zero jitter. The runtime holds the Show Position, which is one shared cursor combining timecode, script position, and cue state. Everything live reads from it, and execution telemetry is written back into the graph log.
4. Data Model: Stable Core and Pluggable Domain Namespaces
The production graph must be stable enough to build reliable software on, yet extensible enough that individual departments can add their own custom data without forcing changes to the core or coupling their release cycles together.
To avoid the classic failure mode of one giant, monolithic schema that tightly couples every department’s lifecycle, the data model adopts a two-tier structure. The core consists of a small, stable collection of universally meaningful entities, including shows, spaces, people, timebase references, and high-level cue nodes. The namespaces consist of first-class domain documents such as lighting, audio, video, stage, and costume data that a department tool can own and evolve independently.
Furthermore, cross-cutting concerns are designed in from day one, including role-scoped visibility on every node to ensure lighting data is naturally scoped to lighting staff, whole-document versioning and undo, and content-addressed asset storage.
5. Identity, Keypairs, and Permissions: Rooted in Cryptography, Not Cloud Servers
Let us talk about the cloud for a second. We have all seen corporate software shift toward mandatory cloud connectivity over the last decade. But imagine standing in the tech booth three minutes before curtain call, and you cannot light the spotlight or trigger the opening soundscape because an Amazon Web Services data center in Dublin is experiencing an outage, or the venue’s local Wi-Fi router decided to drop off!
Relying on a cloud-first architecture for live performance is absolute show-death. The architectural alternative is a local-first, peer-to-peer model backed by cryptographic keypair identity.
In this system, identity is rooted entirely in asymmetric keypairs rather than a central login server. Every physical appliance or computer node on the network generates and holds its own cryptographic node key. Every human operator, from stagehand to lighting programmer, owns a personal cryptographic keypair.
Addressing a person by their email address or handle is simply a user-experience convenience that resolves down to their underlying public key. Human operators unlock their keys locally without passwords using modern passkeys and WebAuthn standards. Permissioning is handled via signed grants, which are cryptographic assertions stating that a specific key is granted a specific role for a specific production.
Because these grants are cryptographically signed, they work entirely offline without needing to check in with a central server. The cryptographic keypairs used for application permissions align directly with the node identities used for the built-in remote overlay network, such as WireGuard-class site bridges.
If a venue management server or cloud control plane goes dark, active role grants remain valid, local peer-to-peer synchronization continues across the local network, and the performance carries on without a hitch. Control planes, such as web-based administrative consoles used to onboard staff, exist purely as optional convenience peers. If the web admin server drops offline entirely, you simply cannot onboard new people until it returns, but the active show plane never stops.
6. Runtime, Compile Contract, and Failover
The Compile Contract and Maturity Levels
The show moves through four distinct maturity levels, with edit rights differing per level and locks applied per-field and per-department rather than as an all-or-nothing switch.
During the Draft phase in pre-production, anything is editable, allowing teams to design, build cue stacks, annotate scripts, and map cues. During the Rehearsal phase in tech and dress runs, teams can make tweaks to armed values, cue timings, and levels, but full reprogramming is restricted. During the Armed state, the compiled show file is frozen, validated, and rendered entirely deterministic. During the Live performance, the base show file is completely locked down, with the sole exception of the deterministic live override layer.
The compiler takes the relevant slice of the graph and produces a deterministic, versioned show file, catching breakage at arm-time, such as a cue referencing an unpatched fixture, rather than at curtain-up.
The Override Layer and Debrief Capture-Back
Real shows require manual intervention mid-performance—bumping a fader for extra front light or running an additional chase at the last minute. The runtime features a deterministic Live Override Layer sitting on top of the armed show file that remains always editable by authorized users.
Every manual override is logged with complete context, including who made the change, when it occurred, which cue was active, and the before-and-after values. After the show, the Debrief Capture-Back workflow presents every recorded override with three actionable options. Operators can fold the tweak permanently into the master cue stack, mark it as a planned manual operation to make future runs predictable, or discard it as a one-off panic fix that should not alter the permanent show file.
Network-Native Outputs and Failover
If you walk up to a traditional lighting or media playback rig today, you will usually find a hardware USB licensing dongle plugged into the back of a single computer. If that computer’s power supply dies mid-show, you can fail over the software brain all day long, but you cannot fail over the physical output pipe without physically ripping out USB cables behind the rack.
To achieve true, zero-downtime redundancy, control outputs must be network-native. This includes sACN and Art-Net for lighting control, AES67 for network-synchronized audio, and NDI alongside SMPTE ST 2110 for video transport over standard Ethernet.
Machines broadcast their hardware capabilities via node manifests, and a placement matrix dynamically binds abstract logical intent to network endpoints. If a primary engine node stops sending heartbeats, a hot-standby backup node takes over streaming sACN or AES67 directly to the exact same network edge appliances.
7. Engines and Interoperability: Bridge First, Own Later (The ArtCraft Suite)
When technical folk set out to solve live production problems, they often try to build open-source replacements for every creative tool simultaneously—a trap that ensures a project never ships. The real competitive moat in live production is not any individual creative tool; it is domain integration.
The guiding principle is Bridge first, own later, anchored by the standing adapter rule. First, prefer integration by wrapping and driving existing open software. Second, rebuild only when necessary—when an existing tool cannot be controlled, its user experience is a fundamental blocker, or no adequate alternative exists. Third, always connect through the graph, so bridged and in-house engines feel like one unified system.
The ArtCraft Suite
The emergence of modern open-source initiatives like the pure-Rust ArtCraft suite—including CADCraft for CAD, SoundCraft for audio, FilmCraft for video, and WordCraft for documents—provides clean-room reimplementations of major creative applications. These tools expose structured control channels, JSON APIs, and Model Context Protocol servers, separating user interface layers from core logic so every menu action can be driven headlessly over inter-process communication.
Audio: SoundCraft vs. The Live Runtime
It is vital to understand that SoundCraft is a brilliant audio workstation engine, but it is not a live-show engine out of the box. SoundCraft provides digital signal processing, plugin hosting, mix engines, and timebase management. However, it lacks cue-driven deterministic playback fired from the Show Position cursor, low-latency live input mixing, multi-monitor in-ear monitor mixes, matrix routing across network nodes, and the armed and locked show model.
The division of labor is precise: we reuse SoundCraft’s digital signal processing and audio crates for audio processing, while our live runtime sits on top to provide deterministic cue execution and matrix routing. SoundCraft makes sound; our runtime decides when.
8. Mesh, Remote Access, and Tunnelling: The Festival Mesh and WAN Architecture
Operators, designers, and producers increasingly operate from remote locations, requiring BackStageOS to connect them securely without a central point of failure and without forcing everyone onto the venue local area network.
Remote connections are divided into two distinct requirements: remote authoring and collaboration, which is latency-tolerant and asynchronous, and remote operation and monitoring, which is latency-sensitive and requires fail-safe execution.
Crucially, remote users join the control and authoring plane, and never the real-time data plane. The wide-area network carries intent, state, telemetry, and content-addressed blobs, while physical media transport including AES67, Dante, precision time protocol, SDI, and ST 2110 stays local to each site.
Two Transports
For connectivity, the system relies on two mechanisms. First, the app-level peer-to-peer mesh uses a QUIC-based, hole-punched, and relay-assisted transport—leveraging Rust candidates like Iroh—providing zero-config connectivity where identity is tied directly to node keypairs and grants. Second, the built-in virtual network site bridge utilizes a WireGuard-class overlay, using userspace implementations like boringtun coordinated via open self-hosted control servers like Headscale, extending a venue’s network to authorized remote nodes so legacy LAN-oriented protocols function seamlessly.
The underlying transport standard is MASQUE over HTTP/3, ensuring outbound-only connections, direct-by-default hole punching, and relay roles that any peer can assume without mandatory central servers.
9. Collaboration and Comms: Cue-Aware Intercoms and Local-First Chat
Backstage communications are traditionally siloed on rigid hardware intercoms or disconnected chat apps. BackStageOS treats comms as a first-class feature integrated directly into the production graph.
Text communications are implemented as a local-first replicated log that syncs over the mesh, working offline and healing automatically. Voice and video are WebRTC-class, direct-by-default audio channels with hub nodes acting as selective forwarding units or relays for larger groups.
Because the comms matrix is tied directly to the live Show Position, communications become cue-aware. As the system nears a high-risk sequence, such as pyrotechnics, the runtime automatically establishes standby talk paths and visual prompts between the stage manager and relevant operators. All voice communications and chat events are timecoded directly into the graph log, turning backstage chatter into searchable documentation for post-show debriefs.
10. VenueOS: Managing the Entire Building from One Pane of Glass
Long term, BackStageOS extends beyond individual show management into a full building operating system called VenueOS. Sitting as a peer to the production graph, the venue graph models the physical building hierarchically from the venue itself down to individual spaces including the main house, studio, foyers, and breakout rooms, as well as resources like rigging, power dimmers, network ports, audio input and output, sightlines, seating, and venue CAD geometry, alongside staff members.
Visiting productions link directly to these spaces via residencies and bookings. Digital signage, box office ticketing, and bar point-of-sale systems all draw from this identical structural substrate.
The Regulatory Boundary for Life Safety
When integrating with building automation systems like HVAC, lighting, and security via standard protocols such as BACnet, Modbus, or KNX, VenueOS operates strictly in a read-mostly, advisory capacity. Certified fire alarm panels and life-safety systems are regulated by law; uncertified software must never be granted authority to override life-safety controllers. VenueOS surfaces environmental telemetry and requests sanctioned, time-bounded isolation modes through official protocol interfaces while leaving ultimate authority in the hands of certified hardware.
11. Version Control & Reuse: Git-Like Immutability for Cue Stacks and Assets
BackStageOS introduces Git-like version control across the board for a very practical reason: allowing a creative team to pull up a cue stack from a previous show, lift a brilliant lighting chase or sound effect, and drop it into a new production.
The model layers CRDTs and version control cleanly. The CRDT handles live, concurrent, offline collaborative editing of working states. Snapshots and commits provide immutable, content-addressed points in time. Branches and tags establish named lines of history, such as opening night as performed. Finally, provenance tracks precisely which graph revision a compiled show file originated from.
Assets, including sound files, lighting presets, and master vector graphics, are stored as content-addressed blocks in an immutable library. Cross-show reuse operates via copy-by-reference, and master design assets enforce an author-once, derive-many workflow across all downstream print, video, and signage targets.
12. Roadmap and Horizons: From Milestone 0 to Horizon 4 (Adjacent Markets)
The development roadmap is organized into four distinct horizons prioritized by user value and architectural dependency.
Horizon 1 focuses on the operating system core, proving the spine end-to-end around Milestone 0, known as “The Pulse,” which features a single program running one production, one fixture, one cue, one sACN packet, and one GO button. This establishes the production graph, compile contract, runtime, node placement, keypair identity, and manual failover. Horizon 2 implements department apps and interop with CADCraft and SoundCraft. Horizon 3 delivers the broader platform, including VenueOS venue management, digital signage, box office, point of sale, building system integration, broadcast-out, cross-site touring federation via the Festival Mesh, and the physical Maestro console family. Horizon 4 gates adjacent markets, exploring virtual production pre-viz, virtual sets, timecoded lighting for games, and integrated newsroom live switching using the core rendering and mesh infrastructure.
13. Conclusion: The Stage Is Set for an Open-Source Revolution
We have covered a massive amount of ground over this pint, haven’t we?
From splitting the authoring plane from deterministic live execution, to ditching cloud dependencies in favor of local-first peer-to-peer keypairs; from routing network-native outputs to eliminate fragile hardware dongles, to building cue-aware comms and content-addressed asset libraries—the underlying philosophy remains singular: live production technology must move away from expensive, brittle, closed silos toward an open, integrated, local-first operating paradigm.
The underlying building blocks to realize this vision—pure Rust runtime systems, local-first CRDT databases, network-native audio and video transports like AES67 and NDI, and open interchange standards like MVR and GDTF—exist right now. The remaining work is assembling these pieces into a unified, accessible ecosystem that places creative control back where it belongs: in the hands of the artists and technicians working backstage.
So, as we finish off this final round and head off toward the theatre, let me leave you with one thought-provoking question to chew on:
If we break down the technological silos between lighting, sound, video, and venue management in your own creative space, what incredible live experiences could you build that were previously impossible?
