Set up Content Replication between Backstage servers

Last updated 7 August 2026

The Replicate feature keeps project files and media assets in sync across several Backstage machines over the network. One machine is the Primary — the authoritative source — and one or more are Replicators, which pull updates from it.

Typical uses: a hot standby for live events, identical content running on several servers in parallel, or pushing a show to a remote venue without transferring files by hand.

How it works

The Primary runs an HTTP server exposing the current project and assets. When something changes — a project is saved, an asset imported — it notifies every connected Replicator over a persistent WebSocket. Each Replicator downloads only the files that actually changed, verified by MD5 checksum, and reloads the project once the sync completes.

Sync is always one-way, Primary → Replicator. Local edits on a Replicator are overwritten by the next sync.

Primary setup

Nothing to configure. Run Backstage as normal — the REST server that powers replication starts alongside the main HTTP server.

Optional controls under Settings → Replicate → Primary:

Setting	What it does
Block Replicators	Stops all Replicators pulling files — useful during maintenance or while preparing a project, so a half-finished state is not pushed out. Clear it to resume syncing
Connected Replicators	Lists the hostname or IP of every Replicator currently connected. Hover an entry for the raw IP address

Replicator setup

First-time setup

Open Settings → Replicate → Replicator.
Choose a Sync Scope and configure its options — see below.
Choose a Sync Mode. Event-driven suits most installations.
Click Sync Now for the initial pull, and wait for Status: idle.
Check that the project and asset files are present locally.

Automatic startup

Recommended for permanent installations:

Tick Start as replicator.
Enter the Primary's IP address, for example 192.168.1.100.
Restart Backstage. On the next launch the machine connects to the Primary and starts syncing by itself.

The restart is required — a note next to the checkbox says so. The setting has no effect until then.

Sync scopes

The scope decides which files on the Primary are offered for download.

Scope	What is synced	When to use
Active assets (default)	All `.bbsm` project files plus the media currently loaded in the Primary's asset manager	Most installations — exactly what is playing, nothing more
Mirror folder	Everything inside one folder path on the Primary	Replicating a defined media library regardless of what is loaded
Mirror drive	Everything on one drive letter, except the project backup folder	Full-drive hot standby — be aware of the sync volume

Set this under Settings → Replicate → Replicator → Sync Scope. For Mirror folder give the absolute path on the Primary; for Mirror drive give the letter only — D, not D:. Drive C: is excluded from the list, so system files are never synced.

Sync modes

Mode	Behaviour
Event-driven (recommended)	The Replicator listens for change notifications over WebSocket. Saving a project triggers a project-only sync; importing an asset triggers a full one. Near real-time
Manual	Nothing syncs automatically. Use Sync Now, or trigger the `ReplicatorSync` node from the node editor

Nodes

Two nodes in the Replicate category bring replication into show logic.

ReplicatorSync

Triggers a sync and reports when it finishes.

Pin	Direction	Type	Description
`trigger`	Input	Bang	Fire to start a sync
`syncComplete`	Output	Bang	Fires when the sync finishes
`syncInProgress`	Output	Int	`1` while syncing, `0` when idle

Chain it before a sequence start so content is always fresh before playback begins.

ReplicatorStatus

Polls the Primary and reports whether it is reachable.

Pin	Direction	Type	Description
`isPrimaryAlive`	Output	Int	`1` if the Primary responds, `0` if unreachable

Set Poll interval (ms) in the node's options — default 2000. The output changes only when the status changes, so it can drive conditional logic directly without debouncing. Use it for a fallback sequence that plays local content when the Primary goes offline.

Authentication

The replication endpoints use HTTP Basic authentication, and both machines must use the same credentials. Configure them under Settings → Replicate → Replicator.

Setting	Default
Username	`admin`
Password	`admin`

Traffic is not encrypted — there is no TLS. Use replication on trusted internal networks only, and change the default credentials on both machines if the server is reachable from anywhere else.

Checking the status

The Status line under Settings → Replicate → Replicator shows idle when connected with nothing in progress, and syncing… during a sync.

The Log window records every file downloaded, any file-lock retries, and completion:

ReplicatorManager: connected to primary WebSocket
ReplicatorManager: full sync started
ReplicatorManager: updated Projects/MyShow.bbsm
ReplicatorManager: sync complete

If the connection drops, the Replicator retries by itself with exponential backoff — starting at one second, doubling to a maximum of thirty. No intervention is needed.

Common Mistakes

Nothing syncs after ticking "Start as replicator" — the setting takes effect only after a restart.
Edits made on a Replicator disappear — sync is one-way and the Primary always wins. Make changes on the Primary.
A Mirror drive scope will not accept the drive — enter the letter alone, D rather than D:. C: is not offered at all.
Replicators sit idle during preparation — Block Replicators is still set on the Primary from an earlier maintenance window.

Known limitations

Limitation	Detail
One-way sync only	Primary → Replicator. Local edits on a Replicator are overwritten on the next sync
No conflict resolution	The Primary's version always wins
No selective exclusion	File types or paths cannot be excluded within a scope. Use Active assets to limit what is synced
No TLS	Traffic is unencrypted — trusted internal networks only
Follower role not implemented	The Follower option is visible in Settings but disabled. Only Backup, which reloads the project automatically, is functional
File locking	If Windows holds a file open — a virus scan, an Explorer preview — the replacement is queued and retried on the next sync. Nothing is lost

Node Editor Window — where the ReplicatorSync and ReplicatorStatus nodes live

Settings — the Replicate section in full