Before you start: one workspace for the night
Save a workspace with what you'll need open: the hypervisor's web interface, a terminal on each host, and their dashboards. On the Connections page, tabs sit side by side in up to eight panes, and Open and connect all brings the whole layout back next time. The split view and workspaces help has the shortcuts. Saving a layout like this is one of the 5 workflows that save time when you manage many servers.
If your hosts aren't saved yet, the guide to managing Proxmox, VMware and KVM hosts walks through adding them, with groups per cluster and tags like prod and backup. For the bigger picture of how terminals, web panels and VNC consoles share one list, see one app for your whole homelab.
1. Look before you touch anything
Open each host's Dashboard: live CPU, memory, load, disks, network and the busiest processes, read over SSH without installing anything. A host that's already struggling is a host to leave until last, or to look at first.
- Any disk the dashboard flags as almost full (it warns from 90%)? Note it for step 4.
- A process using far more CPU or memory than usual? Find out why before an update restarts it.
- On Docker or Podman hosts, open Containers and check nothing is stuck restarting.
Which hosts
2. Make sure the backups are real
Updates are when you find out whether last week's backup works, so check it before, not after. Look for the newest backup files on each host (on Proxmox VE, the default dump folder is /var/lib/vz/dump), then copy them somewhere that isn't the same box.
A transfer tab copies from one saved host straight to another, streaming through your PC with nothing saved on your disk. Turn on Verify and each copy is checked against the original with SHA-256 checksums, where both sides have sha256sum. See copying files between two servers.
3. Have a console ready before you reboot
The moment to find out you can't reach a machine's console is not after it fails to come back. Before rebooting anything, check you have a way in that doesn't depend on its network:
- KVM guests: a VNC host for the VM's display, through an SSH tunnel to the KVM server. See reaching KVM and QEMU VM consoles.
- Proxmox VE and ESXi guests: the console in the platform's web interface, open in a web panel tab.
- A firewall or switch with a serial port: a serial console, on this PC or on one of your PCs it's plugged into. See reaching pfSense, OPNsense and router admin safely.
4. Updates, one host at a time
Save an update script in the terminal's Scripts & History panel and send it with Run on hosts…. You get each host's output and result in one list, and anything that failed can be run again on its own. On Debian-based hosts, Proxmox VE included, a check might be:
apt update apt list --upgradable
Checking can go out to every host at once. Installing and rebooting is different: in a cluster, do one node at a time, move or shut down its guests first, and wait for it to come back healthy before the next. Run on hosts lets you tick exactly the hosts you mean, so tick one. The Proxmox VE guide has examples with qm and pct; ESXi and Hyper-V have their own update routes, covered in the ESXi and Hyper-V guides.
5. Containers
On each Docker or Podman host, Containers lists what's running with its image, state and ports. Restart one, follow its log to see it come up, or open a shell inside it in a new terminal tab. Pulling new images is still a job for your usual commands or compose files in the terminal. More in managing Docker and Podman hosts.
6. Free up space
Back to the disks you noted in step 1. Old backups that are now safely copied elsewhere, ISOs you no longer install from and container images nothing uses are the usual suspects. The SFTP file browser shows folders side by side with your PC, if you'd rather look than type.
7. Check the boxes with only a web page
Firewalls and NAS systems mostly want their own web interface for updates and health checks. Save each as a web panel and they open in tabs next to everything else, with Fill sign-in for the saved user name and password. See the TrueNAS, Unraid and NAS guide.
What stays manual
RemoteAccessApp doesn't connect to the hypervisors' APIs, and there are no buttons to migrate, snapshot or shut down VMs. Do those in the platform's web interface, now in a tab, or with its own commands in a terminal. What the app saves you is the hunting: the consoles, terminals, dashboards and copies for the whole night are in one window. The free homelab management tool page lists what the app does cover for a lab's servers, VMs and PCs, and there are more checklists and homelab posts on the RemoteAccessApp blog.