github MacRimi/ProxMenux v1.2.6.2-beta
on GitHub

pre-release3 hours ago

ProxMenux logo ProxMenux v1.2.6.2-beta

The headline of this beta is OCI manager Apps, a new entry in the main menu that installs applications straight from their official container images as native Proxmox LXC containers, with no Docker engine anywhere. It arrives with a catalog of 334 applications, multi-container applications such as Immich, Nextcloud and Paperless, hardware acceleration profiles, updates that keep the data, and recovery after a restore or on another host. ProxMenux Monitor knows those containers too: it registers their application, follows their image for updates, shows their logs and updates or modifies them from the browser.

Around it: a search in the main menu across ProxMenux options, OCI applications and Helper-Scripts, Helper-Scripts addons that run inside the LXC they are meant for, the backup jobs of VMs and CTs managed from ProxMenux, the NVIDIA Container Toolkit installed with the driver, notifications written in the reader's language, a disk history that follows each disk by its serial number, and a long list of improvements across backups, notifications, Audit & Report, the installer and the translations.

A special thank you goes to @Vaso73 and @f3rs3n. Between them they contributed more than fifty pull requests during this cycle: real installations compared against their Docker originals, corrections across OCI manager, the Monitor, backups and notifications, a review of hundreds of messages so that each one says exactly what happened, and the Slovak and Italian of everything new. Their testing and debugging are a large part of why this version is available.

📦 OCI manager Apps (beta) — official container images as native Proxmox LXC

ProxMenux does not build its own containers for these applications: it reads the published recipe of each one and turns it into a native Proxmox OCI LXC. OCI manager Apps is labelled beta as a whole.

The catalog

  • 334 applications from LinuxServer.io, other public image repositories and recipes written for ProxMenux, in the same layout as the Helper-Scripts: a search, the full list, 28 categories and the installed applications. Every application carries its icon and the architectures its image supports.
  • A ✓ marks what was tested for real. 43 applications read Verified: 41 tested in the ProxMenux lab, and PocketBase and Glances tested by the community.
  • Files & Sharing is a category of its own, with the sixteen applications that serve or synchronise files. Among them is ShareCoveX, a file server with a web panel that publishes directories over SMB, NFS or both, with Samba users and Time Machine destinations.
  • Duplicati Official sits next to the LinuxServer image, and HAOS One installs the docker-haos image, unprivileged and with the watchdog proposed by default.
  • An image that is not in the catalog can be installed too, from its Compose file, a docker run command or its reference, with the result shown for review before any LXC is created.

Installing an application

  • The page of an application shows what it will create before anything is installed: its image, the address it will answer on, where its persistent data goes, the acceleration profiles it offers and, for a multi-container application, every container of the set.
  • Two ways to install. The default one asks what every installation decides (storage, where its data goes, DHCP or a static address, how it starts) and takes the rest from the recipe. The advanced one opens every decision in order: VMID and resources, each data path with its location, storage and size, extra paths and devices, the network, the application settings, the GPU and how it starts.
  • Every question says what it asks for, with an example or a proposed value. An application that needs a database or a Redis server that is already running, such as BookStack, NetBox or Manyfold, says so first, with the address of its image documentation.
  • An application is not asked for its own address. BookStack, Healthchecks, Speedtest Tracker and NetBox are given the address of the container: the fixed one, or the one DHCP gives, obtained before the application starts for the first time.
  • The data folders belong to the application. Downloads, series, music, books and backups are created for the user the application runs as, as a container volume or as a host directory, and a new volume starts with what the image holds at that path.
  • USB and serial devices are chosen from a list, by name and type, and every application accepts extra paths and devices in the advanced installation.
  • Applications start with the memory they need: 1024 MB unless the recipe asks for more or sets a limit.
  • The summary ends with what is needed to use the application: its address, and the user and password to sign in with. A service with no web interface, such as MariaDB, PostgreSQL or an SSH server, is given by its address and port.
  • A mistyped value asks the same question again, a static address already in use on the network is not accepted, and creating the container shows its progress while a large image is unpacked.
  • The downloaded image can be deleted when the installation ends, and images no installation uses are removed on their own.

Applications made of several containers

  • One LXC per service, wired through a private bridge of their own and started in order. Immich, Nextcloud, Paperless and Tandoor have their own recipes, ten more come from their published Compose file, and the Arr suite installs each application as an independent LXC connected to the others.
  • Immich asks what runs its video and its recognition: the CPU or each GPU of the host, together or split between two GPUs, with VA-API or NVENC for video and OpenVINO, ROCm or CUDA for recognition.
  • The address offered is the one a browser can reach: the LAN address of the container, in the summary and in its Proxmox notes.

Hardware acceleration

  • The acceleration menu offers only what the host can run: NVIDIA with the driver and the Container Toolkit, Intel or AMD where that GPU is present. The render node proposed is the one of that GPU.
  • AI applications take the image built for the chosen GPU. Ollama gains an AMD (ROCm) profile, llama.cpp offers CPU, CUDA, ROCm and SYCL, and Faster Whisper and Piper offer NVIDIA.
  • Frigate detects objects on an AMD GPU, an Intel NPU or a Coral (NPU and Coral suggested by @jcastro), and its CPU detector runs on AMD processors.
  • ROCm is offered according to the generation of the AMD GPU, as an experimental option on the ones the image does not carry kernels for, and Immich checks the GPU with a real inference before accepting it.

Storage and shared directories

  • A host directory that already exists can be opened to the application that shares it, with access rules (ACL) that leave the owner of the files as it is.
  • A shared host directory shows what the host has mounted inside it: network shares, disks and ZFS datasets, also the ones mounted while the container runs.
  • A shared host directory is recognised by its filesystem, so an application keeps being updated after the host restarts or a disk comes back under another device name (reported by Charly Silva).

Updating, modifying and recreating

  • An update replaces the image and keeps the data. The container is backed up, rebuilt from the new image and asked to answer before the operation is committed; if it does not, everything returns to how it was. Resource changes made from Proxmox are carried over.
  • Every installed application can be updated and modified, privileged containers, host monitors and the applications of the Arr suite included.
  • Modify changes the settings of an installed application; on a multi-container one it adds or removes extra paths and devices without rebuilding anything, and changes what runs recognition in Immich.
  • A multi-container application can be rebuilt as it is (PR #423, contributed by @Vaso73). Recreate every container with its saved configuration rebuilds each container from the image it was installed with.
  • The backup of an operation can be made on another storage when it does not fit on the system disk, and an operation that has no room says so before anything is stopped.
  • A damaged image download or working backup is written a second time before anything fails, and a failed update leaves no temporary container behind.

Watchdog, backups and clusters

  • An application can be put under watchdog. Proxmox has no restart policy; with the watchdog on, an application that stops on its own is started again, with a notification. A stop asked by the user, a backup, a migration or a ProxMenux operation is never undone.
  • The record of an application travels with its container. A copy lives inside it and another in /etc/pve, so a vzdump or PBS backup always carries it.
  • A restored application is offered for recovery, on a new Proxmox installation, on another host or with another ID. The recovery puts back what the host kept for it, such as the private network of a multi-container application, and checks everything before the host is changed.
  • In a cluster, the record follows the container. A migrated or HA-moved single-container application starts and is registered on the node it arrives at.
  • A container that reboots itself keeps its DHCP address, as Home Assistant OS does from its settings.

Removing an application

  • Everything the installation kept on the host goes with it and the result says whether anything was left undone (PR #402, contributed by @f3rs3n). Host directories are kept, and an application of the Arr suite is removed on its own.

Tested against their Docker originals (contributed by @Vaso73)

Real installations compared side by side with the same images under Docker, and what they brought:

  • An image's initial data reaches its new volume (PR #394), as PocketBase needs.
  • A host monitor is reached through the firewall, on request (PR #393, PR #395): Glances gets a narrow rule, confirmed separately and removed with the application.
  • Stack members keep their data on a prepared volume (PR #410), including the data path of current PostgreSQL images.
  • Stremio, Uptime Kuma and images that need a home directory start as they do under Docker (PR #411, PR #412, PR #413).

📱 OCI applications in ProxMenux Monitor

  • The App tab registers what ProxMenux installed. The application of an OCI container is registered by itself with its name, logo, address and version tracking, read from the installation record, also while the container is stopped. Every service an application serves gets its own link, and a service with no web interface shows its address and port as text.
  • Updates are tracked by the image. The card shows the version of the application and the image it runs, with its build date and digest; a new image under the same tag is an update.
  • The Updates tab updates and modifies the container. Update and Modify open the Monitor terminal on the same flow as the OCI menu. The backup taken before updating can be kept, image updates can be scheduled, a multi-container application is updated from its main container, and a restored application shows a Recover button.
  • A new Logs tab shows what the application writes to its console, kept on the host from the first start: the last lines since the last start, followed live, with a filter and a download.
  • The Proxmox console of an OCI container opens a shell, the equivalent of docker exec, whenever the image ships one.
  • The Watchdog switch sits in the container modal, under Start at boot.
  • An OCI operation sends one notification with its result, instead of one per step. Modify and the rebuild of a multi-container application have notifications of their own.
  • The update icon of the Apps page opens the Updates tab of that container.

🔎 Search in the main menu

  • The main menu opens with Search options and applications. A name or part of it finds an option of ProxMenux, an application of the OCI catalog or a Helper-Script, in that order, by name first and then by category.
  • Every result opens what its name says: a script at its first screen, an application at its page, an option of the post-install or a system utility in its list with it already marked. Nothing is run by the search itself.
  • The Helper-Scripts catalog is kept on the host and refreshed once a day, so the search also answers without a connection.

🧩 Helper-Scripts addons run where they belong

  • An addon is run where its catalog says: on the Proxmox host, inside an LXC picked from a list, or wherever is chosen when it can be both. A stopped LXC is started on confirmation, and OCI containers are left out.
  • Descriptions and notes are shown as plain text, and a script is downloaded whole before anything runs.

💾 VM and CT backup jobs managed from ProxMenux (PR #421, contributed by @MattiaC46)

  • The Backup tab of the Monitor has two views, Host and VMs and LXCs. The second one, and the Host Backup & Restore menu, list the scheduled jobs of Proxmox, the same ones as Datacenter → Backup, and create, edit, enable, disable, delete and run them through the Proxmox API.
  • Run now starts a Proxmox task on each node that has a guest of the job. Changing a job needs an administrator session; a read-only API token can only list them.

💾 Backups and restore

  • Backup notifications say how the job ended (PR #406, contributed by @f3rs3n): clean, with warnings, failed or unconfirmed, naming the guest that failed, with long diagnostics kept readable. The recovery summary counts each guest once (PR #356).
  • A backup started from the Monitor runs in its own systemd unit and continues whatever happens to the Monitor.
  • A host backup works on a host with SELinux (#398, reported by @sbaghdadi) and keeps all of ProxMenux's host state under /var/lib/proxmenux.
  • Host backup notifications arrive with HTTPS enabled in the Monitor (reported by @sahartford).
  • A remote Borg repository authenticates with the key saved on its destination (#357, reported by @bartclone), offering only that key, and keeps its remote path as it was written.
  • A host restore is scheduled only once it is complete (PR #341, contributed by @f3rs3n): each restore is prepared in its own directory and becomes the pending one only when every step succeeded.

🟢 NVIDIA installer

  • The NVIDIA Container Toolkit is installed with the driver. It is what lets a container see the host's GPU. It can also be put back on its own, and it is recorded in the Changes view of Audit & Report.
  • The version picker offers the drivers that support the GPU and can build against the running kernel, and opens in about five seconds.
  • A version is proved to build before the working driver is removed. One that does not build returns to the list with the current driver untouched, and the answer is remembered for that kernel.
  • The result reports what the driver does: a driver that installs but does not drive the GPU is recorded as failed, with the kernel's own reason.
  • Containers created from an OCI image stay out of the LXC menus that install into a container: driver propagation, Add GPU to LXC, Coral, disks and shares. Their devices and paths are changed from OCI manager Apps.

💽 Disks

  • The observations of a disk belong to its serial number. A replaced disk starts with a clean history, the history follows a disk to another device name, and it is permanent: the same observation seen again adds to its count.
  • Mechanical disks are left to spin down (#347, reported by @spectante). A rotational disk nothing is using is not read at all, the storage view says Idle or Excluded beside Standby, and Settings → Disk exclusions keeps a disk out of every scheduled read.
  • Disk formatting keeps what it promises to keep (PR #339, PR #340, contributed by @f3rs3n): removing signatures leaves the partition table alone, and the system disk is recognised through stacked LVM, RAID or ZFS.
  • The storage summary distinguishes unavailable disk temperatures and qualifies the SMART status (PR #365, PR #372, contributed by @f3rs3n).
  • A notice of smartd about its own configuration, or fstrim on a disk that cannot discard, is not reported as a failure.
  • Volume mount points on block storage show their usage in the Mount Points tab.

🔔 Notifications

  • Notifications in the reader's language (PR #348, contributed by @Vaso73): titles, bodies, channel labels and daily digests follow the language chosen for notifications, long Telegram messages are split without breaking their formatting, and the wording was reviewed by hand.
  • Temperature and health alerts carry their values (PR #408, contributed by @f3rs3n): the reading, the threshold and the category in the reader's language.
  • A cluster event notification says what happened (PR #403, contributed by @f3rs3n), with the original message from Proxmox.
  • Proxmox notifications arrive with HTTPS enabled on the Monitor, through a local listener that answers only the notification webhook.
  • The Monitor leaves /etc/pve alone while Proxmox restarts its cluster service (#427, reported by @shtefko). Notification settings are written only while /etc/pve is mounted and only when they change, their copies are kept with ProxMenux, and uninstalling the Monitor removes its target from Proxmox.
  • A log pattern is reported as persistent only while it keeps recurring (#386, reported by @Joshua1264).
  • Excluded storages stay out of the capacity alert (reported by @christiannieveslauz), and a storage that is filling up says how full it is.
  • A private bridge with nothing connected is not reported as down.

🔎 Audit & Report

  • An accepted risk can carry a review date without an expiry (#343, with @Vaso73): the decision stays in force and comes back to be looked at.
  • The assessment comparison says which way a finding moved (#343, with @Vaso73): worse, better or held, in the view and in the printed report.
  • The assessment describes its own effects accurately (PR #352, contributed by @f3rs3n), and the Lynis removal says what happened (PR #404).
  • Audit findings and printable reports fit narrow screens (PR #399, contributed by @f3rs3n).

🔐 The Health Monitor API follows the same token rules as the rest of the API

  • Reading health data requires a token once authentication is set up, and every Health Monitor route that changes something requires a full-admin token. /api/system-info stays public for external probes such as Uptime Kuma.

🖥 ProxMenux Monitor

  • A VM or LXC edited from Proxmox shows its current settings the next time its modal opens: start at boot, tags, cores, memory, network and mount points.
  • The VM and LXC search finds a container by any of its addresses (PR #385, contributed by @Vaso73), and the card shows how many more it has.
  • Available updates on the overview follow the host (#359, reported by @ash34), whichever way the packages were installed.
  • The Proxmox update log says what was updated (#358, reported by @ash34), and the list of packages is shown before the update is accepted.
  • Docker containers pinned by digest stay in the inventory (#206, reported by @byGarcia), marked Pinned to a digest and never offered an update.
  • LazyLibrarian and PeaNUT join the LXC application catalog (with @pdafoto); LazyLibrarian is the first entry tracked by commit.
  • Secure Gateway shows the same update state on the Security page and in the Updates tab of its container.
  • Typing a number in a script terminal keeps the session open.

📦 Installer, updates and post-install

  • The installer shows its steps, not apt's output, and a host without a subscription installs without apt errors on screen. Duplicate repository declarations are commented out.
  • Dependency checks keep the configured Proxmox repositories (PR #407, contributed by @f3rs3n): the switch to no-subscription is offered, not applied, and it is recorded in Audit & Report.
  • pigz keeps working after a gzip update (PR #414, PR #415, contributed by @pbr85): gzip is diverted instead of replaced, and its compression level is applied. The journal helpers report a copy that cannot be written (PR #417, PR #418).
  • The PVE 8 → 9 upgrade stops when the plan would remove proxmox-ve (PR #349, contributed by @f3rs3n), and a failed index refresh is reported as one.
  • Post-install reads the host's memory in any language (#353, reported by @linux-fertxo), and Log2RAM 1.6 sizes itself from it.
  • Fastfetch keeps its system modules on current releases (PR #355, contributed by @f3rs3n).

🌍 Languages and wording

🙏 Acknowledgments

  • @Vaso73 — the side-by-side testing of OCI applications against their Docker originals and the fixes that came from it, the rebuild of multi-container applications from their saved state, notifications in the reader's language, the search by every address of a container, the Audit & Report review dates and comparison, and the complete Slovak of this beta.
  • @f3rs3n — the review of hundreds of messages across the menus, backups, storage and OCI manager, backup, health, temperature and cluster notifications, the disk formatting and host restore safeguards, the repository and PVE upgrade checks, the test suites, and the complete Italian of this beta.
  • @MattiaC46 — the VM and CT backup jobs.
  • @pbr85 — the gzip diversion for pigz and the journal helpers.
  • @byGarcia, @pdafoto and @jcastro — Docker images pinned by digest, the LazyLibrarian and PeaNUT detectors, and the Intel NPU and Coral detection for Frigate.
  • @shtefko, @Joshua1264, @sbaghdadi, @ash34, @bartclone, @spectante, @linux-fertxo, @sahartford, @christiannieveslauz and Charly Silva — the reports behind the /etc/pve handling, persistent log errors, host backups with SELinux, the update count and log, remote Borg repositories, disk spin-down, post-install on any locale, backup notifications over HTTPS, storage exclusions and shared host directories.

Beta feedback is welcome in Discussions or as an issue.

Check out latest releases or
releases around MacRimi/ProxMenux v1.2.6.2-beta

Don't miss a new ProxMenux release

NewReleases is sending notifications on new releases.

Get notifications