Products, and what each one includes

Effective from Kylone Headend v4.2.0, autumn 2026. Licence keys issued before that keep the contents they were issued with; nothing on this page changes a running unit.

---

1. The products

Four Digital Headend products form a ladder, each one containing the one before it. The Hospitality Headend and the Carrier Monitor stand beside the ladder, built for one kind of customer each.

• Digital Headend Gateway. DVB in, IP out. Satellite, terrestrial and cable tuner cards on one side, multicast and unicast UDP, SRT, HTTP and HLS on the other, live TV and radio with a programme guide. The entry product of the line, with the full web UI, the XML API and the monitoring of every other product.
• Digital Headend Advanced. Every source and every output. IP contribution over multicast, SRT, HTTP, HLS and RTSP, files, HDMI and SDI capture; multiplexing and DVB-C/T modulation on the output side; the Modules page, white-label branding.
• Digital Headend Studio. Advanced plus processing: transcoding on the GPU, assistive captions, adaptive HLS renditions, extra output containers and CDN push. Studio is where content gets processed.
• Digital Headend Broadcast. Studio plus control of the signal: scheduled stand-ins for blackout windows, language substitution by grafting an audio track, SCTE-35 cues for insertion, and a video wall to watch it all. Broadcast names the customer and the obligations on the signal; those customers budget for exactly that, and nobody else misses it.
• Hospitality Headend. Studio for a property, plus the client side: set-top box and TV client lines, PMS integration, guest hotspot, the CPE SDK and premises customisation. One unit per property; see the Hospitality Headend page and the integration guide.
• Carrier Monitor. Narrow on purpose: DVB reception, spectrum acquisition and blind scan, run-to-run comparison, monitoring and the API, the Modules page. No live channels, no outputs, no programme guide, so nobody should read it as a cheap Gateway. See the Carrier Monitor page.

Source failover is in every product. The automatic stand-ins, a backup source for one channel or one source guarding many, are a reliability promise, not a feature to sell separately.

2. What each product includes

The same table a licence key encodes, in plain words, on three axes: sources, processing, outputs. The rows below those are the platform every product shares.

✓ included in the licence · ✓¹ included, delivered as a Kylone module: install it from the Modules page when you want it, nothing to buy · hardware: a real hardware requirement, stated on the product page · – not part of the product.

Moving up the ladder, or switching to another product, is a new key at any time, applied in the web UI without a reinstall. Nothing is unlocked piecemeal: the sets above are the only sets there are. Modules are part of that: a function marked ¹ arrives as a Kylone module, installed from the Modules page when the operator wants it, and the licence of the product enables it. Whether to install one is the customer's choice, never a purchase.

3. The facts

4. Why an ISO install, not an application on any OS

A Kylone unit is installed from an ISO image onto a server, as an appliance, rather than as a package on an operating system you maintain. People ask why. The reasons are practical.

• The host is managed from the product. Firewall, SSH keys, security updates, SNMP, NTP, folder sharing: each has a page in the web UI and a function in the API, and the firewall knows which openings the licence, the enabled services and the configured sources need, and lists what is missing.
• Why the host services are in the product at all: fleets. Everything the web UI does, the API does across a fleet: a firewall rule, an SSH key, a static route, an HTTPS certificate, a security update or a configuration change applied on fifty units is one script, or one unit at a time from the web UI if you prefer, with the same result either way. The same holds for software: once a release has been tested on one unit, the fleet is upgraded remotely with a single command. Ten years of operators' fleets have run on exactly that.
• Your policies still apply. The operating system is the distribution's own minimal install with a pre-hardened configuration, socket buffers and limits among it, and nothing proprietary in it. SSH with your own keys gives full access to it, static routes are set on the web UI, and a corporate IT department applies its network profiles and guidelines as on any Rocky Linux or Red Hat server; the firewall page lists what the product needs open so the policy and the product do not fight.
• No host state is copied into the product. The firewall configuration, the authorised SSH keys and the SSH daemon's settings are read live from the system, which stays the single source. The portal keeps no copy and stores no secret of the host.
• A pinned, tested kernel. The tuner, modulator and GPU drivers are built against the kernel each release ships with, and an unattended kernel change would take a unit off air. So the kernel moves only with a service pack, every three to six months, together with the driver set and the kernel-dependent modules, after testing. The pin is a default, not a lock: you may take kernel updates yourself, and then keeping the DVB drivers and the kernel-dependent modules in step with the kernel is your responsibility, as with any product in the market.
• Updates in one click, security updates on their own. The System Settings page installs every pending update from the distribution repositories, kernel excluded. A separate switch installs security updates automatically once a day, security only, never a reboot, an email on every applied update. It is off by default, because an unattended update has broken a unit before; the trade-off is yours and it is stated.
• No dependency drift. Every unit of a release runs the same libraries, the same codecs, the same web server configuration. A problem seen on one unit is reproducible on another, which is what makes support fast.
• A known state to return to. A reinstall from the ISO followed by a configuration import returns a unit to exactly what it was, including its licence, which re-activates automatically with central access or by entering the key once more without it.
• Remote access as a closed network of your own. Because the unit is an appliance, Kylone can give each customer a private network on its remote access infrastructure that holds that customer's units and nothing else: reach them from anywhere, at no fee and with no subscription. A Kylone engineer joins only when you ask for support, the switch on each unit stops the service, and the headend runs exactly the same with it off.
• A security baseline that ships. No default password: the installer generates the administrator password for each unit and shows it once, a firmware image uses the address printed on the unit's label, and the web UI insists on a password of your own at the first login. The firewall on from the first boot with only the web UI and SSH open, password login to SSH replaced by keys at your choice, HTTPS with your certificate, two-factor authentication for the web UI. No hidden accounts and no shell on the console: recovery is one documented entry in the boot menu, reachable only from the physical console, offering a new admin password shown once, a temporary DHCP address or the installer's firewall openings, every use logged and sent as a notification, and switchable off for sites whose policy prefers a reinstall.

Where a compliance rule requires the operating system to be installed and maintained by the customer, Kylone also installs onto an existing minimal Rocky Linux or Red Hat Enterprise Linux instead of from the ISO, with the same host management afterwards; the installer package comes from Kylone on request. Operation needs no internet; maintenance needs the distribution repositories, through a public mirror or the mirror an isolated network runs anyway. On an isolated unit the update page says "repositories unreachable" rather than hiding the fact.

5. Managed as a fleet

The host services are in the product for one reason: an operator runs units, not a unit. Everything the web UI does, the XML API does as well, and what it does on one unit it does on fifty from one script: a firewall rule, an SSH key, a static route, an HTTPS certificate, a security update, a channel line-up, a configuration change. The web UI stays for the operator who prefers one unit at a time; the result is the same either way, because both go through the same code.

Software follows the same path. A release is tested on one unit, then the fleet is upgraded remotely with a single command, unit by unit or all at once, each unit reporting the result. Ten years of operators' fleets have run on exactly that, which is why the host is managed from the product rather than beside it.

The API and its reference clients are published on GitHub; monitoring of the whole fleet goes through SNMP and Prometheus, described on the Monitoring page.

6. Questions people ask

---

Terminology on this page follows the web UI of Kylone Headend v4.2.0. Product names used by the hardware partner for its bundles differ and are not listed here.