The Proxmox web interface is genuinely good, which is a problem, because it is good enough that you can run a cluster for a year and never learn that a second, more capable interface sits underneath it. The two command-line tools, one for containers and one for virtual machines, do everything the web UI does and a set of things it does not expose at all. The gap between them is where a lot of "you cannot do that in Proxmox" beliefs actually live.
Several things became possible the day I stopped treating the CLI as a door marked advanced users only.
Batch operations the UI makes you do one click at a time
The web UI is built around one guest at a time: select it, act on it, repeat. When you need to do the same thing to fifteen containers, that is fifteen rounds of the same clicks, and by the tenth you will make a mistake.
The command line takes a list. Restarting or reconfiguring a whole group of guests is a single loop, and a loop does not get bored on the fourteenth item. Anything you would dread doing by hand across many guests, the CLI turns into one line you can read, check, and then run once.
Configuration keys the UI never surfaces
Every guest's real configuration is a plain text file, and the CLI reads and writes it directly. The web UI shows the common subset of settings; it does not show all of them. There are behaviors, boot and startup ordering, specific device and passthrough options, particular flags, that exist as configuration keys but have no checkbox anywhere in the interface.
If you have ever read a forum answer that says "add this line to the guest config" and wondered why the setting was not in the UI, this is why. The setting was always there. The UI simply curates which settings it presents, and the CLI is the uncurated view.
Scripting, which changes what a homelab even is
This is the real unlock. A tool that takes a list and reads and writes plain text is a tool you can put in a script. Once guest management is scriptable, a class of things becomes possible that a point-and-click interface structurally cannot offer: create-from-template flows tuned exactly to your setup, scheduled maintenance actions, reproducible builds where the definition of a guest lives in a file in a git repository rather than in a series of clicks nobody wrote down.
That last shift is the important one. Clicking through the UI produces a running guest and no record of how you made it. A script produces the same guest and is itself the record. The difference shows up the day you have to rebuild, and it is the difference between remembering and re-deriving.
When to use which, honestly
None of this means abandon the web UI. For looking at things, the console, the graphs, the current state of the cluster, the UI is faster and better, and I use it constantly. For a one-off change to a single guest, clicking is genuinely quicker than typing.
The CLI earns its place the moment the work is repetitive, the moment the setting you need is not on screen, and the moment you want the action to be something you can save, review, and run again. Those three moments are exactly where the UI stops helping and, if you do not know the CLI exists, exactly where you conclude the platform cannot do the thing.
It can. It just does not always advertise it. Once you know the command line is there, the list of things you believe Proxmox cannot do gets a lot shorter.
Top comments (0)