Proxmox VE Helper Scripts in October 2026: new scripts, breaking changes and how to update safely

Proxmox VE Helper Scripts shipped four daily releases between 23 and 26 October 2026, with 10 new scripts, two breaking changes and several Node.js 24 bumps. If you run helper script containers, check Hermes Agent and tubearchivist before you update, note the new Debian 13 requirements, and take a snapshot before running update in any container.

Search interest has jumped this week too. Google Trends showed "proxmox ve helper scripts" at 76.9 for the last seven days against 7.5 for the 83 days before, a rise of about 925%, and listed it as a breakout rising search on 27 October 2026. This post covers what changed in the October releases and how to update existing containers without surprises. For what the scripts are and how to start with them, see the Proxmox helper scripts guide.

What the project is today

The scripts live in the community-scripts/ProxmoxVE repository, which had 29,934 GitHub stars when I checked the GitHub API on 27 October 2026. Its README describes "more than 700" application scripts and points to community-scripts.org for the copy and paste install commands. The old community-scripts.github.io/ProxmoxVE address now redirects there.

A script only describes what to install. The README explains that a shared engine in the separate core repository creates the container, asks the questions and handles errors, and every script loads it at start. So a change in core reaches every script at once, which matters for two of this week's changes.

New scripts added from 23 to 26 October 2026

According to the 26 October release notes, seven scripts were added that day: Vane, HomeTube, Honcho, YTPTube, Stump, Casdoor and Streamystats. The 25 October release added Dreeve, TaskView and EmDash. The 23 and 24 October releases added no new scripts.

New scripts are the least risky part of a release for existing users. They only touch your host if you run them.

Changes that affect existing installs

Two breaking changes on 25 October

Hermes Agent now installs, updates and runs as a dedicated hermes user. The pull request (#18203) says the root run update had stopped working for every install, and that the next update moves an existing container over once: the system unit becomes a user unit, leftover root processes are stopped and /home/hermes is handed back to the hermes user. If you have your own systemd overrides or scripts that call Hermes as root, check them after the update.

The tubearchivist script was changed to prepare for tubearchivist v0.6.0 (#17867). The release notes flag it as breaking, so snapshot that container before you update it.

The same release changed Jellyseerr: fresh installs now point to Seerr instead of a missing install script. Immich now stops early on Debian 12 instead of failing at apt. For more on running Immich this way, see Immich in a Proxmox LXC.

Debian 13 for some scripts

The 23 October release made three scripts require Debian 13: podman-homeassistant, apache-guacamole and unifi-os-server. For apache-guacamole, the pull request (#18094) explains that a needed package exists only from Debian 13 (trixie) on, so a Debian 12 override failed at the dependency install. The script now defaults to Debian 13. If you pick Debian 12 in Advanced mode out of habit, expect it to fail.

The same release dropped the Intel oneAPI Base Toolkit from the openwebui and ollama scripts. If you used either on an Intel GPU, read those two pull requests (#18098 and #18097) before you rebuild.

Node.js 24 bumps

On 26 October, automated pull requests moved several apps to Node.js 24: excalidash and readmeabook from Node.js 20, and homepage and meshcentral from Node.js 22. On 25 October, a core change taught the engine to upgrade Node.js in place when an app package depends on it. Most apps should not care about a Node.js major version change, but a container with extra npm packages you installed yourself might. Snapshot first.

An install now survives a closed console

The most useful change for daily use is in core (core#167). Before, closing the Proxmox shell or losing the SSH session sent a hangup signal to the script, which stopped the container and left it half built. Now the install keeps running, apt or npm included, and the host reports the result when it can. Ctrl+C still aborts. The 24 October release already let installs answer every prompt from the environment and survive a closed stdin.

VM settings now reach qm

A 26 October fix (#18232) passes the machine type, CPU, disk cache and discard settings to qm. According to the pull request, the MikroTik RouterOS script asked for machine type, CPU model and disk cache and used none of them, HAOS and TrueNAS dropped the chosen disk cache, and UniFi OS Server dropped the discard and SSD flags. If you built one of those VMs with Advanced settings, open the VM's Hardware tab and check that the settings are what you chose. The fix applies to new VMs.

Containers from the linuxcontainers.org catalog

Another core change (core#25) creates containers from the linuxcontainers.org image catalog when Proxmox has no template for the requested OS and architecture. The pull request says this opens up 22 distributions on arm64 Proxmox, against the two templates pveam ships. On amd64 it only applies to distributions Proxmox does not ship, such as Oracle Linux, Amazon Linux, Kali and Mint.

The 25 October release also updated post-pve-install to hide the subscription nag in the mobile UI in every UI language.

How to update a helper script container safely

Take a snapshot first. On storage that supports snapshots (ZFS, LVM-thin, Ceph), from the Proxmox host shell:

pct snapshot 105 pre-update

If your storage cannot snapshot, run a backup to Proxmox Backup Server or a vzdump target first. The Proxmox backup strategy for 2026 covers both.

Then check the container's OS, so you know whether a Debian 13 requirement applies:

pct exec 105 -- cat /etc/os-release

Read the script before you run it. Each script page on community-scripts.org links to its source, and the README says plainly that the commands run as root on your host. The update logic sits in the update_script function of the app's file under ct/ in the repository. Our earlier posts on the hidden risks of helper scripts and what a single curl command can do go deeper on this.

Then run the update from inside the container. Open the container's console in the Proxmox web UI, or enter it from the host, and type update:

pct enter 105
update

The README says every container gets this command and that it updates the installed application. VM scripts have no built-in updater, so update a VM through the guest's own package manager.

If the app breaks, roll back and wait for the next daily release:

pct rollback 105 pre-update

Delete the snapshot once the app has run cleanly for a few days, since snapshots on LVM-thin and ZFS keep consuming space.

Should you update this week?

For most containers, yes, after a snapshot. The closed console fix alone removes a common way to end up with a half built container. Wait or read the pull request first if you run Hermes Agent, tubearchivist, Open WebUI or Ollama on Intel GPUs, or an app with your own npm additions on top of Node.js.