monero.loveA little love for the network.
← All guides

Privacy

Your Whonix Updates Finished. Is Your Monero Wallet Updated Too?

Check Whonix Gateway, Workstation, Qubes templates, and separately installed Monero wallets. Learn which updater applies and where each command runs.

Separate wallet and Tor gateway computers beside a package-update symbol on cream paper

A successful Whonix system update does not prove that a separately downloaded Monero wallet is current. The Gateway, Workstation, wallet application, and host computer can each have a different update path. On Qubes, templates and the App Qubes based on them add another distinction.

The practical check is to identify where each component is installed, update it through the appropriate mechanism, restart what needs restarting, and inspect the version you run. Checking only the most recent updater window leaves gaps.

We reviewed the official documentation on November 8, 2026. The Whonix project announced non-Qubes 18.2.4.3 on November 6. That image release number is not proof that every package or downloaded wallet in an existing installation is current. Whonix release announcement.

We have not executed these updates in a Whonix or Qubes installation for this article. Check current advisories before using the steps, particularly the Qubes-specific APT notice below.

Identify what you are updating

Component Its role Where to check for updates
Whonix Gateway Provides the Tor network connection for the Workstation Its own system updater, or its Qubes template through Qubes Update
Whonix Workstation Runs the user's applications Its system updater, or its Qubes template through Qubes Update
Qubes App Qube Uses its template's system while retaining its own private data Restart after template updates, then check software stored privately
Downloaded Monero wallet Runs from a downloaded archive, AppImage, or another separate installation The wallet project's release and verification process
Host and virtualization software Run the virtual machines The host platform's supported update process

For background on the Gateway and Workstation relationship, see our beginner's operating-system comparison. Keep ordinary wallet use in the Workstation. The Gateway's job does not require your wallet seed or wallet files.

Non-Qubes Whonix: update both virtual machines

For ordinary non-Qubes Whonix installations, the official command reference lists upgrade-nonroot for operating-system updates. Run it in a terminal inside Whonix-Gateway, and separately inside Whonix-Workstation:

Shell
upgrade-nonroot

Read the results in each machine. Check for failed downloads and package errors, including any update you declined. Resolve errors before treating the machine as current.

Follow any restart instructions. Restarting the Gateway interrupts the Workstation's network path, so save work and plan that interruption. After both systems are ready, run the documented health check inside each Whonix VM:

Shell
systemcheck

To inspect the Whonix version reported by either VM, run this inside that VM:

Shell
cat /etc/whonix_version

This reports Whonix's version information. It does not inspect the version of an unrelated AppImage in your home directory. Keep a note of which VM you checked rather than treating the Gateway's result as the Workstation's result.

Update the host operating system and virtualization software through their own supported tools. An updated guest cannot repair an unpatched or compromised host.

Qubes-Whonix: use Qubes Update

On Qubes, update the Whonix Gateway and Workstation templates through the Qubes Update tool. Do not apply the non-Qubes command block above inside an ordinary App Qube and assume that its template has changed.

Qubes has a current security-specific requirement. QSB-122 instructs users to use Qubes Update, which handles update ordering. For command-line users, dom0 must be updated by itself first. Only after that succeeds should Debian and Whonix templates and standalones be updated through qubes-vm-update. The bulletin says not to substitute direct apt commands.

The required dom0 packages named in the bulletin are qubes-core-dom0-linux 4.3.25 and qubes-mgmt-salt-dom0-update 4.3.4. At this review, the bulletin describes migration from security-testing to stable over two weeks. We have not established availability in your configured repositories. If the updater offers nothing, check the installed package versions against the bulletin before assuming the fixes are present.

Prefer the graphical Qubes Update workflow and consult the bulletin if the fixed packages are unavailable. Do not enable testing repositories just to make a command in this guide succeed. Our Qubes and Whonix APT advisory coverage provides the security context.

For readers already using the command line, the ordinary Qubes sequence is in a dom0 terminal, first:

Shell
sudo qubes-dom0-update

The dom0 updater requires root privileges in console mode, so this example uses sudo.

Wait for successful completion and verify the bulletin's requirements before proceeding. Then, still in dom0, the documented command to update all updatable templates is:

Shell
qubes-vm-update -T

-T selects templates. It is not a claim that every standalone has been updated. Include Debian or Whonix standalones in Qubes Update separately if you have them. The Qubes update guide documents this distinction and links the command's options.

After updating, shut down the templates and restart the dependent Gateway and Workstation qubes. Save work first. A running App Qube does not automatically replace its system files just because its template finished updating. For gateway qubes, account for the dependent qubes that use their network connection.

Locate the wallet that your launcher opens

Inside the Workstation or wallet App Qube, inspect the wallet's About or version display. Check its launcher target or the location from which you start it. A new download and an old launcher can coexist.

If you deliberately use the CLI, in the directory containing that wallet executable:

Shell
./monero-wallet-cli --version

This reads that file's version. It does not search for every other wallet copy on the system. The stable Monero CLI release checked for this article was v0.18.5.4. Check the official release channel for the product you run. GUI, CLI, Feather, and other wallets have distinct release histories.

A wallet installed as a system package is maintained through the repository and package mechanism that supplied it. A manually extracted Monero archive or Feather AppImage is not replaced merely because APT finished. Feather also documents a Flatpak installation, which has its own update mechanism. Identify the format instead of guessing from the application's name. Feather's Linux installation options.

In Qubes, software stored in an App Qube's private home directory can persist across restarts independently of the template. A template update can leave that private wallet installation unchanged. The Qubes template model explains which system files are inherited.

Gateway updates, Workstation updates, and a separately downloaded wallet each have their own checks, with dependent Qubes App Qubes restarted after template updates

Update a separately installed wallet deliberately

Close the wallet and back up the data and recovery information it requires before replacing software. Keep seeds and private keys offline. Do not copy them into a shared template, the Gateway, or a support ticket.

For official Monero downloads, verify the signed hash list and the selected archive using the Monero download-verification instructions. A matching hash without authenticating the signed list does not provide the same assurance.

For Feather, use its own download page and Linux signature instructions. Match the signature to the exact file you downloaded, and check the signing-key fingerprint through the project's documented channels. Our PGP signature guide explains the underlying checks.

Install or extract the verified application in the intended environment, then check that the launcher opens it. Keep the wallet's data path consistent and verify the running version afterward. Do not delete the old data directory just because the new program opens successfully.

If you maintain several Workstations or wallet App Qubes, check each private installation. Updating a copy in one home directory does not update a different copy in another qube.

Check operation after the updates

Confirm that the Gateway passes its relevant checks, the Workstation has connectivity through the intended Gateway, and the wallet opens the expected file. Check its address and node settings before interpreting a balance or synchronization problem.

Wallet synchronization is not a software update. A fully synchronized old wallet is still old software. A newly installed wallet can need time to scan before displaying its current balance. Our wallet connection guide explains the role of the daemon connection.

Check release notes for wallet-specific migration instructions. If something fails, keep the existing files and record the version and exact error. Do not send a wallet seed or key file to someone offering to diagnose it.

Do not turn an update into an experimental isolation migration

Whonix's separate Monero wallet-isolation guide explicitly warns that it is for testers. Its custom arrangement separates wallet and daemon qubes through Qubes RPC. It is not a prerequisite for routine updates and is not presented here as the normal supported wallet setup.

Keep architecture changes separate from maintenance so that failures are easier to diagnose. If your system also uses Fedora templates, the Fedora 43 to 44 migration guide covers that different task. For a wallet on removable Tails media, use the Tails USB and wallet backup guide.

Support Monero Love

Help keep the public nodes and packages running. Send any amount of XMR.

Scan with a Monero wallet to donate to Monero Love.89hGTKxRVA3AUeKAbCRBt5TMSzq3MQZooNNsezCpNFjp2oeJPRx8AJeGKA8ziHZNqab78f4Vr1ntxhPDxX5298nnGZjHkhm