Six months later: my 30-PC school lab setup became Nixorium 2.1

[u/zener79]

Six months ago I posted here about the NixOS setup I built for the 30-PC computer lab where I teach.

At the time, it worked well for me, but it was still very much my setup: tied to one lab, one network, and a lot of assumptions I had accumulated along the way.

Since then I've been trying to turn it into something other people could actually install, understand, and maintain.

Today I released Nixorium 2.1.

The idea is still simple:

• one NixOS machine acts as the controller
• the lab is described declaratively
• clients can be installed and updated over the LAN
• only the controller needs Internet access
• applications still run locally on each PC
• student environments return to a clean state between lessons
• machines can be replaced and brought back to the same configuration

A lot of the work since my original post has been on the less exciting parts: separating private site configuration from the reusable framework, safer installation flows, recovery from interrupted operations, backups, diagnostics, VM-based release validation, CI, and documentation.

I also made a short 1-minute explainer, because describing this only in Nix terminology makes it sound more complicated than it is:

https://nixorium.org/

The source is here:

https://github.com/giovantenne/nixorium

One caveat I want to be clear about: Nixorium grew out of a real 30-PC lab, and I test releases in VMs, but hardware is hardware. Different firmware, NICs, switches and disk layouts can still expose things that virtual testing won't.

So now I'm especially interested in real-world feedback.

If you run a homelab, classroom, training room, makerspace, or just have a couple of disposable machines around, I'd be very interested to hear:

• what would stop you from trying this?
• which parts of the deployment/recovery story still feel unclear?
• what would you want to see before trusting it on real hardware?

And if anyone actually tries it on hardware different from mine, even a failed attempt would be genuinely useful feedback.

For context, this was my original post from six months ago:

https://www.reddit.com/r/NixOS/comments/1rqtu0j/i_built_a_reproducible_nixos_deployment_system/

-----

EDIT:

A lot of Nixorium is basically an attempt to automate and simplify the workflow I originally did by hand. If you're curious about where it started, the old v1 README from six months ago describes that setup and the manual steps much more directly:

https://github.com/giovantenne/nixorium/tree/11b87a9ca185b0d2a0f2f32bdd342dfba0677d55

[u/fell_ware_1990]

Cool project!

But what if i manage a room full of pc’s with linux, but i’m not a student? 🧐

[u/zener79 → u/fell_ware_1990]

“Student” and “teacher” are mostly terminology inherited from the environment Nixorium was originally built for.

At its core, it's really just a controller managing a room of NixOS machines: installation, updates, recovery, reproducible configuration, etc. That can just as well be a training room, makerspace, shared lab, office, or homelab.

student and teacher are just the default user names/roles Nixorium ships with, because it originally grew out of a school lab.

They can be changed to whatever fits your environment. The site also explains what those roles are meant to represent and how they differ in terms of permissions and workflow.

So the classroom terminology is mostly a default, not a hard requirement.

[u/SDG_Den → u/zener79]

i might see about extending this in the future, ive had an idea for how to manage a fleet a la microsoft entra ID/intune but through nix, and this solves a very large portion of that puzzle

[u/shockjaw]

I remember seeing your first post! Glad to see that you’re still refining this project! It’s so cool!

[u/muhmmadtalha-quant]

kinda curios which nix config pattern it uses?

[u/zener79 → u/muhmmadtalha-quant]

Mostly a flake + NixOS modules.

There are shared modules, controller/client-specific modules, and optional per-host overrides. `mkLab` combines them into the final machine configs.

Simple settings can stay in JSON, while advanced customization can still use normal Nix modules.

[u/muhmmadtalha-quant → u/zener79]

which de does it use ? KDE? or a hyprland based stitched setup ?

[u/zener79 → u/muhmmadtalha-quant]

GNOME at the moment 🙂

[u/Shuaster136]

I have no use for this whatsoever, but it looks awesome and sounds like a great idea well fit for NixOS. Great work!

[u/Twitch_C4T_]

So basically just deployrs

[u/zener79 → u/Twitch_C4T_]

Not exactly, `deploy-rs` is closer to Colmena, which Nixorium already uses for remote deployment.

Nixorium is the layer around that: provisioning machines from scratch, PXE/USB install, local binary cache, lab-wide configuration, TUI, student environment reset, backups, diagnostics and recovery.

So if all you need is “deploy NixOS configs to machines that already exist”, `deploy-rs` may be enough. Nixorium is aimed at managing the full lifecycle of a room of PCs.

[u/207852 → u/zener79]

Nixorium is built on top of colmena?

[u/zener79 → u/207852]

Nixorium currently uses:

• Nix flakes as the source of truth
• UEFI PXE/netboot for the initial installation only (I didn't want to boot every single PC from USB)
• Harmonia as a local binary cache
• Colmena for multi-machine deployment/orchestration
• Disko for declarative partitioning
• Btrfs for student-home snapshots

[u/207852 → u/zener79]

Sounds interesting.

I would test this if I have new machines to deploy. I think disko and netboot would be the most beneficial to me.

But I don't have anything now.

[u/cfx_4188]

Well, someone discovered a thin client.

[u/zener79 → u/cfx_4188]

Not really 🙂
The clients aren't thin clients: they have their own local NixOS installation and applications run locally on each machine.

The controller is used for provisioning, deployment, caching and management, it isn't serving desktops or application sessions.

So it's closer to centrally managing a fleet of full workstations than to a traditional thin-client setup.

[u/necrophcodr → u/cfx_4188]

A thin client is a remote desktop system, or a terminal client. It is not a remotely managed device (although it usually is that too).