Bobi.StudioFR

Deployment

Free software, installed in three commands.

Bobi.Studio is published under the GNU GPL v3. The repository holds the orchestrator, the node agent, the container plugins and the documentation. You can run it, study it, change it and redistribute it.

GitHub repository (opens in a new tab)
01

Licence

GNU General Public License version 3 or later.

Copyright © 2026 BOBI SAS, France. Author: Cyril Mazouer, on behalf of BOBI SAS.

This program is distributed in the hope that it will be useful, but without any warranty, without even the implied warranty of merchantability or fitness for a particular purpose. The full licence text ships with the source.

Bobi.Studio bundles third-party components (the MXL bus, Intel Media Transport Library, DPDK, FFmpeg, MediaMTX and others) which remain under their own licences. The full inventory and the notices to keep are in the repository.

Read the GPL v3 (opens in a new tab)Third-party components (opens in a new tab)
02

Install the controller

One command, one menu, and the machine knows what to become.

On a fresh machine, a single command fetches the installer and opens the menu. It needs neither git nor a package built beforehand: curl and tar are enough.

# on the machine to install, as root
bash <(curl -fsSL https://bobi.studio/get.sh)

The script asks which version to install, fetches the source from GitHub, checks that it is complete, then hands over to the installer.

BOBI.STUDIOInstaller

What do you want to install on this machine?

  1. Process nodeAgent only — runs the video workloads (compute, 2110, media…).
  2. OrchestratorWeb control interface (port 5000) that drives the fleet.
  3. All-in-oneOrchestrator + process node on the same machine.
  4. Orchestrator on a Proxmox VMDeployment via the Proxmox hypervisor (advanced, legacy).
  5. UninstallRemove Bobi.Studio from THIS machine (node and/or orchestrator).

↑/↓ move · Enter select · ← back

The fourth entry is for hosting the orchestrator on a Proxmox hypervisor: run from the Proxmox node, the installer creates the container itself, sets up its network, deploys the code, installs the dependencies and enables the service. Nothing has to be prepared by hand.

On a site already equipped, the same result is reached without going out to the internet: a controller in service hands out its own installer.

bash <(curl -fsSL http://<controller>:5000/install.sh)

And with neither outbound network nor controller, the package builds from source. The build needs nothing but Python — no virtual environment, no dependency.

git clone --recurse-submodules https://github.com/bob-integration/bobistudio /opt/bobistudio
cd /opt/bobistudio
python3 tools/build_dist.py --all
cd dist && sudo python3 install.py

The service is then managed like any system service, with its logs.

systemctl {start|stop|restart|status} bobistudio
journalctl -u bobistudio -f
03

Enrol a node

The same command, a different entry in the menu.

A node is installed with the command from the previous step: pick Process node, tick its capabilities with the space bar, then give the controller address and an enrolment token. The node announces itself and shows up in the interface.

  • compute — numpy workloads: mixer, multiview, UDC, corrector.
  • io2110 — ST 2110 inputs and outputs, on an E810 NIC.
  • media — playback, recording, transcoding, stills.
  • webrtc — WebRTC gateway.

The 2110 NIC is detected at enrolment. For an automated rollout, the node script can also be called directly, with no menu.

./node_agent/install-node.sh --with compute,media \
    --macvlan-parent eno1 \
    --macvlan-subnet 10.0.0.0/24 \
    --macvlan-gateway 10.0.0.254

Everything else is set from the interface: ST 2110 network, multicast allocation, NMOS, TSL, WebRTC, PTP, themes, users and permissions. No site-specific value lives in versioned code.

04

Without a USB stick

A machine room is not always within reach.

A fresh node can be installed by UEFI HTTP network boot, served by the controller itself, or by virtual media from the machine’s management controller. The node finishes its installation and presents itself to the controller with its token.

05

Documentation

Versioned with the code, and rendered in the product’s own help pages.

  1. Infrastructure (opens in a new tab)

    Read before buying: CPU, memory and bandwidth, network cards, GPU, RDMA, PTP, the three network planes, redundancy.

  2. Installation (opens in a new tab)

    From a bare machine to the first flow, with the details that make a commissioning fail.

  3. Node agent (opens in a new tab)

    The HTTP contract between the controller and the agent running on each node.

  4. High availability (opens in a new tab)

    Controller pair, replication, promotion, management address.

  5. Changelog (opens in a new tab)

    What changes, why, and what it fixes. Also rendered in the interface’s help page.

06

Contributing

The repository is open to fixes as well as to new container types.

A container type is a self-contained plugin: a manifest, a script and an optional interface. It declares what it produces, what it consumes, its control endpoints and its drivable parameters.

A plugin’s Python only runs inside its container: the controller renders it and checks its syntax without ever running it in its own process. Its interface, on the other hand, is served by the controller and runs in the operator’s browser, under their session. A plugin is therefore not a sandbox: it is installed with the same trust as any dependency.

A fully commented example plugin serves as a starting point. Bug reports, feature requests and code proposals all go through the repository.

Open the repository (opens in a new tab)

A question before you start?

Sizing, integration into an existing plant, help with commissioning: get in touch.

Contact us