选择最符合合规、延迟和网络要求的环境。
自托管部署路径
在你可控的基础设施上保留同样的直播工作流。
在你自己的云账户、私有基础设施或专用服务器上使用 Callaba 作为受控的传输、播放、录制和监看层。把 SRT ingest、浏览器播放、多目标分发和存储集成保留在同一个工作流模型里，同时继续掌握环境的所有权。
适合关注固定成本规划、合规边界、自定义网络和可预测运营的团队，尤其是在工作流已经超出快速托管启动阶段之后。
基础设施控制把网络、存储与部署边界掌握在自己手里
在不依赖托管 runtime 的前提下，运行同样的 SRT、播放、restream 和录制工作流。
成本形态当使用量稳定后，更接近固定成本规划
按自己的计算、CDN 和存储提供商来设计，而不是把所有场景都当作纯按量付费。
运营匹配在云端与自托管之间保持同一控制面
运营团队保留同样的工作流模型，工程团队则获得更多环境控制。
“嵌入式 SRT 播放器很好，也能很好地控制谁可以观看。”
自托管真正改变的是什么运营优先控制
Callaba 保留工作流层，而基础设施层由你决定。
你不是从零重建视频产品，而是在决定同样的 ingest、监看、交付和归档工作流运行在哪里：自己的云账户、裸金属，或其他可控环境。
在所有权转向你团队的同时，完整保留运营层。
按成本形态、区域覆盖和保留策略去组合交付与存储。
偏向固定成本更适合合规云端或本地部署
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].