Service catalogue

Status: Accepted · Audience: Operator · Area: F — Extensibility

---

Purpose

Say what each service is for, in terms of what it does for the operator rather than what it is.

A stack of twenty-three bundled services is opaque. “Prowlarr” and “Bazarr” convey nothing; the operator sees a list of names, cannot tell which matter, and cannot judge whether a failure is serious. When something breaks they don’t know whether they’ve lost subtitles or lost everything.

The catalogue is also the criteria by which anything new is judged. Nineteen services is already a lot, and every addition costs memory, attack surface, update burden, and cognitive load.

Behaviour

Every service is described by its job

The “without it” column is what makes this useful: it converts an inventory into a judgement about severity.

Criticality is stated

Gluetun is alone at critical, and for the reason stated throughout: it is the only service whose failure can affect the operator outside their own machine.

Provenance is visible

Each service’s licence, upstream project, and pinned version — so the operator can verify the open-source claim rather than take it on faith.

Every bundled service lemonfiber does not build is OSI-licensed: GPL-3.0 (Prowlarr, Sonarr, Radarr, Lidarr, Bazarr, Calibre-Web-Automated, Homepage), GPL-2.0 (Jellyfin, SABnzbd, qBittorrent), MIT (Seerr, Gluetun, FlareSolverr, Recyclarr, Unpackerr, Bindery, Audiobookshelf), Apache-2.0 (NZBHydra2, Caddy).

The services whose images lemonfiber builds from its own code — the request gate and the decline service (ADR-0033) — carry lemonfiber’s own licence, Hippocratic-3.0, as the rest of its code does (licence rationale). Their source is public, so their licence is verified the same way, and it is source-available rather than open source.

Inclusion criteria are explicit

A service enters the stack only if it is open source under an OSI-approved licence — or, where lemonfiber builds its image from its own code, carries lemonfiber’s own licence (F2-R5) — publishes native linux/arm64 and linux/amd64 images, is actively maintained, does something no included service already does, and works without a paid tier.

Stating the criteria makes “why isn’t X included?” answerable, and makes additions a judgement against a standard rather than a matter of taste.

Maintenance signals are tracked, not discovered late

Each bundled service has the date of its last upstream release recorded in the bundle’s last_release, beside its pin, by the reviewers who move the pin, and refreshed whenever they move it. A service going quiet is not itself a problem — a mature application may simply not need frequent releases — but it is a signal worth holding, because the alternative is discovering an abandoned dependency only when it breaks.

The recorded date is the latest release upstream has published, not the date the pinned version shipped. Those diverge precisely when the signal matters: a project that released six times since your pin is alive, and one that has released nothing since is the case worth noticing. A date ahead of upstream’s actual latest release is not a stale record but a wrong one, and fails validation.

The table below carries only services whose signal needs a judgement recorded against it; the dates themselves are bundle data, so they version with the stack rather than with this document.

Notable exclusions are recorded

Edge cases

Acceptance criteria

Related

• B1 Forms — how services group into profiles
• F1 Customisation — adding services
• G2 Plain-language layer — how descriptions are written
• 90-appendix licence rationale