Skip to content

TautWeekly for Plex v0.14.1

Choose a tag to compare

@github-actions github-actions released this 17 Aug 23:45
· 25 commits to main since this release
c98c597

TautWeekly for Plex v0.14.1

v0.14.1 completes the GUI-first host experience introduced in v0.14.0. It
ships verified package-aware updates for NAS/QNAP Compose, macOS Docker Desktop,
native Linux, and FreeBSD Podman; adds the tailored authenticated Manager to the
Mac and FreeBSD packages; repairs older v0.14 host wrappers; and lets an
administrator permanently delete individual configuration backups from the
Manager.

Update existing installations

Back up private data first. On current NAS/QNAP Compose and macOS Docker Desktop
packages, run:

./tautweekly.sh update

On native Linux or FreeBSD Podman, run:

sudo tautweekly update

These commands now download the matching stable host archive and
SHA256SUMS.txt, validate its published checksum, reject unsafe archive
entries, verify the internal release-file manifest, preserve private data and
environment settings, update the host adapter and runtime together, and roll
both back when candidate health or version checks fail.

Unraid continues to update the image through Docker > Check for Updates or
Apps > Previous Apps. Administrators upgrading an older saved template
should apply the documented one-time template migration so the current Manager
environment, read-only hardening, stop timeout, and host-adapter compatibility
marker are present.

One-time v0.14 bridge

If an older NAS wrapper does not list manager-bootstrap, use the documented
direct container bootstrap command once, finish pairing in the Manager, then
apply v0.14.1. If an older FreeBSD wrapper omits that command, verify and extract
the current FreeBSD archive and run:

sudo ./install-freebsd.sh --upgrade-and-update

For an older native Linux archive, verify and extract v0.14.1, then run
sudo ./install-linux.sh --upgrade. The platform QuickStarts contain the exact
download, checksum, recovery, and post-update validation steps.

Mac and FreeBSD Manager packages

The macOS Docker Desktop and FreeBSD Podman packages now expose the shared
authenticated Manager with platform-specific setup, schedule, lifecycle,
paths, updates, recovery, and shutdown language. They do not inherit Windows
tray, sign-in startup, Scheduled Task, Start-menu, installer, or automatic
browser-launch behavior.

The Mac image is read-only, supports amd64 and arm64, and runs as the configured
numeric identity. FreeBSD uses a Podman/rc.d adapter. Both preserve the
independent newsletter schedule and allow up to the documented 30-minute host
grace period for an already-running delivery when the Manager listener stops.

Configuration backup deletion

In Recovery > Configuration backups, each regular private backup now has a
separate Delete action. Deletion requires an authenticated session, a valid
CSRF token, and an explicit confirmation naming the backup. It deletes only the
selected backup, does not change the live configuration, refuses symlinks and
invalid identifiers, and does not expose backup contents in diagnostics. The
action is permanent; download or copy any backup that must be retained first.

Validation and limitations

The release gates cover Manager unit, contract, security, and accessibility
tests; Windows, Linux, macOS, and FreeBSD Manager cross-builds for maintained
architectures; shell and PowerShell validation; synthetic updater success,
locking, private-data preservation, retired-file cleanup, staged rollback, and
corrupted-updater recovery; container heartbeat and liveness behavior;
Compose/Unraid contracts; packaged native Linux boot; reproducible ZIP/TAR
archives; and the isolated Windows installer lifecycle. The amd64 and arm64
container image is built and boot-tested without contacting real Plex,
Tautulli, SMTP, or user configuration.

Physical QNAP, Unraid, macOS, and FreeBSD host behavior, NAS-vendor reverse
proxies and storage ACLs, Community Applications moderation, and real mail
providers remain irreducible environment or submission checks. A native QPKG
remains separately scoped because Container Station already provides the
maintained QNAP deployment path and a QPKG would add signing and hardware/store
maintenance obligations.