TautWeekly for Plex v0.15.0
TautWeekly for Plex v0.15.0
v0.15.0 makes Manager Settings > Updates the truthful update-status source
for every supported package. It separately identifies the running Manager and
application, host package, container image, and host-adapter contract; compares
them with the latest verified stable release only on request; and gives each
platform its exact safe next step without transferring host privileges to the
web process.
Update existing installations
Back up private data, sign in to the Manager, and open Settings > Updates.
Choose Check now to perform one bounded stable-release check, review the
reported application/package/image state and release notes, then follow the
owner named by the card:
| Package | Update owner and action |
|---|---|
| Windows Manager | Confirm Install update after a fresh successful check. The Manager starts the existing verified updater; Windows still requests administrator approval. |
| Native Linux | Run sudo tautweekly update on the host. |
| macOS Docker Desktop | Run ./tautweekly.sh update from the extracted Mac package. |
| FreeBSD Podman | Run sudo tautweekly update on the FreeBSD host. |
| NAS / Docker Compose | Run ./tautweekly.sh update from the extracted NAS package. |
| QNAP Container Station | Run ./tautweekly.sh update over trusted SSH, confirm the recreated application in Container Station, then return to Settings. |
| Unraid Community Apps | Use Docker > Check for Updates or the Apps flow and compare the saved template when Settings reports a legacy host adapter. |
| Other compatible Compose hosts | Run docker compose pull tautweekly, then docker compose up -d --no-build --force-recreate tautweekly from the original stack. |
Return to Settings > Updates after installation to confirm that the
application, package/image, and host-adapter layers agree. Then run the normal
Manager verification, PreviewAll, and controlled TestEmail acceptance flow.
Routine TautWeekly updates do not require a Plex or Tautulli full-library
metadata refresh when current output is already correct.
Truthful status and failure handling
The card reports the stable channel, latest stable version, last successful
check, last sanitized failure, release notes, and one of the following states:
- Current when the reported application and package layers match stable.
- Update available when stable is newer.
- Legacy wrapper when a maintained container package reports an older or
missing host-adapter contract. - Version mismatch when the running application/image and host package do
not agree. - Newer than stable without offering a rollback or downgrade.
- Unknown when no verified comparison is available, the package cannot
identify a version, or the configured channel is unsupported.
Normal Manager refresh, dashboard health, scheduling, newsletter delivery,
first-run setup, backup/recovery, and graceful shutdown remain local. They do
not contact GitHub and continue to work when the Internet or release service is
unavailable.
Security boundary
Check now uses a fixed GitHub stable-release endpoint, an eight-second
deadline, bounded response and private-cache sizes, rejected redirects, exact
stable tag/release/asset URLs, required checksum-manifest metadata, sanitized
errors, and bounded exponential backoff. Cached metadata is validated again
before it reaches the API or UI.
The update endpoints inherit the Manager's authentication, authorization,
session, CSRF, same-origin, allowed-Host, reverse-proxy, secure-cookie,
security-header, and throttling boundaries. Browser input cannot supply a URL,
path, version, command, executable, script, or updater argument.
Windows is the only package with an in-GUI install action. It requires a fresh
successful stable check and separate confirmation, then invokes the existing
fixed Check-Update.ps1 path with fixed arguments. Its UAC approval, archive
checksum, internal manifest, backup, health verification, and rollback remain
authoritative.
Docker and NAS Managers remain non-root and cannot mutate the host. This
release does not mount the Docker socket, add privileged mode, introduce a
helper daemon, invoke sudo or a container engine from the web process, or claim
unattended/one-click installation on a host-managed package.
Host-adapter compatibility
Maintained container packages now report host-adapter API 3 and embed their
release package version in staged Compose manifests. Updating only a container
image may therefore produce a truthful Legacy wrapper state on an older
Compose file, QNAP application, Mac package, FreeBSD rc.d adapter, or saved
Unraid template.
Use the platform owner and migration steps shown in Settings to advance the
host package or saved template. Do not weaken container isolation to hide the
mismatch. Private .env, /data, configuration, credentials, schedules,
history, previews, and backups remain outside release-owned package files.
Validation and limitations
The release gates cover Manager unit, contract, security, accessibility, and
cache-tampering tests; offline, timeout, malformed/oversized metadata,
redirect, prerelease/channel, rollback/downgrade, legacy wrapper, mismatch,
authentication, CSRF, Origin, Host, reverse-proxy, and Windows installer
cases; Windows, Linux, macOS, and FreeBSD cross-builds for amd64 and arm64;
ShellCheck, PowerShell, Compose, Unraid, documentation, link, and repository
contracts; mocked newsletter and SMTP integration; multi-architecture container
build and boot tests; reproducible release archives; and the isolated Windows
installer lifecycle. No real Plex, Tautulli, SMTP, or user configuration is
contacted by automated tests.
Physical QNAP, Unraid, macOS, and FreeBSD host behavior, NAS-vendor reverse
proxies and storage ACLs, Community Applications moderation, and real mail
providers remain environment-specific acceptance checks. No QPKG or app-store
submission is included.