- Immich asks what runs its video and its recognition in one menu, in both
modes, and gives the GPU to the server and to Machine learning; AMD uses ROCm
- Frigate, Ollama, llama.cpp, Faster Whisper and Piper take the image built
for the chosen GPU
- The acceleration menu offers only what the host can run
- An update or a recreation sends one notification with its result instead of
the stop, backup and start of each container
- A private bridge with nothing connected is not reported as down
- Secondary containers of a stack appear in the App tab with their version and
logo; Secure Gateway shows the same update state in both views
- A mistyped value in the wizard asks the same question again
- Apply the static mount list as soon as it arrives instead of waiting
for the df/stat runtime probe.
- Refill a guest's mount seed after a lifecycle event rather than
leaving it empty until the next modal open.
- Retry the bulk modal cache while the server is still warming guests.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
OCI manager Apps
- App tab: containers installed from an OCI image are identified from their
installation record; the application and image versions are shown and an
update is detected by image digest; repository link; Refresh data.
- Updates tab for OCI containers: Update and Recreate run the same flow as the
OCI menu in the Monitor terminal; the pre-update backup can be kept in a
backup storage; scheduled image updates with an optional minimum age.
- Logs tab: console output of the application, kept on the host
(lxc.console.logfile + logrotate) and followed live.
- The Proxmox console opens a shell (cmode: shell) when the image has one.
- A damaged image download is fetched again before failing.
- Multi-container applications open at their LAN address; volume mount
points on block storage report their usage.
Monitor
- Proxmox notifications are delivered to a loopback-only HTTP listener when
HTTPS is enabled, so they no longer fail certificate verification.
- Log persistence counts recurring patterns only; an ended burst is not
reported as persistent and its warning clears on its own (#386).
- Proxmox notification config backups are deduplicated and capped at three.
- The update icon on the Apps page opens the container on its Updates tab.
- Version 1.2.6.2-beta and its release notes in every Monitor language.
Docs
- OCI manager Apps and Audit & Report rebuilt as per-page message files,
with a new page for OCI containers in the Monitor.
- Seven pages fixed where rich-text tags were missing from t.rich.
Translations
- Spanish fixes across the OCI engine, the Monitor and the TUI menus.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Both batches seed the same block for their English-only additions. One
read and one write now cover the PBS key guidance and the Borg SSH keys
together.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Adds the OCI manager: an engine that turns a Docker Compose file into an
LXC definition, a catalog of 365 applications drawn from LinuxServer.io
and other container image sources, and a per-instance registry recording
what each container was built from. Reachable from the main menu.
Catalog text is translated like every other string in the project: the
taglines go through translate() and land in lang/*.json, so the entries
read in all eight languages instead of only English.
Translation cache builder:
- a failed translation leaves the key absent rather than writing English,
which previously made the string count as translated forever
- a result identical to a 3+ word source is rejected, catching a provider
that silently returns the text it was given
- strings that are nothing but glossary terms keep their source spelling
instead of being discarded as failures
- no backoff between attempts when the provider is deterministic
- application names are protected so "HAOS One" survives translation
- argos joins the provider list, and the workflow reads the OCI sources
Audit & Report:
- findings that moved in the wrong direction between runs are reported
alongside the ones that improved
- an accepted risk can carry a review date and is flagged when it falls due
- backup checks explain in plain language what they looked at and what to
do next
Monitor:
- disks can be excluded from periodic reads, and an idle disk says so
instead of showing a stale temperature
- per-disk identity survives a controller or enclosure change
- scheduled Borg backups resolve their SSH key from the repository entry
- PVE upgrades log the package list and the resulting dpkg changes
The web build no longer copies scripts/ into public/: the documentation
links to GitHub, so nothing read that folder.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both message batches seeded locale copies at the same point of
test_command_descriptions.py. The two blocks are independent — one
seeds the backup messages, the other the storage ones — so they are
merged into a single block that reads and writes the fixture once.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The change journal exists so a sysadmin sees what ProxMenux changed on the host — its own configuration, packages and services — not how it uses the host or configures a guest. Several scripts recorded operations that are neither: disk passthrough to a VM, container conversions, VM import/export, mounting a share into an LXC. Those are restored to their original, uninstrumented form. Scripts that operate on the host while also installing a package now record only the package: format-disk keeps its exFAT-tools install, the UUP ISO builder its build dependencies, and the share/host scripts their packages, services and /etc/fstab writes, while the mount and unmount operations they used to log are dropped.
The page now reads in three sections: what ProxMenux optimized after install (each function under its menu name), what its other host scripts changed (by script), and what it installed (packages and utilities, each referencing the script that installed it). A file reads as created or modified with its diff, a service shows its state transition, and the undo line appears only when a revert is possible.
ProxMenux modifies the host: it rewrites configuration files, installs packages, enables services. Until now nobody could say afterwards what had changed, and showing the script does not answer that question — a four-hundred-line function may alter two values, and the reader has no way to know which two. This adds the two halves of an answer.
The change journal records what ProxMenux does as it does it. Eleven bash primitives capture the previous state, apply the change and record it in the same step, writing to a spool that the Monitor reads back. One hundred and thirteen functions across twenty-five scripts are instrumented, covering post-install, shared storage, security tooling, container conversions, disk operations and the PVE 8 to 9 upgrade path. The page shows the difference — rotate 7 becoming rotate 14 — and never the script. Restore and backup scripts are deliberately left out: a restore puts the host back to a state some other script already recorded.
The Audit and reports page answers the other half: what state is this host in, regardless of who put it there. Forty-three checks across seven areas read the host and classify each result as critical, warning, observation, conformant, unverified or not applicable, with the evidence they read attached to each one. A declared policy lets the reader say what this particular host is expected to do — which guests must have a backup, which storages are essential — so the report judges the host against its own intent rather than a generic template. An inventory records the hardware, network and guest topology behind those readings, a comparison shows what moved between two runs, and six report profiles produce a printable document scoped to what the reader needs. Everything is available in the eight supported languages.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MacRimi
martino
MacRimiandGitHub
VAIO73
Vaso73andVAIO73