Vindral Composer has supported cloud deployment for a long time. The headless Runtime runs on GPU instances at AWS, Azure, OCI, Akamai and other providers. Here is how a cloud deployment is put together, and what to check before moving a production off physical hardware.
The same engine, wherever it runs
Composer is a software-defined production engine. It handles chroma keying, compositing, audio mixing, graphics, switching and encoding in one application on standard GPU hardware. The Composer Runtime is the headless version: no graphical interface, controlled through an API, running the same project that was designed in Composer Desktop.
The Runtime runs on Windows and Linux. On Linux it runs in Docker and Kubernetes with NVIDIA GPU passthrough. The production itself is the same whether the Runtime sits in a rack or on a cloud instance, provided every input and target type the project uses is supported on Linux. What changes is who owns the hardware, how quickly it can be changed, and how you get your video sources into Composer.
How a cloud deployment is put together
Design the production in Composer Desktop on a workstation, as always. Scenes, keyers, audio routing, graphics and outputs are all defined in the project.
Deploy the Runtime on a GPU instance, as a container or directly on the host. Size the instance for the production. A single keyed table with a handful of branded outputs needs far less than a multi-camera show with several encodes.
Load and start the project through the Runtime API. The API loads, starts, stops and reloads projects, checks that every asset is in place before loading, and reports state and hardware capabilities. The project is read-only by default on the Runtime, so an operational mistake on the host cannot corrupt the master project.
Bring sources in over SRT, MoQ or RTMPS. Studio and remote encoders send SRT to the instance over the public internet, a Vindral Live channel comes in over MoQ, and an RTMPS source is pulled by Composer.
Send outputs where they need to go, over SRT, MoQ or RTMPS. Outputs can go to platforms and distribution partners, or directly to Vindral Live for sub-second delivery to players and viewers.
Monitor from one place. Composer exposes around 160 Prometheus metrics, and Composer Monitor, a ready-made Grafana, Loki and Prometheus stack on GitHub, collects metrics and logs from every instance into pre-built dashboards.
Everything in a running project, from scene switching to audio faders, is controlled over the HTTP API and WebSockets. An orchestration system can provision, configure, launch and monitor instances without anyone touching a machine.
Where the cloud fits
A studio that has run out of floor space, or has no team to look after hardware, can start the next table or channel on a cloud instance instead of buying a server.
Productions with a start and an end, such as a tournament, a pop-up channel or an event that runs for a few weeks, get an instance that exists for as long as the production does.
Peaks are handled by scaling: one instance on a quiet day, twenty during a major event, back down afterwards.
A standby instance can run in another zone, or with another provider, ready for your orchestration to switch to if the main instance fails.
A new Composer release, or a new version of a project, can run on a fresh instance next to production without touching the live system.
The studio connection stays small. The studio sends its contribution feeds up, and every branded output and platform version is generated in the cloud, close to the CDNs and platforms it goes to.
What to think about before moving
Image quality and bandwidth
On premise, cameras connect directly to Composer, which gives uncompressed SDI inputs. In the cloud, the video has to travel from the studio to the instance, and it is very unlikely to get there without some loss of quality. Run the video links at as high a bandwidth as possible, and use codecs that support 4:2:2 where you can.
Where the sources are
Put the instance in the region closest to the cameras, or to the viewers, depending on which latency matters more. Contribution over the public internet works well, but distance still costs milliseconds.
Which GPU the production needs
Composer itself puts no limit on the number of outputs. How many a single instance can produce depends on frame rate, resolution, number of cameras, which operators are in the chain, bitrate, GPU and CPU, and the answer varies a great deal between productions. Pick the instance for the actual production and change it when the production changes.
Cost model
Cloud capacity is an operating cost tied to each production. Hardware bought upfront depreciates whether or not it runs. For a production that runs around the clock all year, owned hardware may still be cheaper. For work with peaks, a fixed schedule or an uncertain lifetime, paying per production is usually easier to justify.
Operations
Decide who starts and stops instances, who watches the dashboards, and what happens when an instance fails. The Runtime API, the Prometheus metrics and Composer Monitor exist so that this can be automated or handled by a small team.
Coming in R3 2026
The next release adds several features aimed at fleets of unattended instances.
Composer CLI is a command-line tool bundled with the Runtime package. It talks to the Runtime API, so a deployment script can check status, load, stop and reload projects, validate assets and query health probes. Encoder addresses are saved as named contexts, so the same commands work against any instance in a fleet, and exit codes let a shell script branch on the result.
Health probes report startup, render loop and readiness state over unauthenticated endpoints, so Kubernetes or another orchestrator can tell a wedged instance from a busy one. API keys carry roles (viewer, operator, editor, admin) across the HTTP API, the Runtime API and WebSockets. The Runtime can be configured through environment variables, and inputs and targets report both requested and actual state, which separates a source nobody started from one that failed.
On the video side, the SRT target adds HEVC encoding via NVIDIA NVENC, and SRT synchronisation lets several genlocked cameras arriving over separate links join a sync group, so they play out frame-aligned on matching timecode.
Details are in the R3 2026 release highlights.
Get started
Read the Composer documentation for deployment details, or get in touch to discuss a cloud setup for your production.