Pick the environment that matches your compliance, latency, and networking requirements.
Self-hosted deployment path
Keep the same live workflow on infrastructure you control.
Use Callaba as the controlled transport, playback, recording, and monitoring layer on your own cloud account, private infrastructure, or dedicated servers. Keep SRT ingest, browser playback, multi-destination delivery, and storage integration in one operating model without giving up ownership of the environment.
Built for teams that care about fixed-cost planning, compliance boundaries, custom networking, and predictable operations once the workflow moves beyond a quick managed launch.
Infrastructure controlKeep networking, storage, and deployment boundaries in your hands
Run the same SRT, playback, restreaming, and recording workflow without depending on a managed runtime.
Economic shapeMove toward fixed-cost planning when usage becomes predictable
Choose your own compute, CDN, and storage providers instead of treating every workload as pure pay-as-you-go.
Operational fitUse one control surface across cloud and self-hosted deployments
Operators keep the same workflow model while engineering teams gain more control over the environment.
“Good embed SRT player and useful control over who can watch.”
What self-hosted changesOps-first control
Callaba keeps the workflow layer while you choose the infrastructure layer.
You are not rebuilding the video product from scratch. You are choosing where the same ingest, monitoring, delivery, and archive workflow runs: your own cloud account, bare metal, or another controlled environment.
Keep the operational layer intact while the ownership model shifts toward your team.
Choose delivery and storage providers based on cost shape, region coverage, and retention strategy.
Fixed-cost leaningCompliance-friendlyCloud or on-prem
Callaba Self-Hosted is a self-hosted streaming platform for teams that want the media stack inside their own infrastructure. The value is straightforward: you control where the system runs, how it connects, how it is secured, when it is upgraded, and how it is integrated into your product or broadcast workflow. The trade-off is just as clear: your team owns the Linux environment and the operational work around it.
That makes self-hosted the right choice for engineering-led teams, broadcasters, OTT operators, and systems integrators that need control over routing, storage, deployment timing, data boundaries, or customer-specific delivery models. If your priority is the fastest path to evaluation with less infrastructure work, start with Callaba Cloud on AWS. If infrastructure ownership matters now, self-hosted is the right place to evaluate.
Callaba Self-Hosted starts from $5/month, and the license can be shaped around functional units and modules instead of forcing you into one oversized package.
What this self-hosted solution is
Callaba Self-Hosted is self-hosted streaming server software that you install on your own Linux server or virtual infrastructure. It is not a fixed appliance and it is not a managed black box. You choose the host, network boundaries, storage model, and the functions your workflow needs.
In practical terms, that means you can place the streaming layer inside your own data center, private cloud, customer environment, or controlled hosting setup. You can align it with your own firewall rules, retention policies, observability stack, release windows, and internal services. For teams building a real media product rather than testing a single stream, that control is often the main reason to self-host.
When teams choose it
Teams usually choose self-hosted when streaming is becoming part of the product or operating model rather than a simple publishing utility. Broadcasters and OTT operators use it when routing, egress policy, asset retention, and uptime procedures need to stay inside their environment. Product teams choose it when the media layer must connect cleanly to their own APIs, identity systems, billing logic, or customer-specific provisioning. Systems integrators choose it when the deployment has to live in customer-owned infrastructure instead of a shared managed environment.
It is also a sensible choice when you expect the system shape to vary by project. One customer may only need ingest and delivery. Another may need recording, VOD, API control, or conferencing. A self-hosted platform that is assembled from modules is easier to adapt than a single fixed package.
What you can assemble with it
Callaba Self-Hosted can be assembled around the workflows you actually need to run. A deployment may start with Multi-Streaming for ingest, routing, protocol conversion, and delivery to multiple destinations. If your application needs to create and control workflows programmatically, add Video API and review the Callaba Engine documentation to validate the control surface early.
For retained assets and playback workflows, add Video on Demand. For always-on channels and scheduled output, use Continuous Streaming. If your product includes real-time sessions, add Video Conferencing. If you run paid live events, Pay-Per-View Streaming can be added without moving to a different platform.
The key point for buyers is that this is not one narrow SKU. You can license a smaller deployment for one job, then expand as the workflow grows. That is especially useful when the roadmap is still evolving or when different business units need different media capabilities.
How deployment works
A good self-hosted evaluation starts with the workflow, not with the server. Define what must be ingested, what must be transcoded or transformed, what outputs are required, what needs to be recorded, what APIs or backend systems need to control the platform, and what security boundaries must be respected. That gives you a practical deployment design instead of a generic platform discussion.
- Choose the modules and functional units that match the workflow you need to run.
- Provision the Linux host or hosts with the network, storage, and access model you expect in production.
- Install and activate the software, then validate with real streams, expected concurrency, and your actual monitoring and backup approach.
For technical evaluators, the best comparison is to use the same ingest formats, destinations, codecs, and traffic assumptions in both cloud and self-hosted tests. That exposes the real trade-off between operational simplicity and infrastructure control before you commit.
Installation paths
The main Linux deployment path is the self-hosted solution installation guide. Use it when you want the standard path for bringing Callaba up on your own server and validating the core system.
If your deployment depends on newer packaging or on specific media features such as HDR, HEVC, AV1, VP9, or conferencing workflows, use the Callaba 8.2 installation guide for encoding profiles and video conferencing. That path is the right one when codec support and version-specific capabilities are part of the buying decision, not an afterthought.
If your application will control workflows directly, review the API documentation alongside the install guide. That lets engineering teams evaluate deployment and integration effort together instead of treating them as separate decisions.
How pricing works
Pricing starts from $5/month. The license can be shaped around functional units and modules, which makes the pricing model easier to understand than a large fixed bundle. In plain terms, you pay for the capabilities your workflow needs rather than buying every feature up front.
That matters because not every deployment has the same job. A simple routing and delivery node should not be priced like a full OTT stack with API control, VOD, conferencing, and monetization features. As the number of units increases, the price per unit decreases, so larger deployments benefit from volume-based pricing.
The practical way to scope price is to map the workflow first: ingest, processing, delivery, storage, playback, API control, and any special modules. That produces a clearer cost model than trying to estimate from a generic platform label.
Self-hosted vs cloud
The decision is mostly about control versus operational load. Self-hosted gives you more control over infrastructure, security boundaries, storage, upgrade timing, and deep integration. Cloud gives you a faster starting point with less operational ownership. Neither is universally better; the right option depends on whether your team values speed or infrastructure control more at this stage.
| Decision factor | Self-hosted | Cloud first |
|---|---|---|
| Launch speed | Slower to start because you provision and operate the environment. | Faster to evaluate because infrastructure is already managed. |
| Infrastructure control | High control over network boundaries, storage, release timing, and integration. | Less infrastructure control, but less setup work. |
| Operational burden | Your team owns updates, monitoring, backups, scaling, and incident response. | Lower operational responsibility during evaluation and early rollout. |
| Best fit | Long-term platform ownership, customer-specific deployments, stricter security or compliance boundaries. | Proof of concept, early product validation, smaller ops footprint, faster experimentation. |
If you are unsure, the practical path is often sequential: validate the workflow in Callaba Cloud on AWS, then move to self-hosted once the product shape is clear and infrastructure ownership becomes the bigger requirement.
What your team must own operationally
In self-hosted mode, your team owns the Linux hosts, package lifecycle, network and firewall policy, TLS and secrets handling, storage layout, backup strategy, observability, alerting, rollback discipline, capacity planning, and incident response. You also need a plan for how updates are tested and introduced without disrupting live traffic.
This is not a drawback hidden in small print. It is the operating model. For teams that already run production infrastructure, it is normal and often preferable. For teams without Linux operations or on-call capacity, cloud is usually the better place to start.
Practical next steps
If you are ready to deploy on your own infrastructure, start with the Linux self-hosted installation guide. If advanced codecs or conferencing are part of the requirement, go directly to the 8.2 installation path.
Then review the modules that match your actual use case: Multi-Streaming, Video API, Video on Demand, Continuous Streaming, Video Conferencing, and Pay-Per-View Streaming. If you still need to compare operating models before committing to Linux ownership, use Callaba Cloud on AWS as the faster evaluation baseline.
If you need help mapping modules to a deployment or estimating the right functional-unit mix, contact [email protected].