Why Broadcast Software Isn't SaaS: a 20-Year Operator's Perspective

By the KAVANA engineering team — June 2026

Every few years the broadcast technology industry rediscovers the cloud. The pitch is consistent: move your broadcast automation to the cloud, eliminate on-premise hardware, pay per seat, scale elastically, let someone else manage the infrastructure. The pitch has gotten more polished with each cycle, and some of the technical objections from earlier cycles have been addressed. Better internet connectivity, lower latency CDN edges, more capable streaming infrastructure — these changes are real.

We have not built a cloud-native broadcast SaaS product. We have been in the broadcast software business for twenty years and have not moved in that direction. This post is an honest explanation of why, what the actual tradeoffs look like from our perspective, and where we think the "cloud broadcast" model does and does not make sense.

What "Cloud Broadcast" Actually Means in Practice

When broadcast technology vendors describe cloud-based automation, they are typically describing one of three things, and it matters which one.

The first is cloud-hosted software: broadcast automation software that runs on cloud virtual machines rather than on-premise hardware, but architecturally is otherwise the same software. The playout engine, scheduling system, and audio router run in a data center; the local facility has a thin client or a remote desktop connection. This is "cloud" in the infrastructure sense but not in the architectural sense.

The second is cloud-managed automation: the scheduling, scripting, and content management functions run in the cloud, while audio processing and transmission still happen on equipment at the facility. This is the model that companies like Telos Alliance and some of WideOrbit's newer products are pursuing. The cloud handles the "brain" functions; the local hardware handles the "muscle" functions.

The third is fully cloud-native broadcast: audio originates in the cloud, is processed in the cloud, and is delivered via IP to the transmitter. This is technically feasible for IP radio and streaming-only distribution, and several streaming-first stations operate this way. For terrestrial AM and FM broadcasting, it requires a reliable IP-to-transmitter connection that carries the full audio chain, which introduces a dependency that most terrestrial stations cannot accept.

These three models have very different risk profiles and very different implications for how a station operator should think about them.

The Core Problem: Network Connectivity Is in the Critical Path

The fundamental issue with cloud-dependent broadcast automation is that it puts the internet connection in the critical path of transmission. If the internet connection fails, broadcast fails.

This is a different failure mode than any traditional on-premise broadcast architecture. A playout machine can fail; the backup machine takes over. A storage array can fail; the redundant array takes over. These are local failures with local redundancy. An internet connectivity failure is a site-level failure that affects the entire dependency on cloud services simultaneously — and it cannot be mitigated by local redundancy, because the redundant local equipment has the same network dependency as the primary.

Broadcast stations in China have highly variable internet connectivity. City-center stations at provincial broadcasting groups in Beijing or Shanghai may have multiple independent fiber connections with high reliability. A county-level radio station in a mountainous region of Yunnan province may have a single 100 Mbps fiber connection or a 4G cellular backup. When we analyzed our customer base, approximately 35% reported at least one internet connectivity outage lasting more than 15 minutes in the past calendar year. For those stations, cloud-dependent broadcast automation means 35% of internet outage events are also potential broadcast outage events.

This is not a problem you can solve with SLA language in a cloud contract. The station's internet connection is not the cloud provider's responsibility, and the cloud provider's uptime guarantee does not extend to the local access link.

The stations we serve need to be able to broadcast through their internet connection failing. That requirement is incompatible with cloud-dependent broadcast automation as the primary architecture.

Data Sovereignty and Content Compliance in Chinese Broadcasting

Chinese broadcasting operates under content oversight requirements that are more demanding than those in most other markets. Broadcast content is subject to pre-air review requirements for certain categories; content involving certain topics or organizations has specific handling requirements; records of what was aired and when must be maintained for regulatory inspection.

These requirements create a data sovereignty question for cloud architectures: when broadcast content flows through cloud infrastructure, where does it go, who can access it, and how is access logged? For a cloud-hosted system running in a domestic Chinese cloud provider's infrastructure, this question may be answerable to the regulator's satisfaction. For a cloud system running on AWS, Azure, or Google Cloud infrastructure with global data centers, the answer is more complicated.

The regulatory preference — which we have encountered repeatedly in conversations with station managers who have had regulatory consultations — is for content to be processed and stored on infrastructure that is clearly within the station's or broadcasting group's control. On-premise infrastructure provides a clear answer to this question. Cloud infrastructure requires a more elaborate documentation chain.

This is not unique to Chinese broadcasting. European broadcasting organizations dealing with GDPR requirements for audience data, or North American broadcasters dealing with FCC content archiving requirements, face versions of the same question. The specific requirements differ, but the underlying tension between cloud architecture and content sovereignty requirements is common.

We have customers who have been explicitly advised by their regulatory contacts to maintain on-premise processing for certain content categories. This is not always publicly documented guidance — broadcast regulatory relationships in China often involve informal consultation — but it is a real factor in infrastructure decisions.

Single Points of Failure: the Topology That Cloud Architectures Create

Here is an architecture argument that does not depend on Chinese-specific regulatory considerations.

A broadcast station with on-premise automation has local failures and local redundancy. The failure modes are: this machine, or this disk, or this audio card, or this network switch. Each failure is isolated to a specific component that can be made redundant. A well-designed on-premise deployment has no single point of failure below the site level.

A broadcast station with cloud-dependent automation has an additional failure mode: the cloud service itself. Cloud services fail. AWS has multi-hour outages every few years. Azure has had significant incidents. The relevant characteristic is not the published SLA percentage but the frequency and duration distribution of actual outage events — which for any major cloud provider includes occasional events that are long enough to be significant for broadcast continuity.

More importantly, cloud service failures are correlated across customers. When a major cloud provider has an availability event, it affects all customers in the affected region simultaneously. A hardware failure at a single station is a problem for one station. A cloud availability event is a problem for every station using that cloud service, simultaneously, with the same outage window, with the cloud provider's engineering team handling all of them at once.

This correlation is the feature of cloud architectures that broadcast operators should care most about. On-premise architectures fail independently. Cloud architectures fail together.

The relevant comparison is not "on-premise vs. cloud for a single station." It is "what happens if the failure mode that affects my station can also affect every other station that shares my infrastructure provider, simultaneously?" For a broadcasting group operating fifteen county-level stations all using the same cloud automation platform, a cloud availability event is not a single-station incident. It is a network-wide incident.

We do not think this argument means broadcast stations should never use cloud services. We use cloud services extensively — AI synthesis APIs, remote monitoring, content distribution. The relevant question is which functions are acceptable to run in the cloud and which functions are not. Our position is that the core playout and transmission chain should not depend on cloud availability.

The Hybrid Model We Actually Built

The architecture we have settled on is local core with cloud-assisted periphery. The terminology is our own, but the concept is common in industrial systems that cannot tolerate core failures.

The local core consists of the playout engine, audio processing, schedule management, and failover infrastructure — everything that is in the direct path between content and transmitter. This runs on on-premise hardware at the station or at a local hub. It operates without any dependency on internet connectivity. KAVANA-DOG, our watchdog process, monitors the local core and executes failover within 800 milliseconds without touching any cloud service. The local core can run indefinitely without internet access.

The cloud-assisted periphery consists of: AI synthesis via cloud APIs when local GPU is not available or as a fallback pipeline; remote monitoring and alerting through our reverse SSH tunnel infrastructure; content distribution for shared programming that originates at headquarters; software updates and configuration management; and the administrative and analytics functions that do not need to be local. These cloud connections are desirable when available and gracefully degrade when unavailable. The station continues to broadcast if any or all of them are unreachable.

This architecture is less elegant than a pure cloud solution. It requires on-premise hardware at every station. It requires local maintenance capability or a service partner who can do local maintenance. It does not provide the elastic scaling and zero-capital-cost entry that cloud SaaS promises.

What it provides instead is broadcast continuity through internet failures, clear data sovereignty, failure isolation, and the ability for stations to operate in environments where internet connectivity cannot be assumed. For the stations we serve, those properties matter more than the properties that cloud SaaS provides.

How This Compares to NexGen Cloud and WideOrbit Cloud

We are sometimes asked directly how our approach compares to the cloud offerings from incumbent broadcast automation vendors. The honest answer is more nuanced than a simple comparison table.

NexGen's cloud architecture is primarily a cloud-hosted playout engine with the option for local audio processing hardware. The playout logic — what plays when, based on what schedule — runs in the cloud; the audio signal path can be handled locally. This is the "cloud-managed brain, local muscle" model. It reduces (but does not eliminate) the internet dependency for audio continuity, because the local hardware can fall back to a local schedule if cloud connectivity is lost, but the scheduling, logging, and management functions require cloud connectivity to function normally.

WideOrbit's cloud approach is similar in structure: cloud-hosted for administrative and scheduling functions, with local hardware options for the audio chain. WideOrbit has been more conservative about putting the audio chain itself in the cloud, for exactly the reasons discussed above.

Both of these approaches are more hybrid than the marketing sometimes suggests. Neither vendor has moved their core audio chain to a purely cloud-hosted model for terrestrial broadcasting, because the internet dependency problem is real and their existing customers know it.

Where NexGen and WideOrbit have advantages over our approach: larger installed base in North American and European markets, deeper integration with the content distribution ecosystems that major networks use, longer track record with the specific workflow patterns of Western commercial radio. Where our approach has advantages: the local-first architecture is more appropriate for the internet reliability profile of our customer base, our AI content production pipeline is more deeply integrated with the broadcast automation system, and our pricing is significantly more accessible for county-level and city-level stations that cannot afford NexGen or WideOrbit's subscription models.

The comparison that matters for a specific station is: what does your internet reliability look like, what are your data sovereignty requirements, and what is your content production workflow? Stations with high-reliability internet, no specific sovereignty requirements, and workflows that match the major vendors' assumptions may be well-served by those products. Stations with variable internet, specific sovereignty requirements, or content production workflows that involve high AI synthesis volumes are likely better served by an architecture like ours.

The Update and Remote Management Problem

One reasonable objection to local-first architecture is the update and maintenance problem. Cloud SaaS products can be updated centrally; every customer gets the new version without any local action. On-premise software requires coordination with each station's local team or with a service partner who has access to the equipment.

This is a real operational cost, and we have invested significantly in addressing it without moving the core execution to the cloud.

Our software update mechanism distributes updates through the same reverse SSH tunnel architecture that provides monitoring. When an update is available, the update package is pushed to the station's local machine through the tunnel; the KAVANA-DOG process handles the download, verification, and installation sequence without requiring human intervention at the station. The installation happens at a scheduled maintenance window — typically the station's overnight low-traffic period — and the system validates the update before committing to it. If the update fails validation, the previous version is restored automatically.

This update mechanism works even for stations that do not have on-site IT staff. The only requirement is that the station's internet connection be available periodically — not continuously — for the update package to transfer. A station that has internet access for four hours per day can still receive updates; it just may take longer for a large update to fully transfer.

The remote management capability — the ability to diagnose problems, adjust configuration, and execute remediation actions at a station without dispatching someone physically — is handled through the same tunnel infrastructure. A detailed account of how this works is at the KAVANA documentation site, and the open-source components of the tunnel architecture are published at github.com/kavanafm/kavana-docs-en.

The operational cost of maintaining local software across a network is real and we do not claim otherwise. What we can claim is that the mechanisms we have built reduce this cost substantially, and that the operational cost must be weighed against the reliability and sovereignty benefits that local-first architecture provides.

When Cloud-First Broadcast Makes Sense

We have spent most of this post explaining why we are not building a cloud-first broadcast SaaS. It is worth being direct about the cases where cloud-first does make sense.

Internet-only streaming stations that distribute solely over IP, with no terrestrial transmission obligations, have a different risk profile. The internet connection is in their critical path regardless of their automation architecture; there is no terrestrial fallback. For these stations, cloud-hosted automation does not introduce a dependency that does not already exist.

Stations that operate in markets with consistently reliable high-bandwidth internet connectivity — major metropolitan areas with multiple fiber providers and high-redundancy access infrastructure — face a lower risk from internet dependency. The argument for local-first architecture is partly about risk, and lower underlying internet risk reduces the argument's force.

Stations whose primary use case is content production and post-production rather than live transmission — production houses, podcast studios, content agencies that distribute through third parties — do not have the live transmission continuity requirement that drives the local-first argument. For them, cloud-based production tools may be entirely appropriate.

And new entrants — stations that are starting from scratch and evaluating their first automation platform — may find that cloud-hosted options have significantly lower entry cost because they eliminate the hardware capital requirement. If the station's internet reliability is good and their regulatory environment permits cloud data processing, the lower entry cost of cloud SaaS may be the right tradeoff for the early operational period.

We support cloud API pipelines for AI synthesis, and we expect to expand the cloud-assisted periphery in our architecture over time. What we are not going to do is move the transmission-critical core to a cloud dependency, for the reasons this post has tried to explain honestly.

The Honest Position

We are an on-premise broadcast software company with cloud-assisted capabilities. We will probably still be an on-premise broadcast software company in ten years, because the fundamental argument — that broadcast transmission continuity cannot depend on internet connectivity — is not going to stop being true for the majority of terrestrial stations operating in the environments we serve.

This is not a conservative or backward-looking position. It is a position about which architecture properties matter most for which use case. For the use case of reliable terrestrial broadcasting across a heterogeneous network of stations with variable internet reliability, on-premise core architecture is the right choice. For other use cases, the tradeoffs may fall differently.

If you are evaluating broadcast automation and want to understand more about how the architecture choices we have made translate to your specific situation, we are happy to have that conversation directly. The sales pitch version of this conversation is available everywhere; we try to offer the honest version instead.

Reach us at international@kavanafm.com. Technical documentation, including the architecture rationale for the decisions described in this post, is at github.com/kavanafm/kavana-docs-en. The KAVANA product overview covers the full system in non-technical terms for those making preliminary evaluations. The AI utilities documentation covers the cloud-assisted capabilities that sit on top of the on-premise core.

KAVANA is developed by Hunan ShengGuang Technology Co., Ltd. (湖南声广科技有限公司), incorporated 2012, team active since 2005. We hold a broadcast production and distribution license (湘字第00565号) and operate under Chinese cybersecurity Level 3 certification. Technical documentation and open specifications: github.com/kavanafm.

Originally published at https://www.kavanafm.com/blog/en/why-broadcast-software-isn-t-saas-a-20-year-operat.html

Draft assisted by Codex/DeepSeek, reviewed and edited by KAVANA engineering team.