NiXOA: A declarative implementation of Xen Orchestra using flakes on NixOS

dalem

I have been working on NiXOA, a declarative Xen Orchestra appliance for NixOS designed specifically for running on XCP-ng.

The project started as an experiment in building Xen Orchestra fully from source in a reproducible way using Nix flakes, but over time it evolved into a much larger operator-focused platform with its own CLI tooling, TUI management console, bootstrap installer, host templates, reusable modules, and appliance workflows.

As of v2.0.0, the project architecture has been significantly simplified and unified.

The old split model, where a separate “system” flake consumed “core” as an input, has been deprecated. The core repository is now the operational appliance repository itself. Host definitions, modules, packages, automation, tooling, and documentation all live together in one place.

Quick Start

On a fresh NixOS VM, you can now bootstrap and switch to the latest NiXOA appliance with a single command:

bash <(curl -fsSL https://codeberg.org/NiXOA/core/raw/branch/main/scripts/bootstrap.sh) --enable-flakes --first-switch

The bootstrap installer handles:

Host prompting and initialization
Repository checkout preparation
Trusted binary cache setup
First-switch deployment logic
Initial system guidance before nxcli is installed globally

After the first switch, NiXOA becomes a fully managed appliance environment with integrated tooling and host lifecycle management.

What Changed in v2.0.0

v2.0.0 is the largest architectural refactor the project has had so far.

The repository now contains:

Concrete host definitions
Host templates
NixOS modules
Home Manager modules
Xen Orchestra packaging
Operator tooling
Bootstrap tooling
TUI console management
Documentation
Automation logic

Everything is now consolidated into a single flake.

The project now exposes a Den-native namespace with reusable aspects including:

nixoaCore/platform
nixoaCore/xcp-ng-guest
nixoaCore/xo
nixoaCore/appliance

nxcli Operator CLI

NiXOA now ships with a packaged operator CLI called nxcli.

It provides commands for:

Host creation
Apply/rebuild operations
Rollbacks
Commit and diff workflows
History inspection
Flake updates
Xen Orchestra input updates
XO log tailing
Boot operations
Status inspection

The CLI replaces many of the older standalone helper scripts and acts as the primary operator interface.

Flake apps now route through packaged nxcli behavior instead of runtime helper script resolution.

nixoa-menu TUI

NiXOA also includes nixoa-menu, an xsconsole-style management interface designed specifically for appliance-oriented operation.

Features include:

Compact operator-console layout
Contextual right-side information panels
One visible menu level at a time
Keyboard navigation using arrows, Enter, and Esc
Integrated repository and system operations through nxcli
Apply-time dirty worktree detection and commit prompting

The older multi-pane tabbed console model and large ASCII-art layouts were removed in favor of a more compact and operationally focused interface.

New Host Layout

Host-owned values now live directly under:

text id="x4k1fj" host/<hostname>/

This replaces the older separate system-flake repository model.

Host directories now control:

Hostname
Deployment profile
Hardware imports
Admin user
Shell selection
Optional extras
Menu behavior
Runtime configuration

The repository also includes:

host/_template/
host/nixo-ce-example/
host/_automation/default.nix

There is also a stable nixosConfigurations.vm target for VM-oriented workflows and automation.

Hardening and Runtime Improvements

v2.0.0 also included significant operational hardening and packaging cleanup:

Safer first-switch behavior for VM deployments
Better hardware import consistency
Improved Xen guest tooling integration
Wrapper runtime cleanup
CIFS capability handling
Sudo-wrapper protection fixes
Smaller runtime closure assumptions
Trusted libvhdi cache integration
Cleaner Determinate Nix handling without persistent nix.conf conflicts

The packaged XO path now follows the pinned xen-orchestra-ce / xo-nixpkg input flow more closely and avoids rebuilding unnecessary runtime closure pieces.

Deprecated

The following workflows are now deprecated:

The old split core + system flake model
System-flake-owned lifecycle commands
Legacy helper-script operator workflows
Direct use of older standalone maintenance scripts

Removed

v2.0.0 removed a large amount of legacy behavior, including:

nixoa-cli.sh
Old standalone install/update/log scripts
Obsolete Redis migration helpers
Legacy parts/ flake wiring
Older console rendering models

Documentation

The documentation has also been heavily reorganized and updated.

Current workflows now treat:

bash id="5cz8n7" nix run .#nxcli -- ...

or the installed nxcli command as the primary operator interface.

The docs now focus on:

Bootstrap installation
Appliance operation
Host management
Troubleshooting
Architecture
CLI workflows
Console workflows

Future Goals

Some of the long-term goals for the project include:

Continued refinement of the appliance/TUI operator model
Additional automation around XO package updates
Further upstreaming work into nixpkgs
More appliance-oriented lifecycle tooling
Improved host provisioning workflows

This is still a personal passion project, but it has evolved into something much larger than the original proof of concept.

Feedback, testing, bug reports, and contributions are welcome:

https://codeberg.org/NiXOA/core

afk

@dalem That looks awesome ! Glad to see nix/nixos getting more and more adoption.

It must have been a pain to build the pkgs, thanks a lot for working on this. I'll give it a try when I manage to free some time.

Have you considered upstreaming the module/pkgs to nixpkgs or is this too much work ? I have not contributed there yet so I don't know if it would get merged as is.

dalem

@afk Great question! I’ve decided the best path forward is to create some GitHub mirrors and then submit the libvhdi package upstream, wait for that to get approved, and then submit the Xen-orchestra-ce package since it’s dependent on libvhdi, it’ll take a while but having them both as upstream nix packages is the goal

dalem

This post is deleted!

dalem

I have updated the main post with version 2 of NiXOA, which is aimed to be much more accessible and friendly to first time users, now you can deploy by executing a single command!