- Uninstall removes the installation directory again after the change journal writes to it
- Show version information counts jq installed from GitHub as installed
- Spanish calls the release channel «canal de versiones»
- Open the post-install menu from the PBS menu
- List only the customizable options that apply to PBS
- Offer the PBS no-subscription repository through the native repository API
- Upgrade PBS with the package list shown before applying it
- Remove and restore the subscription notice on the PBS web interface
- Install Figurine on PBS without the Proxmox VE aliases
- Offer the Helper-Scripts PBS post-install and microcode scripts
- Tune firewall bridges after the systemd udev rules in the automated post-install
- Add PBS repository policy tests and syntax checks
- Document the PBS differences on the post-install page
- Use backups in the Spanish PBS update message
- On a PBS host the Monitor no longer starts the node metrics and VM prewarmers, the LXC update scheduler, the managed installs detector or the app update emitter, which read guests and PVE metrics that do not exist there
- pmx_require_pve refuses only a host known to be PBS, so an unreadable package list leaves the PVE scripts working as before
- The PBS menu numbers its options, shows the tables proxmox-backup-manager prints instead of raw JSON, and says Goodbye on exit
- The PBS update asks to press Enter before returning
- Spanish: Datastores de PBS
- Registry accounts are kept in /etc/pve/priv/proxmenux/registry-auth.json, shared by every node, unless REGISTRY_AUTH_FILE says otherwise
- The custom image importer offers to sign in when a registry refuses an image, and reads it again
- Installers, updates, the watchdog and the Monitor update check read private images with the saved accounts
- The host backup includes the accounts, and uninstalling ProxMenux removes them and keeps the OCI records of the cluster
- Spanish written by hand and spacing fixed for the registry account messages in every locale
- Docs: private registries section, Registry accounts in the OCI menu, README storage notes
- NAS menu: FygoOS, with the latest installer published on fygonas.com detected and a fallback version
- Menu search finds the NAS menu by the name of each system
- Docs: FygoOS card and per-system notes, including its web port
- OCI manager Apps carries the Technology Preview label that Proxmox VE gives to application containers from OCI images, in the main menu, the engine windows, the menu search, the message at the end of each installation, the release notes and the documentation.
- The documentation explains that the label refers to the Proxmox VE support it runs on, not to the ProxMenux engine, and stays until Proxmox VE marks it as stable.
- Spanish for the new message; the other languages are left to the translation bot.
The main menu opens with a search that finds an option of ProxMenux, an application of the OCI catalog or a Helper-Script by its name or by related words, in that order, and by category after the names.
Every result opens what its name says and nothing is run by the search itself: a script starts at its first screen, an application opens its page, an option of the post-install or a system utility opens its list with it marked, and an option that lives inside a menu is opened by that menu, which stays behind it.
The menus take the option to open as an argument and behave as before without one. The Helper-Scripts catalog is kept on the host and refreshed once a day. The main menu, the lists of OCI manager and the Helper-Scripts menu share the same height.
An addon is run where the catalog lists it: on the Proxmox host, inside an LXC chosen from a list, or wherever is chosen when it can be both. The LXC is started when it is stopped, and OCI containers are left out. Until now every addon ran on the host.
A script is downloaded whole before anything runs, so a failed or empty download runs nothing. Descriptions and notes the catalog writes in HTML are shown as plain text.
The menu opens one script given as argument, and is as tall as the main menu.
- Nothing is written under /etc/pve unless it is the mounted cluster
filesystem; a Monitor that starts while pve-cluster is being restarted
waits for it and registers its webhook afterwards.
- The Monitor service is ordered after pve-cluster.service.
- The settings are written only when they have to change. The copies
taken before a change are kept in
/usr/local/share/proxmenux/backups/pve-notifications, and the ones left
in /etc/pve by earlier versions are moved there.
- Uninstalling the Monitor removes its target and matcher from Proxmox.
Reported in #427.
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>
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>
## i18n
- Swedish (sv) wired end-to-end: `MESSAGE_CATALOG` in `provider.tsx` now imports `sv/common.json`; `SUPPORTED_LANGUAGES` reordered as English + alphabetical native and all eight locales marked complete.
- Settings → Interface language: the per-locale status cards grid is retired now that all eight locales are populated end-to-end; the dropdown selector is the only control.
- CLI change-language dialog (`scripts/menus/config_menu.sh`) picks up Swedish and matches the Monitor ordering.
- Spanish catalog: label polish across the dashboard — *VM y LXC activos* / *11 VMs* / *11 detenidos*, LXC modal tabs shortened to *App / Actualiz. / Montajes / Copias*, *Limpiar / Cerrar* replacing the wrong *Claro / Cerca* in terminal controls, *En ejecución / Ejecutar* replacing the literal *Correr*.
- Cross-locale normalisation across ES / DE / FR / IT / PT / SK / SV: *OK* / *Proxmox System Dashboard* / *Warn* labels stay consistent, *AVG / MAX / MIN* kept verbatim as universal abbreviations so the stats row no longer overflows.
- Tailscale brand preserved verbatim across ES / FR / IT / PT — previous machine-translated variants like *"escala trasera"* / *"à grande échelle"* restored.
## Docs
- `ROADMAP.md` rewritten as a short invitation to the [ProxMenux Roadmap project board](https://github.com/users/MacRimi/projects/1). `ROADMAP.es.md` removed — it mirrored the same outdated version-milestone plan and the docs site keeps the Spanish surface for users who need it.
- `release.md` annotated with nine pending sections for the v1.2.4.1 beta cycle.
## AppImage
- `ProxMenux-1.2.4.1-beta.AppImage` replaces the previous `ProxMenux-1.2.4.AppImage`. Sidecar `ProxMenux-Monitor.AppImage.sha256` regenerated.
The HOST block already groups everything that runs on the host
side, so the secondary "Host-only resources" divider between item 4
and item 5 was visual noise — the user reading the menu sees two
HOST sub-titles back to back and has to wonder how items 1-4 differ
from item 5 in scope. They don't; items 1-4 register an external or
local resource as a Proxmox storage, item 5 creates a local shared
directory. Both are host-side actions.
While here, retitle item 5 from "Add Shared Directory on Host" to
"Create Shared Directory on Host" — items 1-4 add an existing
external/local resource, item 5 creates a new one.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
VAIO73
MacRimi
MacRimi
Jonatan
Vaso73
