Security and support

The image catalogue shows each image's declared lifecycle state, admission policy, review date, and support boundary. These fields are repository policy. They do not prove that a registry artifact exists, that a runtime test passed, or that upstream vendors still maintain every included component. Use the maintenance evidence guide to match a published index digest to architecture-specific runtime and vulnerability records.

Docker and Podman images are isolated compatibility fixtures. They share the runner kernel, cgroups, and host security policy, and some require a privileged outer container. Rootless inner mode does not remove that outer trust boundary. Historical engine lines and Debian 11 targets remain useful for compatibility testing even where their upstream security maintenance has ended. Do not treat a daily rebuild as a patch to an old pinned engine binary or an end-of-life distribution. The Docker and Podman guides document coverage and exclusions, including Podman UBI/openSUSE rootless nested-runtime omissions and Debian 11 Docker rootless's outer --oom-score-adj=0 requirement.

The application images have production admission policy, subject to matching publication evidence and the consuming stack's own review. Nextcloud PHP-FPM and TYPO3 PHP-FPM do not bundle those applications, their site configuration, web server, or persistent data. notify_push requires the surrounding Nextcloud, database, and Redis services. A clean vulnerability scan is not a guarantee: scanner package detection can miss manually copied or statically linked dependencies, and a passing smoke test does not cover a full deployment.

Before using an image, resolve its tag to a digest, inspect the image's installed-component manifest and SBOM, and confirm a maintenance release whose image, index digest, architectures, source revision, and run identity match. unknown in a catalogue evidence column means no matching record was supplied. An observedAt registry check is only a point-in-time observation of a mutable reference. Read tags and versions for the distinction between source, build, publication, package, and observation times.

For non-sensitive support requests or bug reports, open a GitHub issue with the image name, architecture, exact digest, and sanitized reproduction. Follow SECURITY.md for sensitive vulnerability reporting. At present, GitHub private vulnerability reporting is disabled and no verified security email is published; do not paste exploit details or credentials into a public issue.

The repository has an AGPL-3.0 license text. That does not replace the licenses of upstream engines, PHP, Nextcloud notify_push, base distributions, or installed packages. Check upstream notices and each published image's SBOM for bundled components and their obligations. The vulnerability scanning guide describes current admission policy and exception review; the operations guide covers rollback to a verified digest.

View source ↗ Read as Markdown Source updated