XCP-ng is a turnkey virtualization platform, and this repository is its front door

An appliance, not a distribution you configure

The product is described as the user-friendly, high-performance virtualization solution, developed collaboratively for unrestricted features and open-source accessibility, and the tagline is Turnkey Open Source Virtualization Platform. The features section makes the turnkey claim concrete. There is no complicated setup, because XCP-ng is a true appliance with everything pre-configured and ready to run your VMs. It runs, snapshots, live migrates and grows any kind of workload or operating system on top of it, even containers. It is based on the Xen hypervisor technology, which the README describes as making it one of the most secure virtualization platforms on the market, both technologically and with what it calls a really serious security workflow. And it is fully open source with no paywalls or complicated licenses, all the features are free. The audience is an infrastructure team that wants a hypervisor platform without a per-feature licensing conversation.

This repository is the entry point, not the implementation

The repository description is unusually blunt about what it is, the entry point for issues and the wiki, and it also contains some scripts and sources. That is worth understanding before you clone anything expecting to find a hypervisor in it. The top-level entries match that description, with an iso/ directory for the installer build, a data/ directory, a misc/ directory, a scripts/ directory, the Makefile, a pyproject.toml and a setup.cfg, and a .github/ directory. The platform itself is documented at docs.xcp-ng.org, and the wiki lives in this repository, which is where the how-to-report-bugs and Mirrors pages are, so a contributor ends up here even though the code does not. That arrangement is common for a project whose main community surface is a documentation wiki and an issue tracker rather than a source tree.

The Makefile exists to keep the JSON tidy

The Makefile at the root is short and its job is not to build a platform. The default target is help, which prints the README, and there is a setup target that checks for the presence of the tools, with the jq variable defaulting to jq --indent 4. The lint target walks the tree for JSON files, skipping directories named with a cache suffix, and pipes each one through jq and moves the result back over the original, which rewrites every JSON file with jq's own indentation. The check target depends on lint and then runs git diff --stat --exit-code, so it passes only if the sources are already linted, with the message telling you to lint and commit if they are not. That is a complete, self-checking format policy for a repository whose data files are generated or hand-edited JSON, and it is the kind of thing that keeps a merge from being blocked later by whitespace.

The Python tooling configuration

The pyproject.toml is short and shows how the project checks itself. The pydocstyle configuration ignores a long list of codes, D100 through D107 for the missing docstring rules, and then D203, D210, D212, D401 and D403, which is the shape of a project that has decided documentation style is a matter of taste and enforces only the parts it cares about. Ruff is configured with preview enabled and a line length of 120, and the format section sets quote-style to preserve, which is a deliberate choice, since a formatter that rewrites your quotes creates diff noise in a repository where the data files are JSON. The lint section selects four rule families, F for pyflakes, I for import sorting, SLF for private member access and SIM for simplifications. The selection is small on purpose, and the combination with the pydocstyle ignores suggests a project that wants a short, predictable set of checks rather than a comprehensive style gate.

Installing it means downloading an ISO

The quick start is two links. Download the ISO from the project mirror, and install it on your own hardware using the instructions on the project site. The link in the README points at the 8.2.1 image on mirrors.xcp-ng.org, and the install guide lives at xcp-ng.org under the easy-to-install anchor. That is the whole deployment story, and it is worth pausing on, because a virtualization platform installed from an ISO onto a host disk is a genuinely different kind of commitment from a package you can remove. The documentation site at docs.xcp-ng.org is the official documentation, and the security workflow page linked from the features list is the one to read if you are deploying rather than experimenting.

Management at scale, and the commercial path

The management story is where the platform stops being an appliance. There are many integrated ways to manage an XCP-ng host, both locally and remotely, with a command line, a graphical interface and an API, and Xen Orchestra is named as the de facto administration and backup platform. The screenshots in the README are of that interface rather than of the host, which tells you where the day-to-day work happens. And there is a second path for production, the pro supported option, where XCP-ng is part of the Vates VMS stack that covers the virtualization platform through to the administration and backup tools. That is the honest shape of the project, an open source platform with a commercial support and management layer around it, which is also why the feature list emphasises that there are no paywalls and all the features are free at the platform level.

The release line, the community and the mirrors

The releases are tagged by product version, with 8.2.1 marked as an LTS release on 2023-10-20, 8.3.0 marked as an LTS release on 2025-04-30, and a dated build, 8.3.0-20250606, published on 2026-06-16. The last push to the repository was on 2026-10-15, so the work on the scripts and the wiki continues even where the platform releases are on a longer cadence. The community surface is the forum at xcp-ng.org/forum/, the contribution guide in the documentation, the bug reporting wiki page, and a mirrors page, because a platform that people install from an ISO needs mirrors, and the project invites people to host one. The topic tags place the lineage in the open, with citrix, xenserver, xen-source, xen-cloud-platform and xcp among them, which is the ancestry of a project that took a commercial hypervisor and opened it up.

Editorial conclusion

XCP-ng is the right choice if you want a Xen based virtualization platform you can install from an ISO and administer without a per-feature licence conversation, especially for teams that have outgrown a single host and want live migration, snapshots and a management API. It is the wrong choice if you need a software-defined stack with a vendor behind it, because the commercial path here runs through a different product, and it is the wrong choice if you want to build on the platform source rather than run it, since this repository is the entry point for issues and the wiki rather than the whole implementation. Before you commit, read the documentation site rather than the README, since the README is a product page and the details live in docs.xcp-ng.org, and test the installation on a spare machine first, because an appliance install is not reversible on the host disk.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. xcp-ng/xcp on GitHub