Installing Software in Qubes (all methods)

:placard: Navigating the Waters: Installing Software in Qubes

Installing software in Qubes OS can be a daunting experience. This guide’s goal is to serve as a crossroad sign to help you navigate this landscape.

(image credit: @deeplow, via public domain, original from pixabay)

Installing in Template qube

A template qube is like a boilerplace for app qubes based on it. When you install a piece of software on it all qubes based on the template will also get that piece of software.

When you install it like this, you get updates via routine updates (normal way of updating).

other methods (advanced)

:warning: This is for advanced users only. Updates are manual.

Using the updates proxy to give software management programs internet access in the template.

In case this software installs stuff in non-persistent directories you’ll need to use bind-dirs those directories persist when starting an app qube based on the template.

Examples of what can be achieved with this

Installing in App qube

App qubes are your regular qubes (e.g. personal or work qubes). If you install like this the application will only be available in that app qube where you installed it.

  • When the software is available as a “snap package” (search availability here)
    Read more at Installing Snap Packages (official documentation). Updates should be done automatically but you should double-check this.

  • When the software is available as a “flatpack package” (search availability here).
    Qube Apps - developed by Micah Lee, a trusted community member.

    :warning: Updates are manual but just one-click.

  • When an AppImage is available. Just download the AppImage and follow the installation instructions.

    :warning: Updates are manual and tiresome. It’s basically repeating the whole install process! Plus, you’ll have to figure out a way to know when there are updates. This bad security practice means it will probably be outdated for a long time.

Other methods (advanced)

TODO usermode dnf / deb packages.

Installing in a dedicated qube (standalone qube)

Standalone qubes are dedicated qubes. They are good if you want to install random software that you don’t trust to be installed on your main templates and only really need to use in a single qube.

It’s very flexible. The only downside really is it occupies a lot of space (like regular templates) but none of the advantages of splitting that space among app qubes.

Regardless, the security isolation and flexibility may make this a way to go for very particular pieces of software.

10 Likes

I’m sure there are other ways of installing software in Qubes OS installing from source and other advanced stuff. My goal here was to try to get at least one solution for the way each software is packaged.

But if there are more suggestions, do send them and I might include them.

@adw if you want / feel this fits into the official docs, do let me know. Maybe a link to this?

1 Like

Yes, you can.
You can create them as class Template, and then use them to create
qubes, specifying them as template as normal.

If you have installed the OS to the first disk, then qubes using that
template will effectively be disposables.
You can make them behave like normal qubes by manipulating /etc/fstab
(or equivalent) to store user data on the second disk, which is not
cleared on reboot.

I never presume to speak for the Qubes team.


When I comment in the Forum or in the mailing lists I speak for myself.

1 Like

Ah. Nice! Always learning :slight_smile:

I think I’ll keep the explanation, sacrificing technical accuracy for clarity. But it’s good to know that! Thanks!

Updated the standalone section to say one can also install like a template or an app qube.

2 posts were split to a new topic: Installing a browser extension like uBlock Origin for firefox so it is available in all appqubes based on a specific template

We have an “External” section for community documentation links like this. Please feel free to submit a PR:

In this case, you may also want to link from:

10 posts were split to a new topic: Curl / Wget-proxy scripts in Templates so users can add GPG distro keys linked to added external repositories

Does installing Zoom, MS Teams and Webex fit into any of these methods? I guess my question is about all the .deb and .rpm packages out there, that cannot be installed permanently in an App Qube.

Usually, I download the installation .deb or .rpm package, move it to the Template, and run sudo apt install .package or sudo dpkg -i install .package or for Fedora sudo dnf install .package in the template.

This would of course require manual update of the package (download new version, move to template, and re-install).

Is there a better way to do this?

I use a StandaloneVM for Zoom, together with a custom update script.

More generally, I consider such software to be untrusted, so I don’t want to put it in any of my existing TemplateVMs, and having a TemplateVM with only one AppVM based on it is somewhat pointless.

What makes you say that? (not looking for an argument, just curious to understand your thinking)

I was thinking that was the whole point: light-one-app-appVM instead of booting up whole system for one app…
Curious too to hear, always looking forward to broaden perspectives.

@enmus @Sven @Demi

My global advice to customers on how to deal with untrusted, invasive proprietary software is always tosegregate them for install, and audit what results from install in a seperate template prior of merging those software into a template that is used for more trusted operations.

I like to seperate for example debian-10 from debian-10-proprietary, where proprietary would be an initial clone of debian-10 + proprietary related repositories.

I tend to agree with @Demi on randomly released .deb and .rpm that are not part of a repository and consequently doesn’t update itself: better to put that on a standalone qube, which is less then desirable approach, but at least undesirable outcome would only touch that qube, even more if only one qube relies on that template qube.

The general idea on this falls into the same category as deploying printer related software in a broadly used template: not a generally good idea because of the added attack surface. We all know that printers drivers are iffy, that additional services (systemd) are added at boot,etc. Whatever extends the attack surface needs to be carefully chosen and audited to be running by default on qubes on which that template depends, and should be a no go. It is better to fit a light-one-app-appVM where needed, depending on threat model and use cases, once again. I would personally not trust Zoom or any proprietary tools to stand side by side of carefully curated software installed on template shared with mission critical qubes i’m using.

I personally prefer to clone a known good template (debian-11) to a general persona-related template (debian-11-communication-proprietary), install software in the latter and then compare the filesystem to see exactly what happened there prior of taking a decision on if I keep that template distinct of others for one/two AppVMs. If no additional start-up services are installed, I might reconsider having it installed in a standalone qube, or sharing a template with other proprietary software. If that thing is not updated automatically, it definitely goes into a standalone, short-lived template-turned-into-standalone for hte time being I need that app where all my being is saying no, but others want me to use that app, so be it really ephemerally. Cloning on thin-lvm is no cost. Installing software there has space consumed for the diff of the installed software. As long as I do not intend to keep it there forever, its more like a install, use it delete it use-case.

Once again, I’m a big advocate of wyng-backups for that, which permits to just send the diff (–dedup is your friend) between debian-11 and debian-11-communication-proprietary to a local backup, including the qube that depends on it. If I do not use either the qube or the template, I make sure to have backuped the qubes.xml with accompanying wyng-backup/qubes-wyng-util at master · tasket/wyng-backup · GitHub tool, and if needed, I restore it a matter of minutes if I deleted it. No worries, small space consomption. Hallelujah.

1 Like

For me, if i will not using a dispvm based on this apps, then i will go to standalone. Just reducing the vm that I have.

2 posts were merged into an existing topic: Qubes Appreciation Mega-thread

My question

What makes you say that?

was in relation to @Demi’s

having a TemplateVM with only one AppVM based on it is somewhat pointless.

I tend to disagree. A standalone VM is kind of the least desirable solution and I always prefer the template based approach when at all possible / manageable. Also I don’t see why a 1 qube to 1 template relationship would be “somewhat pointless”.

Hence my question to understand, since @Demi has clearly a much deeper understanding then I do.

But increasing the total size of backups. You don’t need to backup templates as frequently, since they only contain updates. (Also not benefiting from the /home and /root separation.)

That’s not a problem for me. Well i think diff people have diff configuration, that’s why I only tell the preference.

I just don’t like seeing 30vm+ at qvm-ls / qubes-qube-manager.