Media tier: Plex — optional, and the only proprietary service in the estate

[Gerrrt]

Sub-issue of #95. Filed because ADR-0008 names it; filed as optional because it is the one entry on the whole shortlist that fails this repository's usual tests.

What and why

Plex ⊘ Proprietary Unknown — and note the source: non-free.md:216, not README.md. awesome-selfhosted keeps a separate file for software that is not open source, and Plex is in it.

ADR-0008 places it "beside [Jellyfin] for household convenience", which is an honest reason. Client quality and the fact that people already know how to use it are worth something real, and a media server the household refuses to use has failed regardless of its licence.

What it costs, stated plainly

Every other service in this estate can be inspected, pinned, and reasoned about. Plex cannot, in three specific ways:

• It phones home by design. Authentication goes through plex.tv, so a service on a segment with no inbound path still has an outbound dependency on a third party, and the account holder's credentials are involved. This is the only service here where an outage somewhere else can stop a local device playing a local file.
• Digest pinning buys less. docs/security.md names supply-chain compromise of a container image as accepted and undefended; digest pinning is what narrows that. It still pins the bits, but nobody outside the vendor can read them.
• Features have moved behind a subscription before, including hardware transcoding. A dependency that can be repriced is a different kind of dependency.

None of that is disqualifying for a film library on a terminal VLAN whose data is explicitly replaceable. It is disqualifying for anything on the sensitive tier, which is why it appears nowhere near it.

Recommendation

Deploy Jellyfin (#138) first and run it for a few weeks. If nobody complains, close this as not planned and the estate keeps the property that everything in it is inspectable. If the household does complain, deploy Plex alongside and record here that the tradeoff was made knowingly — which is the same standard ADR-0008 applied to itself.

What it needs if it goes ahead

• A claim token and account credentials in secrets/*.sops.yaml.
• The same library mount as Jellyfin, read-only where possible.
• No inbound port forward. Remote Access stays off — there is no external exposure anywhere in this estate and this is not the place to start.

Which VLAN this touches

🟡 40 — CasaBonita (media)

Security review

• Does not weaken the default-deny posture between VLANs — no new rule beyond the 50→40 in Media tier: Jellyfin — placement answers the terminal-VLAN problem #138; but confirm Remote Access is disabled, since it exists to create an inbound path
• Any new credential goes in secrets/*.sops.yaml
• Any new device is added to docs/network.md with an OUI-truncated MAC — n/a

Depends on

#95 (the NAS), and preferably a trial of #138 first.

---

Note

Status, 2026-09-17. The host exists and the tier has a shape; the storage
does not.

smaug — the NAS, named by
ADR-0038
and running TrueNAS by
ADR-0040
— has held 10.0.40.30 since 2026-09-16, with four inbound passes created and
verified in position. The 50→40 rule this issue inherits from #138 is among
them, so no new firewall rule is needed here and none was ever going to be.

stacks/media/ is
authored and CI-validated, with Jellyfin alone in it. It is not deployed —
docs/runbooks/build-the-nas.md §6 deploys it, after the two Exos X20 drives
land and the pool erebor and its erebor/media dataset exist.

The storage decision §4 made applies here too: erebor/media is not backed up
and erebor/apps — where a service's database and config go — is.

Depends on #413, not #95, which
closed on 2026-09-04.

This one stays deferred, and the test it is deferred against still has not
been run: whether any screen on CasaBonita lacks a working Jellyfin client.
build-the-nas.md §8 lists it among what the build leaves open, and
stacks/media/README.md records the deferral. ADR-0016 builds Jellyfin alone
for that reason. Nothing here becomes actionable until #138 is deployed and a
household actually tries it — which is the point of the ordering, not an
accident of it.

---

Corrected 2026-09-19

The 2026-09-17 note says the storage does not exist. It does: erebor is ONLINE, Jellyfin is deployed on smaug (#522), the transcode passed (#524), and #138 closed today. So the deferral test is live rather than blocked: does any screen on CasaBonita lack a working Jellyfin client? stacks/media/README.md records that the LG OLED, the primary screen, has one. Named in build-the-nas.md and roadmap.md as "a test nobody has run" and tracked by neither until now — it is this issue's gate.

Moved to last: the trigger is a household observation, not work, and the first television has not yet played anything (#413 §7).