Proxmox LXC update monitoring self-hosted is the missing half of homelab update hygiene. You probably already watch your Docker images for new releases — but the Debian packages inside your LXC containers drift just as fast, and nothing tells you when a security patch is waiting. Stashboard closes that gap: it counts pending apt updates inside each container, shows the number right on the card, and lets you apply them with one click. This guide walks through exactly how Proxmox LXC update monitoring self-hosted works under the hood (V6.0, V6.7, V6.7.1), the API token and SSH it needs, and the safety gates around the one-click upgrade.
New here? Start with the Stashboard self-hosted homelab dashboard overview, and the full Proxmox surface is covered in the manage Proxmox from a web dashboard pillar guide. 🧩
How Proxmox LXC update monitoring self-hosted works
Each scan does two different things for two different targets. For the node itself, Stashboard reads the pending-update count straight from the Proxmox REST API — no shell required. For each running LXC, it opens a short-lived SSH session to the host and runs pct exec to count upgradable packages inside the container:
pct exec <vmid> -- sh -c 'apt list --upgradable 2>/dev/null | grep -c upgradable'That number is the pending-update count you see on the card. A stopped container is skipped — there is nothing to exec into — and so is one with monitoring turned off. Crucially, this is package-level, not image-level: Proxmox LXC update monitoring self-hosted asks each guest’s own apt database “how many packages can you upgrade right now?” — the same question you would answer by hand with apt over SSH.
Connection prerequisites: API token plus SSH
Proxmox LXC update monitoring self-hosted connects a node with two credentials, and they do different jobs:
- Proxmox API token — the recommended credential of the form
user@realm!tokenid=secret. It drives all read-only discovery: listing LXCs, reading the node’s own pending-update count, and looking up each container’s IP. A read-only role is plenty here. - SSH (host, username, private key) — required for the per-container counts and for one-click Update now, because both run
pct execon the host. Without SSH the node count still works over the API, but every LXC card shows “SSH is not configured — per-container update counts require SSH access to the Proxmox host.”
⚠️ The SSH user must be able to run pct exec on the PVE host — effectively root-level on the node. Treat that private key like a root key: store it carefully and scope it to a host you trust.
Per-LXC monitoring toggle and maintenance snooze
Not every container should be watched. A deliberately pinned appliance, or one you know has no apt, only creates noise. Since V6.7, monitoring is a per-LXC toggle: flip it off and the container still appears as a card with live resource detail, but its update count is no longer computed — Stashboard skips the IP lookup and the SSH pct exec entirely, exactly the way a disabled Docker watch is left unchecked.
V6.11 adds a maintenance snooze for the in-between case — a container you still want monitored, just not right now. Snooze it for 1h, 6h, 24h, or 7d and it is skipped by both scheduled and manual checks for that window, then re-included automatically when the window passes. Monitoring stays on; you are simply muting the guest while you work on it, and you can clear the snooze early at any time.
The pending-update badge on the card
Once a scan finishes, each linked service shows an aggregated update badge — the same badge component the Docker side uses, so a host with packages waiting reads identically whether those updates live in a container image or inside an LXC. The states are the familiar ones: up to date, update available, error, or disabled. Drill into the per-container card and you see the raw count of upgradable packages, the last-checked time, and — when something went wrong — the verbatim error instead of a misleading zero. This shared visual language is what makes Proxmox LXC update monitoring self-hosted feel like part of the dashboard rather than a bolt-on.
One-click Update now: what it runs, gating, and audit
When updates are waiting, Update now applies them in place. Behind the click, Stashboard SSHes to the host and runs, for an LXC:
pct exec <vmid> -- sh -c 'apt-get update && \
apt-get -y -o Dpkg::Options::=--force-confold -o Dpkg::Use-Pty=0 dist-upgrade'On the node itself it runs the same apt-get line directly. It is fully non-interactive — DEBIAN_FRONTEND=noninteractive, and --force-confold keeps your existing config files on any prompt — and the combined output streams back to the browser line by line as it runs. A non-apt target short-circuits with a distinct exit code, so you get “Not a Debian/apt-based target — nothing to upgrade” rather than a hang. You can even preview the exact command first: a read-only endpoint surfaces it so the confirm dialog can show and copy it, the way the Docker “Update command” panel does.
Applying updates is privileged, so it is triple-gated and fails closed — none of these is on out of the box:
- A server-wide master switch — Settings → Proxmox updates, off by default.
- A per-host opt-in — “Allow apply updates” on the individual Proxmox connection.
- SSH configured on that connection.
⚠️ If any gate is off, Stashboard returns a deterministic refusal before it ever touches the host — the action fails closed, never half-done. And nothing is silent: every run is audited. Each target gets its own session row — who started it, the host and node, the target, start time, exit status, bytes streamed, and the end reason or verbatim error — surfaced on the Audit page. A bulk “Update all” across many guests records one row per guest, exactly as if you had updated each individually. On success, the pending count is re-read immediately so the badge drops on its own.
Proxmox LXC update monitoring self-hosted vs Docker update monitoring
If you have read the Docker update monitoring guide, the mental model is similar but the mechanism is completely different. Docker monitoring compares the SHA-256 digest of a running container image against the registry manifest — it asks “is there a newer image?” Proxmox LXC update monitoring self-hosted instead counts apt-upgradable packages inside a long-lived guest — it asks “are the packages in this OS out of date?”
That difference carries through to the fix. Docker’s one-click update pulls a new image and recreates the container — the container is replaced. The Proxmox one-click upgrade runs apt-get dist-upgrade in place — the container keeps its identity, snapshots, and config; only its packages move forward. And where Docker reaches the daemon over a socket or SSH tunnel, the Proxmox side always needs an API token (discovery) plus SSH (the apt work). One more boundary worth knowing: this is LXC-only. QEMU/KVM virtual machines are discovered and shown as cards, but they carry no pending-update count — a VM is not necessarily Debian and may have no SSH, so apt-style monitoring does not apply.
How to verify Proxmox LXC update monitoring self-hosted is working
- Test connection on the connection form runs the API and SSH checks independently, so you instantly know which credential is the problem rather than guessing.
- After a scan, a monitored, running, Debian LXC should show a number — even
0. If it shows the “SSH is not configured” message, add SSH; if it shows “Not a Debian/apt-based container”, that guest simply has no apt (see below). - Cross-check by hand: SSH to the PVE host and run
pct exec <vmid> -- apt list --upgradable. The count should match the card. - After Update now, the badge and count drop automatically (the count is re-read on success — no manual Check now needed) and a new row appears on the Audit page with the exit status.
⚠️ Risks and edge cases
- A container with no apt. Alpine, or any non-Debian template, has no
apt-get. Proxmox LXC update monitoring self-hosted detects this and reports “Not a Debian/apt-based container” instead of a fake zero, and Update now exits cleanly with “nothing to upgrade”. It is harmless — just turn monitoring off for that guest to keep the dashboard tidy. - SSH access is the whole dependency. No SSH means no per-LXC counts and no one-click upgrade — only the node’s API-based count survives. And because the SSH user runs
pct exec, it holds real power over the host; scope and protect that key accordingly. - dist-upgrade is a real upgrade. It can restart services inside the container and pull in significant package changes.
--force-confoldprotects your config files, but test on a non-critical container first. A generous 20-minute command ceiling lets large upgrades finish instead of being cut off mid-flight.
Bottom line
Proxmox LXC update monitoring self-hosted turns “I should really SSH in and check apt on all my containers” into a number on a card and a button. Connect a node with an API token and SSH, toggle monitoring on the containers you care about, snooze the ones under maintenance, and apply waiting updates with one audited, triple-gated click. For the full picture of everything the Proxmox surface can do, read the Proxmox web dashboard pillar guide; for the disk-health side of those same LXCs, pair it with Scrutiny SMART monitoring on a Proxmox LXC. 🚀
Stashboard is open source — you can find the full source code on GitHub and pull the ready-to-run image directly from Docker Hub. Issues, PRs, and stars are always welcome. 🙌