Self-hosted streaming server on Linux with Callaba 8.4

Written by Iurii Pakholkov

Founder of Callaba. Building cloud video tools for SRT, RTMP, WebRTC, NDI, live routing, monitoring, recording, and production workflows. May 26, 2026.

If you want a self-hosted or on-premises streaming server with full infrastructure control, this page is the right starting point. Callaba Self-Hosted on Linux is for teams that want to run ingest, routing, recording, playback-related workflows, and API-connected media operations inside their own environment instead of depending only on a fully managed cloud setup.

The practical trade-off is simple. Self-hosted gives you more control over routing, deployment timing, access boundaries, firewall rules, and infrastructure ownership. It also means your team owns the machine, updates, backups, monitoring, and planned change discipline. If you want pricing and broader product scope first, start with Callaba Self-Hosted pricing and overview. If you want the fastest evaluation path before committing to self-hosted infrastructure, use Callaba Cloud on AWS first and move to self-hosted when you need tighter control.

This guide keeps the install path straightforward: prepare the Linux host, use the latest 8.4 Multiview installation repository, choose the correct processing mode, open the dashboard, activate the license, and verify that the instance is ready for real streaming work.

What you will accomplish

By the end of this setup, you will have:

• a Linux server prepared for Callaba Self-Hosted
• Callaba 8.4 Multiview installed and activated
• browser access to the local dashboard
• a self-hosted base for SRT ingest, routing, monitoring, failover, video API, and on-demand workflows

What makes this a self-hosted streaming server

A normal streaming server often means one narrow job: receive a stream and send it somewhere else. Callaba Self-Hosted is wider than that. It is a live video control layer that can sit inside your own infrastructure and help your team operate the workflow around the stream.

What is new in Callaba 8.4 Multiview

Callaba 8.4 is useful when the deployment is not only about installing a server, but also about giving operators better control during live production. The key additions are browser-based SRT multiview and a failover switcher that can be used for main, backup, and fallback paths.

A multiview board lets operators watch several live SRT sources in the browser, arrange sources into a practical layout, and keep main, backup, and fallback feeds visible from one place.

The basic workflow looks like this:

This matters for on-premises and private cloud deployments because the monitoring and recovery logic can live close to your own infrastructure rules, instead of being split between local preview tools, manual checks, and separate routing systems.

When self-hosted or on-premises is the right choice

Linux self-hosted deployment usually makes sense when your team needs tighter control than a managed cloud environment gives you. That may mean internal infrastructure rules, data-boundary requirements, custom routing, specialized GPU or codec handling, private network access, or a broader product strategy where the media stack becomes part of your own application platform.

If the real requirement is simply to test the workflow quickly, a managed cloud launch is often the faster first move. If the requirement is ownership, control, and infrastructure-level flexibility, self-hosted is the right path.

How to get Callaba streaming server

1. Sign in to Callaba
2. Choose the self-hosted license that matches your deployment
3. Install and activate the software on your Linux server

After you sign in and choose the license, continue with the installation steps below.

If your team will run production ingest, distribution, or application workflows on top of the installation, the most relevant next pages are Multi-Streaming, Video API, and Video on Demand. For the 8.4 feature overview, also see Callaba 8.4 release notes.

Requirements

Minimum system requirements: 4 vCPUs, 4 GB RAM, 60 GB SSD

Recommended system requirements: 8 vCPUs, 8 GB RAM, 100 GB SSD or more if you plan to keep stream recordings, local media outputs, or heavier workflows on the same machine

Recommended OS: Ubuntu 22.04

Required packages: Git, Docker, and Docker Compose

Use the minimum profile only for light evaluation or narrow internal workflows. For production work, the recommended profile is the safer starting point because media routing, recordings, background jobs, and monitoring workflows make small machines feel constrained quickly.

Before you install

• Make sure you have shell access to the Linux machine.
• Confirm the server or local PC has internet access for package installation and license activation.
• Check CPU, memory, and disk before installation. Useful commands are lscpu, free -h, and df -h.
• Keep your Callaba account credentials and license key ready.
• Know the server IP or domain you will use later to open the dashboard in the browser.
• Allow browser access to the dashboard through standard web ports: 80 for HTTP and 443 if SSL is configured.
• Decide whether the installation should use CPU, NVIDIA GPU, or Xilinx acceleration.

Step 1. Download the Callaba 8.4 Multiview installation files

Open the terminal and clone the latest 8.4 Multiview installation repository. If git is not installed yet, install it first using your distribution package manager.

git clone https://gitlab.callabacloud.com/callaba-8/8.4-multiview.git

Move into the project directory:

cd 8.4-multiview

This replaces the older Callaba 7 Linux installation path. Use this repository when the deployment should be based on the 8.4 Multiview package.

How to move from old version to Callaba 8.4 Multiview

Download the new 8.4 upgrade scripts

From the server terminal, clone the new installation repository:

git clone https://gitlab.callabacloud.com/callaba-8/8.4-multiview.git

Then open the new folder:

cd 8.4-multiview

Use this folder for the version 8.4 update. Do not continue running update commands from the old callaba-7/linux directory when the goal is to move the server to the 8.4 Multiview package.

Run the update

Run the update script from the new 8.4 Multiview directory:

sudo bash update.sh 8.4-multiview

Keep the same hardware profile that the server is meant to use. If the instance was built around NVIDIA or Xilinx acceleration, validate that the hardware, drivers, and runtime path are still available after the update.

Validate the server after the upgrade

After the update finishes, open the Callaba dashboard and check the basic operating path before returning the server to production:

1. Confirm that the dashboard opens from the expected IP address or domain.
2. Confirm that the license is active.
3. Send one test SRT feed into the server.
4. Create or open a multiview board and confirm that the source is visible.
5. Test the failover switcher with a main and backup source.
6. Check recording, storage, and playback-related workflows if your installation uses them.
7. Check API-connected workflows or internal control panels if your team uses the Callaba API.

Clean migration option

For critical on-premises systems, a clean migration can be safer than an in-place upgrade. In that model, install Callaba 8.4 Multiview on a new Linux server, activate it, recreate or import the needed workflows, test ingest and failover, and move DNS, IP routing, or operators to the new server only after validation. This approach takes more time, but it reduces pressure on the existing production instance.

Step 2. Choose the right installation mode

Callaba 8.4 Multiview can be installed in different processing modes. Choose the mode that matches the hardware available on the server.

Option 1. Install with regular CPU processing

Use this option for a standard Linux server without a dedicated hardware acceleration profile:

sudo bash install.sh 8.4-multiview

Option 2. Install with NVIDIA GPU support

Use this option if the machine includes a supported NVIDIA GPU and your workflow should use NVIDIA acceleration:

sudo bash install.sh 8.4-multiview nvidia

Option 3. Install with Xilinx acceleration

Use this option if the machine includes Xilinx acceleration and the workflow is planned around that hardware path:

sudo bash install.sh 8.4-multiview xilinx

The right choice depends on the actual server and the workload. CPU is the simplest starting point. Hardware-assisted modes are better when the deployment depends on denser transcoding, higher efficiency, or a more demanding codec strategy.

Step 3. Launch the Callaba dashboard

After installation, wait a few minutes for the services to initialize. Then open the host IP address or domain of the machine in the browser. By default, browser access uses standard web ports: 80 for HTTP and 443 when SSL is configured.

The default access pattern is:

• Login: admin
• Password: password
• License: your license key

This default password is useful only for first access. Once the instance is working, change the password and treat credentials and access policy like production infrastructure, not like a one-time demo system.

Activate the license if needed

If the software is not activated with a valid key, the system will show a warning and will not work as expected. You can also activate it after first login.

Open the gear icon in the top panel:

Then open License settings and insert your key:

If activation problems appear, fix those before configuring ingest, multiview, failover, or playback workflows. A half-activated system is the wrong place to start operational testing.

Update an existing installation

To update the software later, run the update script from the same installation directory:

sudo bash update.sh 8.4-multiview

Use updates deliberately, not casually. In production environments, treat updates like planned change windows: know what instance you are changing, what workloads depend on it, and how you will validate the result after the update finishes.

Remove the installation

To remove Callaba Self-Hosted completely, run:

sudo bash remove.sh

This removes the application, data, files, and images stored by the installation. Do not run it on a system you still need for recordings, workflow state, or retained media.

Recommended first test after installation

Once the Linux instance is online and licensed, do not start with the full production chain. Start with a small controlled workflow:

1. Create or receive one SRT source.
2. Create a backup SRT source or prepare a fallback file.
3. Add the sources to a multiview board.
4. Create a failover switcher.
5. Test manual switching first.
6. Then test automatic failover behavior.
7. Send the final output to one destination.
8. Only after that, add more destinations and more operators.

This gives your team a clean validation path: first confirm that ingest works, then confirm that monitoring works, then confirm that the recovery path works.

What to do after the installation

The next practical step depends on what the deployment is meant to do:

• For ingest and distribution workflows, start with Multi-Streaming.
• For browser-based monitoring and source control, review Multiview and Callaba 8.4 Multiview release notes.
• For application-controlled playback, asset workflows, and integration logic, continue with Video API.
• For archive, playback, and media library workflows, review Video on Demand.
• If you need a simpler evaluation before investing more time in Linux operations, start with Callaba Cloud and compare the operational burden directly.

Self-hosted streaming server FAQ

Is Callaba Self-Hosted an on-premises streaming server?

Yes. You can run Callaba Self-Hosted on a Linux server that your team controls. That server can be in your own facility, a private cloud, a rented bare-metal server, or a cloud environment where you manage the machine yourself.

Can I use it only as an SRT server?

You can use it for SRT ingest and routing, but the platform is not limited to one protocol job. The stronger use case is the full operational path: ingest, monitor, switch, route, record, and automate.

Can I move from Callaba 7 to Callaba 8.4 Multiview?

Yes. If the existing server was installed from the older Callaba 7 Linux repository, use the new 8.4-multiview repository for the upgrade path. Make a backup first, run the update from the new directory, validate the dashboard, license, ingest, multiview, failover, storage, and API workflows, and validate the production path before returning the server to live work.

What should I check if license activation fails after changing the server IP or moving the installation?

First check that the server has internet access, the license key is copied correctly, and the dashboard is opened from the expected IP address or domain. If the instance was moved to another machine or the activation still fails, contact Callaba support so the license state can be checked before you continue production testing.

Do I need NVIDIA or Xilinx hardware?

No. CPU installation is the simplest path. NVIDIA or Xilinx acceleration is useful when the server hardware supports it and your workflow needs denser processing or a specific acceleration strategy.

Should I choose self-hosted or Callaba Cloud?

Choose Callaba Cloud when speed and easy evaluation matter most. Choose self-hosted when infrastructure ownership, private network access, deployment control, or internal compliance requirements matter more.

Can this setup be used for production live events?

Yes, but treat it like production infrastructure. Use a clean server, validate network access, test the license, confirm the dashboard, run a small ingest and failover test, and plan updates before the event.

Have questions? Send us a message at [email protected].