Requirements

Reference appliance

Castmux is developed and measured against a deliberately modest machine, because that is what fits in a comms cupboard and runs unattended for years:

Component	Reference specification
CPU	4 cores, arm64 or x86-64
Memory	2 GB
Cooling	Fanless
Storage	Any; there is no disk activity in normal operation beyond logging
Network	One interface minimum, two preferred

Nothing is transcoded, so there is no GPU requirement and no benefit from one. The absence of sustained disk writes is worth noting for anyone specifying hardware: an appliance running on industrial flash is not being worn out by this workload.

Per-channel cost

The two engines have materially different costs, and which one you choose changes the capacity of the box by a factor of roughly 1.5. Measured per channel:

Measurement	Remux engine	Pass-through engine
Cold start (join → first packet)	~4.4 s	~1.9 s
Full 1316-byte datagrams	85%	100%
CPU per channel	~5% of a core	~15% of a core
RAM per channel	~72 MB	~23 MB
Channels on a 2 GB box	~16	25+

The costs run in opposite directions, which is the reason both engines exist. The pass-through engine is cheap on memory and expensive on CPU; the remux engine is the reverse. On the reference appliance this means the remux engine runs out of memory first and the pass-through engine runs out of CPU first — four cores at 15% each is a little over 26 channels, which is where the “25+” figure comes from.

The remux engine cannot be retired, despite costing more per channel. The pass-through engine cannot null-pad to constant bitrate, and its HLS input reads MPEG-TS segments only, not fMP4/CMAF — so a modern CMAF origin, or a downstream device that insists on CBR, needs the remux engine. See Streaming engines for how to choose.

Capacity planning

Memory is a cliff, not a slope. This is the single most important thing on this page. CPU exhaustion degrades gracefully — streams stutter, you notice, you reduce the load. Memory exhaustion does not degrade at all: the kernel picks a process and kills it, and the process it picks is usually a healthy channel that had nothing to do with the problem. There is no warning band between “fine” and “a channel just vanished”.

Do not test capacity by ramping until it breaks

Twenty remux-engine channels OOM-killed a 2 GB box during testing. Nothing warned first; the box was carrying nineteen channels apparently comfortably, and the twentieth took one of them off air. Ramping until failure does not find the limit, it finds a number one channel past the limit, and it does so by taking a working system down.

Measure the per-channel resident set size on your own sources, do the arithmetic below, and stop there.

The arithmetic

Three steps:

1. Usable memory = total memory − ~300 MB. That reserve covers the operating system, the container runtime and the Castmux process itself, none of which are per-channel costs.
2. Raw channel count = usable memory ÷ per-channel RSS for the engine you have chosen.
3. Leave 15% headroom. Per-channel RSS varies with source bitrate and moves during origin hiccups and reconnects; the last 15% is what absorbs that.

Worked, for a 2 GB appliance running the remux engine:

# usable memory
2048 MB - 300 MB = 1748 MB

# raw count at ~72 MB per channel
1748 / 72 = 24 channels

# minus 15% headroom
24 x 0.85 = 20 channels

Twenty is where the arithmetic lands, and twenty is the number that OOM-killed a real box. The measured safe figure is ~16. When arithmetic and measurement disagree, believe the measurement: the per-channel RSS in the table is a steady-state average, and channels do not all sit at their average simultaneously.

Treat the arithmetic as a way of ruling out obviously infeasible plans, not as permission to run right up to the result.

CPU headroom

On the pass-through engine, do the same division against cores rather than memory: four cores is 400 percentage-points of CPU, at roughly 15 per channel. Leave the same 15% headroom, and leave more if the box is also driving a DVB-C modulator or serving previews to several browsers at once.

Networking

Interfaces

Castmux will run on a single network interface, and for a small installation that is a perfectly reasonable choice. Two interfaces — one for management, one facing the televisions — is preferred, for a diagnostic reason rather than a throughput one.

With management and multicast sharing one link, every fault becomes ambiguous. A saturated uplink makes the web interface unresponsive, so the tool you would use to diagnose the problem is the tool the problem has broken. Separating them means the management interface stays answerable while you work out what is wrong with the other one, and it means the traffic figures in the footer are attributable: one interface should show a steady multicast rate, the other almost nothing.

Layer 2 and routing

The televisions must be on the same layer 2 segment as the appliance. Multicast does not cross a router by default; getting it to do so requires PIM on the intervening routers and IGMP snooping configured consistently across the path, which is a network engineering exercise outside the scope of this product.

On the appliance itself, 224.0.0.0/4 must point at the interface facing the televisions. This is covered in detail in Installation → multicast routing, and it is worth reading before you order hardware, because it is the requirement people discover last.

Uplink and the startup stagger

The uplink carrying the source streams needs to sustain the sum of all channel bitrates, with margin. The margin matters more than the average, because of what happens at start-up.

When Castmux starts, every always-on channel wants to begin at once. Each one opens a connection to its origin and pulls segments as fast as the origin will serve them, in order to fill its buffer. Eight channels doing that simultaneously on a 100 Mbit uplink do not each get one eighth of the link and start slowly — they all time out, all fail, and all retry, which produces the same burst again.

Castmux therefore staggers channel starts, with a default gap of 3 seconds between them. The cost is that a full restart of twenty channels takes about a minute to complete. The benefit is that it completes at all. Do not reduce the gap to make restarts look faster; on a constrained uplink that is exactly the change that reintroduces the failure.

DVB-C hardware

Required only if you want RF output onto the coaxial network. Two things are needed:

• A free PCIe slot, which rules out most compact fanless boxes and is the usual reason a DVB-C installation needs a different chassis from an IP-only one.
• A supported TBS modulator card.

For an IP-only installation none of this applies. See DVB-C multiplexing for supported cards and configuration.

Software

A Linux host with a container runtime. Castmux ships as castmux/castmux:latest and is a single Go process inside the image.

The image is built on Debian trixie. This is not arbitrary: the engines need recent FFmpeg and TSDuck, and older Debian releases cap both at versions with known limitations. Alpine is not an option — no TSDuck package exists for musl, so the pass-through engine simply cannot be built there. If you are used to Alpine-sized images, expect this one to be larger, and that is the reason.

The host distribution does not matter, only that it can run the container with host networking and the two capabilities described in Installation.

Internet access

No outbound internet access is required to stream. If the sources are on the local network or a private circuit, the appliance can sit on a segment with no route to the internet at all and operate indefinitely. There is no licence check, no telemetry and no phone-home.

Internet access is used for exactly two things:

• Reaching internet-hosted sources, if that is where your sources are. This is a property of your channels, not of the product.
• Pulling a new container image when you choose to upgrade. This is manual and nothing initiates it automatically. An appliance that never sees the internet never upgrades and never asks to.

One caveat on DNS

If your sources are addressed by hostname, name resolution must work and must be fast. An origin that publishes an IPv6 address on a network with no IPv6 route causes every fetch to attempt IPv6 first and fall back, which is slow at best and multi-second at worst. Where the appliance has no IPv6 connectivity, configure the host to prefer IPv4; Troubleshooting covers the symptoms, which look convincingly like a slow origin.