Composer Runtime

The Composer Runtime is a stand-alone application — separate installer, separate licence — for playback of projects authored on Composer Desktop. It runs as a console application without a graphical interface, using the same compositing engine and GPU pipeline as Desktop. Available on Windows and Linux.

Important — licensing

The Composer Runtime licence is separate from the Composer Desktop licence. A project authored on a licensed Desktop installation will still need a Runtime licence on each host that runs the project headless.

Note — not available on Core licences

The headless Composer Runtime is not available under a Vindral Composer Core (free) licence. VindralComposerRuntime.exe refuses to start, logs Core license is not valid for the headless Runtime., and exits with a non-zero code. Core is a Desktop-only tier; upgrade to a Subscription or full licence to deploy the Runtime. See Activating a license for licence-tier details.

For driving a running Runtime instance over HTTP, see the Runtime API manual; for picking which of Composer's many control surfaces to integrate against from outside, see Integration & Runtime.

When to use Runtime

Common deployment scenarios:

• Headless production hosts — run the show on a server without paying for a Windows GUI session and without giving an operator anything to accidentally click.
• Container deployment — Linux Runtime fits naturally into Docker / Kubernetes infrastructure (with NVIDIA GPU passthrough). Windows GPU container support is pending NVIDIA driver work.
• Cost reduction — fewer Windows licences for fleet-deployment use cases.
• Read-only production — Runtime treats the project as read-only by default, which means an operational mistake on the runtime host can't corrupt the master project.

For one-off prototyping or live-show authoring, use Composer Desktop. The Runtime is purpose-built for stable, automated playback.

Exporting projects from Desktop to Runtime

A few practices keep cross-host playback predictable:

• Use relative paths. Drop your media into the project's own Media/ folder so paths inside the .prj are relative; the project then opens identically on any host. File → Export → Export project and assets… in Desktop does this for you and produces a self-contained folder. See Transferring a project to a different machine in the User Guide for the full handoff workflow.
• Match versions. The Runtime should be at least as new as the Desktop version that authored the project; older Runtime can't open projects that use newer features.
• Cross-platform paths. When deploying a Windows-authored project on a Linux Runtime, ensure no inputs / targets reference Windows-only components (Web Page (Chromium, Windows) is one example — use the cross-platform variant instead).