I've been working on a project I'd like to share and get feedback on: xo-apply — configuration-as-code for Xen Orchestra.

The idea: XO keeps its entire configuration locked inside its own database. There's no way to write any of it down in a reviewable file, so rebuilding an XO means re-creating it all by hand in the UI. xo-apply treats XO as code: declare your XO in a YAML file, keep it in git, and reconcile any instance to match it — the same model Terraform uses for cloud accounts.

Backups are where we started — that whole surface is complete today (remotes, jobs, schedules, DR/CR, metadata, mirror, sequences)

What you can do with it:

Rebuild fast — reinstall XO, reconnect your pools, then xo-apply apply config.yaml and your remotes/jobs/schedules are back without clicking through the UI.
Detect drift — xo-apply diff tells you when someone changed a job in the UI and it no longer matches the file (exits non-zero on drift, so it drops straight into CI).
Review changes in git — every config change is a commit with an author and a diff.
Clone configs — apply one file to several XO instances (e.g. keep staging and production identical).
A quick taste of the diff output:

Remotes:

• create nas-backups (nfs://192.168.1.50:/export/xo-backups)
  Backup jobs:
• create nightly-critical (delta, 1 schedule)
  ~ update weekly-full
  ~ schedule weekly
  retention: 4 → 8

Plan: 2 to create, 1 to update, 0 untracked
There's also an interactive terminal UI — just run xo-apply with no arguments and it walks you through connecting, picking a config file, and running diff/apply/export. And a plain export command to write down what you already have on an existing XO, so you can adopt it without starting from scratch.

What's covered today (the complete backup surface):

Backup remotes (NFS, SMB, S3, local)
VM backup jobs + schedules (delta/full, smart-mode tag selection, explicit VM lists)
Disaster Recovery / Continuous Replication (SR targets)
Pool metadata + XO config backups
Mirror backups
Backup sequences (run schedules one after another)

On the roadmap — this is where the project grows beyond backups toward managing the rest of XO, and where I'd love input on priorities:

• Users & groups
• Servers / pool connections
• ACLs / RBAC
• Backup job health checks

How it works under the hood: it talks to XO over the network — the REST API where writes are supported, and XO's JSON-RPC websocket via xo-lib (the same client xo-cli uses) for backup jobs/schedules, since the REST API doesn't expose those writes yet. No state file is kept: the running XO is always the source of truth. It runs anywhere Node.js ≥ 20 does — Linux, macOS, Windows — and works against any current XO from sources or XOA.

Install is a one-liner from GitHub (details + full docs in the README):

npm install -g https://github.com/acebmxer/xo-apply/archive/refs/heads/main.tar.gz
What I'm looking for: feedback from this community — is this something people want? And if anyone's willing to test what's there today against their own XO, I'd love to hear how it goes. diff and export are read-only and safe to try; apply shows you the full plan and asks for confirmation before it changes anything (and refuses to run unattended without --yes). One heads-up for testers rebuilding onto a fresh XO: connect your pool(s) and set any remote-secret env vars first — the README covers both.

It's an independent community project, AGPL-3.0 (the same license as XO itself), and not affiliated with or endorsed by Vates. It stands on Vates' own xo-lib and xo-remote-parser libraries.

Repo: https://github.com/acebmxer/xo-apply

Note: this project was built with Claude Code from the ground up.