There has never been a clean way to manage Proxmox from web dashboard self-hosted without juggling three tools at once — the Proxmox VE web UI for guests, an SSH session for the shell, and a separate app for update monitoring. Stashboard collapses all of that into one page. This is the pillar guide to everything you can do when you manage Proxmox from web dashboard self-hosted with Stashboard, from connecting a node to cloning a VM, and it links out to the deeper how-tos for each piece. New here? Start with the Stashboard self-hosted homelab dashboard overview.
Across releases V6.0 through V8.6, Stashboard grew a full Proxmox surface that sits right next to its Docker tooling — so the same dashboard you already use for containers also drives your LXC containers and QEMU virtual machines. In short, it is one place to manage Proxmox from web dashboard self-hosted. 🧩
Why manage Proxmox from web dashboard self-hosted
The Proxmox VE interface is powerful, but it is also heavy and built for the admin who lives inside it. Most of the time you just want to see whether a guest is running, apply a pending update, glance at CPU and memory, or pop a quick shell. When you manage Proxmox from web dashboard self-hosted with Stashboard, you get exactly that: Docker-style cards, one-click actions, and an in-browser console — without exposing the full Proxmox admin UI to every device on your network. It also means one dashboard for your whole homelab, with Docker hosts and Proxmox nodes side by side, mirroring the same patterns from the visual Docker Compose editor on the container side.
Connect a Proxmox host: API token plus optional SSH
Everything starts with a connection. You add a Proxmox node by its host URL and a Proxmox API token — the recommended credential of the form user@realm!tokenid=secret. The token alone is enough for all read-only discovery: listing guests, reading config, polling stats and tasks. That is the safe baseline to manage Proxmox from web dashboard self-hosted — nothing can be changed yet.
Adding optional SSH credentials to the same connection unlocks the two things the API token can’t do on its own: the in-browser LXC console (which runs pct exec over SSH) and the deeper node telemetry collectors that read load, ZFS, and disk health straight from the host. SSH is opt-in — skip it and you simply don’t see those features. ⚠️ Give the API token only the privileges you actually need; a read-only role is plenty until you decide to enable the mutating actions described below.
LXC and VM guests as Docker-style cards
Once a node is connected, Stashboard discovers every LXC container and every QEMU/KVM virtual machine on it and renders each as a card — the same card language used on the Docker page. A coloured state badge tells you running, stopped, or paused at a glance; the card shows the guest’s name, VMID, node, and a quick resource summary. Click a card and a per-guest modal opens with tabs for everything else. This Docker-parity layout is deliberate: if you already manage Proxmox from web dashboard self-hosted alongside Docker, there is nothing new to learn.
Per-guest update monitoring and one-click update
This is the feature that started the whole Proxmox track — and still the most common reason people manage Proxmox from web dashboard self-hosted. Stashboard checks each guest for pending package updates and surfaces a count right on its card, just like it does for container images. You toggle monitoring per guest, so noisy or deliberately-pinned containers stay quiet. When updates are waiting, a one-click Update now applies them inside the guest, and a bulk action does it across many guests at once — each attempt recorded in an audit trail.
If this sounds familiar, it should: it is the Proxmox sibling of the Docker features covered in the Docker update monitoring guide and the one-click container update post. Applying updates is a mutating action, so it is gated — see the safety model at the end.
Lifecycle, stats, tasks, and logs
The per-guest modal is where you actually manage Proxmox from web dashboard self-hosted — it turns the dashboard into a real control surface:
- Lifecycle — start, stop, shutdown, and reboot a guest from an action row, with confirmations on the destructive ones.
- Stats — live, per-second CPU, memory, network, and disk I/O graphs while the guest is running.
- Tasks — the node’s recent task history (each Proxmox task UPID), so you can see what ran and whether it succeeded.
- Logs — a live log stream for the guest, tailing without an SSH session.
Edit guest config and network
Reading config is good; editing it without dropping to the shell is better. A Config tab shows the guest’s parameters, and you can edit the ones that matter — cores, memory, the description, boot options — through real form fields. For LXC containers you can also edit network interfaces and mount points, and for QEMU virtual machines Stashboard exposes the VM’s parameters the same way. Each change is sent to the Proxmox API and reflected back on the card, so editing config is part of how you genuinely manage Proxmox from web dashboard self-hosted rather than just watch it.
Browser console: LXC over SSH and VM over noVNC
Two kinds of guest need two kinds of console, and Stashboard ships both in the browser. For an LXC container, the Console tab opens an interactive PTY that runs pct exec over your SSH connection — a real shell inside the container, no terminal app required. For a QEMU virtual machine, the console is a full graphical noVNC session that relays the VM’s VNC display straight to your browser, so you can reach the BIOS, a boot menu, or a desktop login. Both consoles are ticket-authenticated and short-lived, and every session is written to a console audit trail. Together they let you manage Proxmox from web dashboard self-hosted right down to a root shell or a VM display.
Create, destroy, clone, snapshot, and restore — for both guest kinds
The full provisioning lifecycle is covered, symmetrically, for LXC containers and QEMU virtual machines:
- Create — a new LXC from a template, or a new VM from scratch, with the VMID defaulted from the cluster’s next free id.
- Destroy — remove a guest, guarded behind a stopped-guest check and an explicit double-confirm that names the target.
- Clone & snapshot — full or linked clones, plus a Snapshots tab to create, roll back, and delete snapshots.
- Restore — re-create a guest from a
vzdumpbackup archive; restoring over an existing VMID requires the target to be stopped and a second confirmation.
Each of these is a long-running Proxmox task; Stashboard polls the task UPID to completion, then re-scans the node so the new or changed card appears on its own. A host rejection is surfaced verbatim instead of being swallowed. Provisioning is the most powerful way to manage Proxmox from web dashboard self-hosted, which is exactly why it sits behind the gates below.
PVE and PBS node health with alerting
Guests are only half the story — the node underneath them matters too. A node health card summarises each PVE node’s CPU, memory, storage, and uptime, and a node modal goes deeper with telemetry the SSH collectors gather (load average, ZFS pool state, disk SMART). Proxmox Backup Server nodes are covered as well, including datastore usage and disk health. On my own main server — a Xeon E5-2650L v4 with 64 GB of RAM — this is the panel I glance at first. Crucially, node health is wired into alerting, so a node going unreachable or crossing a threshold notifies you instead of waiting to be discovered. If you like this kind of disk-level visibility, pair it with Scrutiny SMART monitoring on a Proxmox LXC. Healthy nodes are the foundation that lets you safely manage Proxmox from web dashboard self-hosted.
The safety model behind manage Proxmox from web dashboard self-hosted
Here is the part that makes it responsible to manage Proxmox from web dashboard self-hosted at all. Every single mutating action is double-gated, and both gates are OFF by default:
- A server-wide master switch in Settings — a separate toggle per capability (update, console, create, destroy, clone/snapshot, restore). Until you flip it, that capability simply does not exist for anyone.
- A per-host opt-in on the individual Proxmox connection — so enabling, say, destroy globally still doesn’t let you destroy on a host you haven’t explicitly trusted for it.
⚠️ Both gates must be on before a mutating call is even attempted. If either is off, Stashboard returns a deterministic refusal before it ever touches the Proxmox API — the action fails closed, never half-done. Out of the box, then, a fresh connection is strictly read-only: you can watch, graph, and inspect, but nothing can change until you deliberately turn it on.
And nothing is silent. Every action that reaches a host — an update, a console session, a clone, a destroy, a restore — writes an audit row (who, when, which host and node, which guest, the action, and success or the verbatim error) surfaced on the Audit page. So when you manage Proxmox from web dashboard self-hosted, you always have a “who changed what, when” trail to fall back on.
Bottom line
From V6.0 to V8.6, Stashboard turned Proxmox into a first-class citizen of the dashboard. You can manage Proxmox from web dashboard self-hosted end to end: connect a node with an API token (plus optional SSH), see LXC and VM guests as cards, monitor and one-click update them, drive lifecycle, read stats, tasks, and logs, edit config and network, open an LXC shell or a VM noVNC console, and create, destroy, clone, snapshot, or restore either kind of guest — all on top of PVE and PBS node health with alerting, and all behind a double-gated, audited safety model. Connect a node and try it. 🚀
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. 🙌