Patching an ESXi host from the shell is not a shortcut. It is an exception path — the thing you reach for when a host sits outside the happy path: a standalone box with no vCenter, an isolated site, or a day when your lifecycle tooling simply refuses to cooperate.
The difference between casual SSH patching and a professional one is not the commands you type. It’s the evidence you collect around them. Anyone can esxcli software profile update and reboot. The controlled workflow is what lets you prove — afterwards — that you knew the state going in, you had a rollback, and you validated the state coming out.
There is no magic in the shell. There is only the difference between “I ran a patch” and “I ran a controlled exception, with evidence.”
Try it yourself — the ESXi patch simulator
Below is a safe, simulated ESXi shell. Nothing here touches a real host — it is a sandbox that walks the full ten-step workflow. Type the commands yourself, or use the buttons. The checklist lights up as you complete the workflow in the correct order.
Patching LAB! Test it now
Patch ESXi without guesswork. Route it. Dry-run it. Prove it.
▶ Launch the ESXi Patching Lab
The two commands people get wrong
The single most important choice is profile update vs profile install. Update applies newer content and ignores lower-revision content — it is the recommended method for patching. Install overwrites existing packages and can silently downgrade VIBs. Use install only when you know exactly why you need it.
Starting with ESXi 8.0 Update 2, upgrading via
esxcli software vib updateorvib installis no longer supported. Use the profile method.
The takeaway
CLI patching is strong for standalone hosts and isolated sites, poor for routine workload-domain patching (let vLCM / SDDC Manager own that), and risky when the image state is unclear. Whatever the reason you are in the shell: check the state, keep a backup, dry-run, update, reboot, validate, and write down the drift. That last step is what turns a risky SSH session into a controlled exception.