Alpha release of QixOS - Qubes with Nix

nexus · July 17, 2026, 4:00pm

I’ve been working on a project I call QixOS and now I’m releasing the alpha for you to look at and give feedback on.
QixOS is an extension of QubesOS that you install on your already existing Qubes system.
Think of it as a set of tools which together make you able to configure your Qubes system using nix.

Why I built QixOS

I’ve been using Qubes for a long time and by now I couldn’t live without it. More recently I discovered NixOS and Nix and fell in love.
I think Nix and Qubes solve essentially orthogonal problems. Qubes gives us really tight security and a great UI for compartmentalization.
Nix gives us configuration-as-code and the benefits it brings and a great package repository.

Project structure

QixOS manages a subset of VMs on your system called nubes (nix qubes). They all run NixOS and are configured through the nix programming language.
The managing VM for the nubes is qixos-admin, a VM that has full control over all the VMs. It creates through the use of a dom0 qrexec policy.
qixos-admin has no access to any other VM except the ability to assign sys-net as a network VM for the nubes.

In QixOS you configure your VMs using .nix files of 2 different types. The ‘outer’ configuration files which declare which VMs should exist on your system, and the ‘inner’ configuration files which declare how the internals of a single VM should look.
The ‘outer’ configs use QixOS specific nix libraries while the ‘inner’ ones look essentially like a regular NixOS configuration and uses regular NixOS modules.

To apply an ‘outer’ to your system you use a tool called qixos-rebuild that is accessible in qixos-admin.

I won’t go too much into the internals of how QixOS makes all of this fit together, but if you’re technically interested in NixOS and QubesOS, I warmly encourage you to go read VISION.md and DESIGN.md.
The architecture and design decisions here is exactly the kind of thing I would love to get feedback on.

There are 2 results I’d like to highlight that comes from how QixOS is designed:

There is an increase in the security of templates due to a concept I’ve called space-time security
Each AppVM effortlessly gets to control its own root filesystem without needing to use /rw/ or bind-dirs. Read more

Alpha status

This is the alpha release. Only 2 people in the world have used this project before this point.
If you try to run QixOS expect a lot of bugs and expect things to change.
The code is dirty at the moment and will likely remain dirty for a while until we’ve solidified the architecture.
Also don’t use it for security critical stuff.

However if you’re interested in Nix+Qubes don’t let that stop you! Come join!

Installation

The installation can be done in 2 ways.
Either by running a script in dom0 or following a manual step-by-step guide.
The script and the guide mirror each other.

The installation process does not require that you install any new software inside of dom0.
The things it requires from dom0 is to first create a temporary policy which lets a temporary builder VM install a nixos template that it has built.
Then it requires a permanent policy that allows qixos-admin to create new VMs and gives it admin access to the VMs it creates.

You can go here to get started here: INSTALL.md.

Community

In the longer run as the project matures I’d love to see more community sharing through a community repository.
The vision is that 1 person can write a configuration for a nube (a nix qube) and many people can easily use it.
As the project matures I’m hoping we can build configurations for high value but hard to install qubes such as sys-gui, sys-audio, sys-vpn, etc.
A working split-ssh already exists in the community repo, which I use daily.

What I want from you - feedback

I want feedback on:

Is this an interesting project to you?
The architecture - I’ve made plenty of opinionated decisions about the architecture, do you disagree with any of them? Nix people especially welcome.
Vision for the project - I have tried to lay out what I want this project to grow into, what do you think about this? For example what do you think about a community of people building configurations and sharing them?
Would you use this? Will you use this now? Is there something that needs to be done before you start using it?
Misc - I’m interested in basically all types of feedback. If you have a thought then post it.

Get in contact

You can talk to me in this forum thread or on the codeberg issues or on the discord server.

Git repo: GitHub - originalposter/qixos: Qubes with Nix - the security and compartmentalization of QubesOS plus the configurability, shareability and packages of Nix · GitHub
Discord server: Discord

I know there are some people who are already interested in combining Qubes and Nix and I’d love to hear your input @solene, @evq.

I also looked around the forum for people that seem interested in nixos on qubes @eject_cosmos, @nokke, @otter2, @kalbasit, @skyvine, @arkenoi, @DanConwayDev, @Qball . Let me know what you think!
I built the foundations of QixOS on @evq’s NixOS template for Qubes so huge thanks to them!

Should you experience issues

If you encounter issues in the installation process or in the usage process please do not hesitate to contact me on discord, codeberg or here.
It is really valuable to see what kind of issues people have because it will help me know where to focus my efforts and how to improve documentation.

kuhbs · July 17, 2026, 4:17pm

Very interesting, thank you for sharing!

A few very simple questions so I can see “what this does / how it works”:

Lets say I want to create a AppVM with signal-desktop installed - what files would I have to create for this (ideally provide how they look like please) and what commands do I execute to create the TemplateVM, install signal-desktop in it via apt: Signal >> Download Signal for Linux , and then create a AppVM from it?

This task, for me, is a bit of a “hello world” task for me to see how config management works. Would love to see how you do this!

nexus · July 17, 2026, 5:37pm

Hi! Great question!

In QixOS there are basically two types of configs you need to create: an ‘outer’ configuration and an ‘inner’ configuration.

The outer one will declare that you want an AppVM with signal installed. Below is an example of an outer config that defines 1 template VM and 1 app VM.

    qixosConfigurations.my-signal-setup = { 
      baseTemplate = "qixos-admin-base-template";

      # In this config we just have 1 template which these nubes share.
      nubeClusters.my-template = {
        template = {
          properties = {
            label = "black";
          };
          remoteFlake = {
            # This is a git url to a basic template config, essentially all templates can use the exact same 'inner' config.
            url = "git+https://codeberg.org/originalposter/qixos-community?ref=master&dir=users/op/nubes/templates/basic";
            output = "qixosTemplateConfigurations.default";
          };

          deleteOnRemoval = true;
        };
        appVms.signal-vm = {
          properties = {
            label = "green";
          };

          remoteFlake = {
            # This is a git url to the 'inner' config for the signal configuration
            url = "git+https://codeberg.org/originalposter/qixos-community?ref=master&dir=users/op/nubes/appvms/signal";
            output = "qixosAppConfigurations.default";

            deleteOnRemoval = true;
          };
        };
      };
    };

The inner configuration for a signal VM can be found here.

With those two files defined you run the following command in the qixos-admin VM:

qixos-rebuild --flake <path-to-outer-config>#my-signal-setup apply

Some additional notes:

We use the nix package repository for signal rather than apt and each AppVM can define what things it wants to install rather than having the template define these. This does not cost disk overhead since if two appVMs install the same package these will be shared.

kuhbs · July 17, 2026, 5:57pm

how do you “apply” this? Can you please copy paste cli output from what it looks like when you want to create the signal qube (including the command)?

Also how does this run things inside of the VMs? Like dumbest example, if I want to create /home/user/test.txt with content “hello world” - what way does this use to do this exactly?

Is there a “nix library for Qubes OS” or something that abstracts things like qvm-copy-to-vm, qvm-run, bla?

What limitations does this have?

I am working on something called kuhbs, which is supposed to be a config management system for Qubes OS that is targeting endusers, so when I look at this I’m thinking about the “challanges” I’m facing with this.

One thingy I had to work around for example is what if I want to replace sys-net with sth custom. This has to “move” the qvm-pci assignment, as well as first setup the new VM while still using sys-net for internet, and then on removing the custom VM for NIC it also has to assign the pci device back to sys-net.

I’m wondering how things like this are managed here. Please share some insight into how this works, feels and behaves as a daily driver.

The idea here is also to completely abstract the whole setup in code, yes?

Btw, does this manage dom0 as well? For example can this manage by dom0:~/.config/i3/config and alike? I do something that auto-assignes specific Qube VMs to i3 workspaces automatically, think ~/.config/i3/config.d/media.conf - can you put this into one “definition” of a Qube VM setup (or multiple VMs, think template-signal, app-signal, …) as well?

I find this project very very interesting. I am familiar with how salt works in Qubes and I hate it very deeply I am familiar with how salt normally works and also don’t like it. I’m also not happy with qubes ansible x) Even though I really like ansible.
I’m a bit on a quest to bring Qubes to endusers, think appstore, as in “click to install Signal”. I am writing my own config management service for this, but question if this is the right choice.. I heared of Nix OS and that its basically config management build into the OS, but never did much with it or looked any deeper.

So long story short I’m VERY interested in your project, if you have the time please just textwall me a bit about it here

linuxuser1 · July 17, 2026, 6:28pm

I’m not a NixOS fan since it’s not the simplest distro for me - which is exactly why this work earns such enormous respect.

kuhbs · July 17, 2026, 6:40pm

Well fully managing Qubes using config management might be worth the effort of learning it.. I’ve HEARED lots of good things about nix OS but never tried it.

nexus · July 17, 2026, 9:31pm

Haha I’d love to text wall you about this!

how do you “apply” this? Can you please copy paste cli output from what it looks like when you want to create the signal qube (including the command)?

I’ll paste the output of applying this at the end.

Also how does this run things inside of the VMs? Like dumbest example, if I want to create /home/user/test.txt with content “hello world” - what way does this use to do this exactly?

The way you run things inside of VMs is using regular NixOS ways. In order to create files you can declare them in your config so inside of the ‘inner’ config we’d add something like:

home.file."test.txt".text = "hello world";

and then run qixos-rebuild –flake <path>#<name> apply. (for completeness sake the above nix code uses the nix home-manager)

This isn’t the only way to do it, NixOS offers a bunch of ways to both act on the OS, for tasks that require more complex actions you can easily declare systemd jobs that run on boot.

Is there a “nix library for Qubes OS” or something that abstracts things like qvm-copy-to-vm, qvm-run, bla?

Not the way I think you mean this. Nix code is a declaration of what your system should look like. It tries to avoid doing imperative things like "qvm-run bla”. If you want to do imperative things then you tend to declare a systemd job which do them for you. There are escape hatches but they’re discouraged.

What limitations does this have?

Hmm, it’s a difficult question to answer. I’ll try to list some domains of where you’ll find limitations.

You need to declare your configurations in the nix language. So the limitations of NixOS and the nix language come along with QixOS.
There are plenty of unfinished things in QixOS right now. For example the configuration and packaging of the qubes audio system isn’t done yet so you won’t be able to play audio in any nube. The same is true for a bunch of the special cased sys- qubes. This isn’t a conceptual limitation though, it’s just isn’t in the alpha yet.
AppVMs that share a TemplateVM can see each others configurations because they all share a /nix/store/ folder that is inside of the template.
Everything has to come through the nixpkgs repository. (package repo of nix)
I’ll go into details later but doing dom0 management is intentionally not possible and with that anything that MUST go through dom0 is off limits to QixOS. Things that can go through the admin API are not off limits.

One thingy I had to work around for example is what if I want to replace sys-net with sth custom. This has to “move” the qvm-pci assignment, as well as first setup the new VM while still using sys-net for internet, and then on removing the custom VM for NIC it also has to assign the pci device back to sys-net.

This is an interesting problem. I’ve not tried to look into this yet and it might be bumping up against a fundamental limitation of QixOS which is that it has no access to anything in dom0 that does not go through the admin API. If PCI assignment is possible to do through the admin API qixos-rebuild would have to have some custom logic for how to translate a declarative config for who should be the network VM to a set of imperative actions that assign this correctly. I don’t know enough about the details here to comment on where and if we’d run into issues.

I’m wondering how things like this are managed here. Please share some insight into how this works, feels and behaves as a daily driver.

It works as a daily driver for me, all my regular VMs are QixOS nubes, but it involves a lot of pain (which I don’t mind since I’m developing it). Deploying a large configuration is very slow and will sometimes crash due to for example the OOM killer. Like I mentioned there are plenty of things still missing such as audio.

The idea here is also to completely abstract the whole setup in code, yes?

That’s right!

Btw, does this manage dom0 as well? For example can this manage by dom0:~/.config/i3/config and alike? I do something that auto-assignes specific Qube VMs to i3 workspaces automatically, think ~/.config/i3/config.d/media.conf - can you put this into one “definition” of a Qube VM setup (or multiple VMs, think template-signal, app-signal, …) as well?

Like mentioned before QixOS does not manage dom0 at all by design. I wanted to let people be able to use QixOS without having to compromise on the security of the entire system. What you’re describing with modifying i3 is of course a highly desirable feature and I’m really hoping to be able to achieve WM configurations and similar by setting up a sys-gui nube that can be configured. However that’s a bit into the future.

I am not sure what you mean by

can you put this into one “definition” of a Qube VM setup (or multiple VMs, think template-signal, app-signal, …) as well?

could you clarify?

I find this project very very interesting. I am familiar with how salt works in Qubes and I hate it very deeply I am familiar with how salt normally works and also don’t like it. I’m also not happy with qubes ansible x) Even though I really like ansible.

I also really hate salt, yuck

I’m a bit on a quest to bring Qubes to endusers, think appstore, as in “click to install Signal”. I am writing my own config management service for this, but question if this is the right choice.. I heared of Nix OS and that its basically config management build into the OS, but never did much with it or looked any deeper.

That’s an admirable aspiration, I’ve looked a little bit at Khubs and I think we have similar interests but quite different approaches, different enough that I think we’re targeting different types of users. QixOS is fundamentally using nix and will require that every user embraces this, in return they’ll get an amazing configuration language and OS. However not all users are going to embrace nix and I think if Khubs can offer a user friendly interface for non-nix users it can be a great service.

QixOS does not currently do a lot of the more specific Qubes wiring like the PCI device things you talked about earlier. QixOS will eventually have to tackle similar problems and I’d be interested in reading more about what you did and how you did it. It would be cool if we could collaborate as we solve these similar problems.

I really like the idea of an appstore for Qubes, I think it’s such a perfect format because a VM offers an amazing configuration sandbox and an appstore needs high security around the “apps” for it to be safe to share. My vision for the QixOS appstore is obviously one described in nix. I also really hope to make it more personal than just a wrapper around programs and additionally have little environments that you can share with others.

Here are the outputs of qixos-rebuild

[user@qixos-admin:~/qixos-community]$ qixos-rebuild --flake ./users/op/outer-configs/example#example apply
INFO: apply
INFO: switch templates
INFO: switching template [my-template-nube]
INFO: protocol_blob: {
  "template_dirname": "qixos-community-e531cd27",
  "template_flake": {
    "source": "users/op/nubes/templates/basic",
    "output": "qixosTemplateConfigurations.default"
  },
  "remote_appvms": {
    "signal-vm-example-nube": {
      "source": "git+https://codeberg.org/originalposter/qixos-community?ref=master&dir=users/op/nubes/appvms/signal",
      "output": "qixosAppConfigurations.signal-nube"
    }
  },
  "local_appvms": {},
  "tar_dirs": [
    "qixos-community-e531cd27"
  ],
  "update_lockfile": false,
  "standalone": false
}
INFO: switch protocol beginning
INFO: calling my-template-nube qixos.Switch
INFO: sending json blob b'{"template_dirname":"qixos-community-e531cd27","template_flake":{"source":"users/op/nubes/templates/basic","output":"qixosTemplateConfigurations.default"},"remote_appvms":{"signal-vm-example-nube":{"source":"git+https://codeberg.org/originalposter/qixos-community?ref=master&dir=users/op/nubes/appvms/signal","output":"qixosAppConfigurations.signal-nube"}},"local_appvms":{},"tar_dirs":["qixos-community-e531cd27"],"update_lockfile":false,"standalone":false}'
INFO: trying to send tardir /tmp/tmpaq14bmc1.tar
INFO: sending directory size 266240
INFO: sending tar file /tmp/tmpaq14bmc1.tar
INFO: waiting for qixos.Switch to finish on [my-template-nube]...
qixos.Switch starting...
tar blob byte size: 266240
switching to new flake configuration at /var/qixos/current-flake/flake.nix
This may take a while...
successfully switched to: /var/qixos/current-flake/flake.nix
INFO: [my-template-nube] qixos.Switch finished successfully

nexus · July 17, 2026, 9:32pm

Thanks! It’s surprisingly fun once you get into it!

kuhbs · July 17, 2026, 9:53pm

khubs

kuhbs the Kuh (german for cow) Build System - after the saying “stop treaing your Qubes OS VMs like pets, start treating them like cattle” - borrowed from the inventor of Saltstack, which ones said exactly that about servers x)

Kuhbs is OLD, it used to be bash and I’m trying to get it into python with a nice and very simple GUI. My goal is (amongst others)

Have endusers click “install signal” and move on.
Have a way to configure a kuhb that lets medium knowledge Linux users copy paste an installation manual into a shell script and call that a “kuhb” (like the signal kuhb)

This is working well right now, but its all still in development and not worth a look. What is worth a look though are the kuhb’s (like signal kuhb but multiple) - GitHub - kuhbs/my-kuhbs: Personal KUHBS definitions for a Qubes workstation: network gateway/firewall/Tor/USB plus app and standalone qubes for browsing, code, media, messaging, Hermes, GeForce NOW, and backups. · GitHub

These are the configurations medium skilled users will later develop themselves. Its reasonably idiot proof and worth 3 minutes of your time to fly over, to see how its structured and alike.

The goal here is that people can copy one of those, adjust it a bit and then have their own kuhb.

A kuhb leaves very little to be desired - all setup steps are in bash and it can run scripts in both inside each VM (template for apt and what not, or whatever you want as its bash, and then again in the appvm, for example flatpak –user, and so on). It can do 99% of the things you’d want to do.

It is not really config management though, more like docker. If something goes wrong you do kuhbs remove signal; fix it; kuhbs create signal, so you always start from scratch. It does backups too, so you can specify a backup path like /home/user/.config/Signal and it restores this upon create and bla bla bla.

This is a lot less cool then the nix approach, and a lot more enduser friendly. I am all up and down if I’m doing the right thing here, but salt ansible and from the looks of it nix are just to hardcore for endusers to setup themselves.

Qubes OS website says its for journalists, lawyers, whistleblowers but it really isnt. Its far to complex, which is what I’m trying to solve by providing a secure baseline, starting with the networking stack and alike (the kuhbs- kuhb’s in my-kuhbs repo). You can use those or not, or build your own.
I thought a lot about if I shouldnt build kuhbs around ansible, but then endusers just wont flipping get it again. My goal was that a medium skilled user can kinda just copy paste this: Signal >> Download Signal for Linux

And flip a few settings in yaml, which pretty much every enduser can do.

unman, one of the qubes devs, told me in another thread the other day that I’m reinventing the wheel, and I’ve had this thought before tbh. But the wheel just isn’t fucking round enough (salt) xD

I have ran a linux consulting company for 10 years that was initially build with saltstack and then with ansible, so when I see your nixos approach I’m having second thoughts again about my kuhbs lol… Its far more professional than what I’m capable of coding myself too (nix itself).

I always find automating qubes just “isn’t that complicated”… Thats one of the base ideas behind kuhbs, which is basically just a way to abstract a couple of qvm-bla commands - kuhbs does “everything” with qvm-bla commands.

I really like the idea of an appstore for Qubes, I think it’s such a perfect format because a VM offers an amazing configuration sandbox and an appstore needs high security around the “apps” for it to be safe to share. My vision for the QixOS appstore is obviously one described in nix. I also really hope to make it more personal than just a wrapper around programs and additionally have little environments that you can share with others.

I’d love to have some competition here. My idea for this is that it has to be a gui. If you think whistleblower, they might work in pharmacy or politics or god knows what, and never even touched Linux before. We can get a non echy user AT BEST to write off curl | bash into dom0 to install something - provided the command is less than 25 characters and we will have to explain to them what the pipe | key is.
This sounds dumb, but I think qubes REALLY needs a solution for this.

And I think this Signal >> Download Signal for Linux is the PERFECT example of what a medium skilled user should be able to implement in Qubes OS without having to google / forum / chatgpt to much - it should take him 10 minutes to figure this out - which kinda only leaves yaml config + a folder structure so small that its all obvious really fast.

OR we just build all the “apps” in the appstore (we, the techys). But then its kinda limited again, we can never know what kinda nonsense that lawyer, journalist or whistleblower needs to blow the whistle lol.
On the other hand chatgpt can kinda implement this all for him now. If he knows how to prompt it for it…

Here are the outputs of qixos-rebuild

Yeah this looks quite nice. Not as clean as ansible. x)

For me, I think the best approach is docker like, which is funny because I’m REALLY not a fan of docker xD But to me the “build from scratch each time” approach kinda made most sense.

I’m textwalling too rn x) Please keep textwalling, I’m very happy to speak to another qubes automater about it all.

Automating things is kinda my passion, EVERYTHING HAS TO BE AUTOMATED lol x)

nexus · July 19, 2026, 3:51pm

I agree with your diagnosis that QubesOS as it stands is difficult to use for non-technical users. You’ve made me think about more about how and if this can be solved in QixOS by for a simple UI frontend that interfaces with QixOS. It does not sound impossible. Like discussed I also really like the idea of an appstore so these ideas might work well together.

I’m not as sold on the bash script or the docker setup as the base configuration architecture. The nix ecosystem is a fantastic set of systems and ideas and if it’s possible to piggyback on NixOS I think that’s a huge win. Same as I think piggybacking on Qubes for security is a huge win.

LLMs becoming so commonplace also makes configuration as code much more attractive and I think we can more and more offer knobs to non-technical users as long as we can give them a good prompt to tweak those knobs.

Yeah this looks quite nice. Not as clean as ansible. x)

Definitely. The logs are really ugly at the moment, improving them is one of the many things on the TODO list!

Interesting chatting with you, I’m sure we’ll see each other around and I’d be delighted to discuss things further if you have any more ideas.

kuhbs · July 19, 2026, 4:01pm

Well this topic will keep existing I’ll be notified on updates.

I’m not as sold on the bash script or the docker setup as the base configuration architecture. The nix ecosystem is a fantastic set of systems and ideas and if it’s possible to piggyback on NixOS I think that’s a huge win. Same as I think piggybacking on Qubes for security is a huge win.

I see your point here, and I’m also up and down on it. What I’m thinking on is is maintaining yet another system (there is salt and ansible) the solution, but idk anything about Nix, so might be. But keep in mind that if this ends up in a gui with an appstore for endusers, this has to be maintained.

Some GUI inspiration below (its my WIP).

kuhbs · July 19, 2026, 4:32pm

One more thing I just thought, as much as I hate docker.. I think in Qubes the best approach for an update of anything inside a Qube is destroy, build from scratch.

Even if a user doesn’t go the route of “kill the whole system and restore it once a day”, and if only dom0 is trusted ultimately (or in this context permanently), it is still better to not “update config”, as in do config management on files in VMs, but to just throw the whole thing away and build them from scratch.

This however is a security thing, not an admin / configuration management thing. But giving the user the ability to “update this file” in a VM rather than “forcing” the user to build the whole VM from scratch if he wants to “update this file” kinda seems wrong to me.
On the other hand this is forcing the user to build sth more trusted simply because he wants to update a file, not because he wants the security of build it from scratch.

Each time I think about this I kinda like my approach better, even though the admin in me says “just use a proper config management tool” xD

There are many pros and cons to it all x)

otter2 · July 22, 2026, 2:04am

Keeping installation out of dom0 is a good decision.

Correct me if I misunderstood how it works for the following, I haven’t read the code, only sifted sparsely.

Cooperation with switch could be iffy. How do you (plan to) ensure a malicious switch doesn’t take over qixos-admin or at least an instance of qixos-rebuild? Judging by this you don’t, not yet: #15 - Don't let qixos-rebuild get output from qixos.Switch - originalposter/qixos - Codeberg.org

It is curious that you clone to create standalone and template vms. No option to define empty or load virtual disk yet?

When deleting qubes you don’t seem to handle QubesVMInUseError. I understand this is temporary? It should be fine for qube class hierarchy since you remove appvms first but should fail if appvms depend on each other.

Also no named disposables?

What inner config urls other than codeberg work? tested? planned?

What loicense?

Do you plan to do any review on the community repo? Seems like the answer is no? If so bothering with repository indexing could be more valuable than bothering with prs, and allows sharing configs however you want

How long have you been working on this project? running it?

Do you have a solution for the fact that “special qubes” require writing qrexec policies?

Nah seems too early. Only for poking around the code maybe?

nexus · July 22, 2026, 10:01am

Keeping installation out of dom0 is a good decision.

Agreed!

Cooperation with switch could be iffy. How do you (plan to) ensure a malicious switch doesn’t take over qixos-admin or at least an instance of qixos-rebuild? Judging by this you don’t, not yet: #15 - Don't let qixos-rebuild get output from qixos.Switch - originalposter/qixos - Codeberg.org

qixos-rebuild (ran inside the admin) only needs to write to the qixos.Switch qRPC endpoint. The only reading it is doing is reading the output logs from qixos.Switch for debugging purposes, the issue you linked is about removing that read. I don’t see how a malicious switch would take over admin unless you mean by finding for example a terminal emulator exploit before the linked issue is resolved? Do you see another way?

It is curious that you clone to create standalone and template vms. No option to define empty or load virtual disk yet?

That’s right, and I haven’t really planned for that. It’s not a feature I have thought holds a lot of value especially since QixOS requires that the VMs are NixOS and have certain software packages installed onto them. Do you see value in this feature?

When deleting qubes you don’t seem to handle QubesVMInUseError. I understand this is temporary? It should be fine for qube class hierarchy since you remove appvms first but should fail if appvms depend on each other.

Also no named disposables?

Both planned work. This and much more is planned work. I wanted to get feedback on architectural decisions as well as the general vision before I continued for too long.

What inner config urls other than codeberg work? tested? planned?

The inner config URLs just need to point at a nix flake, so anything that can host a nix flake works. This includes github, gitlab, http, local files, etc.

What loicense?

I’m planning on making it GPLv3. Currently I’m away and can’t push things, but once I’ve got access again I’ll clean some docs up, including the license.

Do you plan to do any review on the community repo? Seems like the answer is no? If so bothering with repository indexing could be more valuable than bothering with prs, and allows sharing configs however you want

That’s a good suggestion. I’ll seriously consider doing repo indexing rather than community repo with PRs. I wonder if there might be a compromise where you both accept PRs for code as well as PRs to add a repo to the index.

How long have you been working on this project? running it?

~6 months, I’ve been running it for basically as long. Running it is trivial since you can just run it on top of your already existing QubesOS setup and mix and match the types of VMs you use.

Do you have a solution for the fact that “special qubes” require writing qrexec policies?

Yes, but only theoretical. The qubes admin API allows you to choose VMs that can edit the policy. I have not looked into this more than just noting that it exists so there might be details that make it unusable. If so I suppose we’ll have to find another solution and in the worst case ask users to edit the policy if they want to have a special VM.

Nah seems too early. Only for poking around the code maybe?

Fair enough! Assuming it gets a bit more mature and various details are fixed and features are added is this something you’d be interested in using?

otter2 · July 22, 2026, 2:25pm

I don’t know, I haven’t checked that part of the code

Yeah absolutely. Even with no internal configuration of nixless domains their definition and deletion on removal of said definition is valuable.

More specifically, empty standalones is how you do storage-less unkernels on qubes. But it also is useful for other images via qvm-start --cdrom

p.s. You don’t need the standalone to be empty strictly speaking since you define what runs but that’s just dirty

Perhaps