@afk I’ve got two draft nixpkgs for libvhdi and Xen orchestra from sources respectively, I’ll look into submitting them upstream soon but take a look and feel free to share any feedback xen-orchestra-ce libvhdi.

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!

@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

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