byGarcia
de72e18a77
An LXC running its workload in Docker could not answer two questions it already had the data for: which application is in there, and whether a newer version exists. **Which version is available.** The Updates tab resolved that number only for docker.io, and only when a version tag happened to share the digest of the tag in use. On ghcr.io, lscr.io or quay.io the row said "New image available" with no number at all. The image a pull would install carries its own version label, so it is now read from the registry by digest — over the same protocol and Bearer challenge the digest comparison already uses, and through the same label lookup the installed version uses, now shared as _docker_version_from_labels. The question this answers is the one the tab asks: what do I get if I re-pull this tag. Not "what is the newest upstream release", which is a different number whenever a tag is pinned or the publisher tags releases differently from images. Docker Hub keeps priority on docker.io: its tag API is not a pull and does not spend the anonymous pull-rate budget, and official images carry no labels for the registry path to read. The digest still decides whether an update exists; this only names it, and declines to name it when the answer would be a guess — no build for this platform, no labels, an unreadable manifest, a moving tag, a rebuild of the same version, or two sides whose versions came from different label keys. Each refusal is recorded in available_version_source. Attestation manifests are skipped explicitly: they advertise unknown/unknown and their config blob is a provenance document, not an image. Every document is fetched by digest and verified against it, the config read is bounded, and it is cached per digest, which never changes content. The CDN redirect is followed by hand, dropping Authorization: urllib re-sends it to the redirect target and signed-URL storage rejects a second auth mechanism. **Which application it is.** The probe already read "1.37.2" out of a Vaultwarden container and get_suggestions discarded it, so the panel answered "No new applications were detected" about an application whose version it had just measured. Containerised applications are now offered for registration like any other, with their name, logo, published ports and installed version. What they do not get is an update path of their own, because they do not have one: updating Vaultwarden means pulling and recreating its image. A new update_via=docker marker records that delegation, so one release stays one badge, one notification and one button. The marker is validated rather than inferred from installed_via, since docker_exec with an upstream is a legitimate registration someone may already rely on; combining it with an upstream is rejected instead of silently stripped, because registering an app that checks GitHub behind a delegation promising it will not is worse than an error message. Three failure modes the delegation had to be defended against: detector auto-healing would have migrated the app onto a leftover /root/.<app> marker and quietly un-delegated it; saving replaces the whole record, so the editor carries the marker explicitly rather than dropping it on the first port edit; and the release-age hold gates on a publish date a delegated app never has, which deferred the whole schedule forever. Their version is resolved server-side through the container the detector declares — not through the app's name or image, since Immich's compose service and image are both immich-server while the application is immich. The annotation happens on the way out of both endpoints rather than into their caches: the App tab's cache is invalidated by events, not by time, and the Docker inventory it reads is built asynchronously, so annotating before storing froze a response taken before the first scan. The rows carry that name too. display_name was already computed and already used by the bulk-update section; the image row, the update notification and the CT badge now use it as well. A delegated app's pending update counts in the badge only while its image is not already being counted, so registering just the application does not leave the container looking up to date, and registering both does not count twice. Catalog: four detectors verified on real containers, following the rules in the file. vaultwarden and immich gain docker fallbacks for installs where the native marker does not exist. netalertx is new — note its repository is netalertx/NetAlertX; the Docker Hub namespace 404s. technitiumdns is new and uses Technitium's own update endpoint rather than GitHub releases: its marker reads 15.4 while the release tag is v15.4.0, and _version_tuple compares (15,4,0) > (15,4) as an update that would never clear. Verified live against ghcr.io (Immich 3.1.0), docker.io (Vaultwarden 1.37.2) and lscr.io (Radarr 6.3.0.10514-ls314), plus postgres:16, which correctly reports no version because official images carry no labels. Exercised end to end on Proxmox VE 9.2.4 with NetAlertX reporting 26.6.3 -> 26.9.0. 31 new unit tests cover the resolution rules, every refusal, the delegation contract and the container-to-image pairing.
ProxMenux is an interactive toolkit for Proxmox VE — a menu-driven CLI plus a web dashboard for post-install, backup/restore and continuous health monitoring of your homelab.
📌 Installation
To install ProxMenux, simply run the following command in your Proxmox server terminal:
bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/main/install_proxmenux.sh)"
⚠️ Be careful when copying scripts from the internet. Always remember to check the source!
📄 You can review the source code before execution.
🛡️ All executable links follow our Code of Conduct.
📌 How to Use
Once installed, launch ProxMenux by running:
menu
Then, follow the on-screen options to manage your Proxmox server efficiently.
🖥️ ProxMenux Monitor
ProxMenux Monitor is an integrated web dashboard that provides real-time visibility into your Proxmox infrastructure — accessible from any browser on your network, without needing a terminal.
What it offers:
- Real-time monitoring of CPU, RAM, disk usage and network traffic
- Overview of running VMs and LXC containers with status indicators
- Login authentication to protect access
- Two-Factor Authentication (2FA) with TOTP support
- Reverse proxy support (Nginx / Traefik)
- Designed to work across desktop and mobile devices
Access:
Once installed, the dashboard is available at:
http://<your-proxmox-ip>:8008
The Monitor is installed automatically as part of the standard ProxMenux installation and runs as a systemd service (proxmenux-monitor.service) that starts automatically on boot.
Useful commands:
# Check service status
systemctl status proxmenux-monitor
# View logs
journalctl -u proxmenux-monitor -n 50
# Restart the service
systemctl restart proxmenux-monitor
🧪 Beta Program
Want to try the latest features before the official release and help shape the final version?
The ProxMenux Beta Program gives early access to new functionality — including the newest builds of ProxMenux Monitor — directly from the develop branch. Beta builds may contain bugs or incomplete features. Your feedback is what helps fix them before the stable release.
Install the beta version:
bash -c "$(wget -qLO - https://raw.githubusercontent.com/MacRimi/ProxMenux/develop/install_proxmenux_beta.sh)"
What to expect:
- You'll get new features and Monitor builds before anyone else
- Some things may not work perfectly — that's expected and normal
- When a stable release is published, ProxMenux will notify you on the next
menulaunch and offer to switch automatically
How to report issues:
Open a GitHub Issue and include:
- What you did and what you expected to happen
- Any error messages shown on screen
- Logs from the Monitor if relevant:
journalctl -u proxmenux-monitor -n 50
💙 Thank you for being part of the beta program. Your help makes ProxMenux better for everyone.
🔧 Dependencies
The following Debian packages are installed automatically during setup:
| Package | Purpose |
|---|---|
dialog |
Interactive terminal menus |
curl |
Downloads and connectivity checks |
jq |
JSON processing |
git |
Repository cloning and updates |
python3 + python3-pip |
ProxMenux Monitor (Flask web dashboard) |
UI translations ship as pre-built JSON files per language (English, Spanish, French, German, Italian, Portuguese). There is no runtime translation dependency.
🤝 Contributing
ProxMenux is an open, collaborative project — contributions of every shape are very welcome, no matter your background. Every PR, bug report, idea, translation or kind word helps move the project forward.
📖 Before sending code, please read the Contributing Guide. It covers the project structure, the UI design policy (the two-phase
dialog/whiptailflow), message helpers, translation policy and submission conventions — what reviewers will look for in your PR.
Ways to help:
- 💻 Code — fix a bug, polish a script, add a feature. Read the Contributing Guide first, then open a pull request.
- 🐛 Bug reports — found something broken? Open an issue with steps to reproduce, and the Monitor logs if relevant (
journalctl -u proxmenux-monitor -n 50). - 💡 Ideas & feedback — share suggestions in GitHub Discussions. Every idea is welcome.
- 🌍 Translations — the documentation site already supports English and Spanish; help expand it to more languages following the translation guide (one page per PR).
- 🧪 Beta testing — run the beta build and let us know what you find.
- ⭐ Spread the word — a GitHub star or a mention in your homelab community helps others discover the project.
Before contributing, please take a moment to read our Code of Conduct.
Contributors
Thanks to everyone who has helped make ProxMenux what it is today.
Made with contrib.rocks.
⭐ Support the Project
If ProxMenux is useful to you, the simplest way to support it is a ⭐ on GitHub — it really helps others discover the project.
If you want to go a step further, a coffee on Ko-fi keeps development going:
📈 Project Growth
Stars, forks, and Git clones tracked with Repo Growth.