xlings is a free, open source project & work management project written in C++ and released under Apache-2.0. It has 614 GitHub stars, 49 forks and 48 open issues, and was last pushed 3 days ago. On this registry it ranks #62 of 73 tracked projects in Project & Work Management, with 5 head-to-head comparisons available. It gained 2 stars over the last 30 tracked days.

What is xlings?

xlings is a universal, rootless package manager with OS-like SubOS isolation that installs and runs any version of anything across Linux, macOS, and Windows — built for developers juggling multiple toolchain versions and for AI agents that install and drive software on their behalf.

What it is

xlings is package infrastructure written in C++ and released under Apache-2.0, with 607 stars and 49 forks on GitHub. It treats a package as an xpkg that may carry a binary, a script, config, a SubOS, or a tutorial, and it draws those recipes from a decentralized index made of an official index, third-party indexes, and self-hosted ones, with resource servers acting as binary mirrors. Versions coexist rather than overwrite each other: the version-view plus ref-counting model keeps N environments at roughly the storage cost of one.

The concrete problem is toolchain sprawl inside one user account. A single installed version of a compiler or runtime, placed there with root, conflicts with the need to build against gcc 11 and gcc 16 on the same afternoon. xlings replaces single-version, system-wide install flows and per-tool version switchers, and it places itself in the space its own docs/comparison.md sets out — the neighbourhood of apt, nix, and docker, but rootless, cross-platform, and scoped to per-project tool selection instead of system packages or full containers.

Key capabilities

  • One xpkg format covers five asset types: binary, script, config, subos, and tutorial.
  • Multi-version coexistence through version-view and ref-counting, so N environments cost about 1x storage: xlings install gcc@16 gcc@11 node@24 cmake then xlings use gcc@11 switches the active version while both stay installed.
  • Three levels of SubOS isolation: shell (environment switch), filesystem (bwrap or proot, rootless), and image (ext4, root).
  • Decentralized package index combining official, third-party, and self-hosted indexes, plus resource servers for binary mirrors.
  • JSON event interface through xlings interface (NDJSON), intended for AI agents, CI, and third-party tooling.
  • Self-diagnosis with xlings self doctor --fix, which checks the four state layers and repairs them in one run.
  • Built-in agent guide: xlings agent lists skills and the overview, xlings agent usage prints a complete usage guide written for LLM agents.

Who uses it and how

  • MCPP builds on xlings, and Luban Linux is listed as upcoming.
  • AI agents such as Claude, Codex, and OpenCode install it from a pasted prompt and then self-learn the workflow by running xlings agent usage.
  • CI pipelines and third-party tools consume the xlings interface NDJSON stream instead of parsing human-readable output.
  • Developers on Linux, macOS 14+ arm64, and Windows x86_64 run identical commands to keep several versions of a toolchain side by side without sudo.
  • Teams needing private or mirrored packages run their own index and resource servers.

Getting started

On Linux and macOS, run curl -fsSL https://raw.githubusercontent.com/openxlings/xlings/main/tools/other/quick_install.sh | bash; on Windows, run irm https://raw.githubusercontent.com/openxlings/xlings/main/tools/other/quick_install.ps1 | iex. An agent can be handed the repository README with those same two commands and will install xlings itself.

How it compares

No list of paid products accompanies this entry, so the meaningful comparison is the one named in the project's own facts: apt, nix, and docker, addressed in docs/comparison.md. Where apt manages system packages with root privileges and docker isolates whole containers, xlings stays inside a single user account and targets toolchain versions rather than machines or services.

When to use it — and when not to

On macOS and Windows, --sandbox is not a security boundary: it redirects the home directory so a tool writes its dotfiles somewhere isolated, and it does not contain the filesystem, the network, or processes — use an OS sandbox or a VM to run code you do not trust. Package coverage is partial on Linux aarch64, macOS, and Windows, because many recipes publish only an x86_64 artifact; xlings installs a single-artifact recipe but tells you the recipe could not confirm your architecture. The project also carries 48 open issues, so anyone expecting uniform behaviour across every platform and every recipe should plan around that gap.

project readme (upstream, from github) — read inline

xlings

Universal package infrastructure with OS-like SubOS isolation.
Multi-version · Rootless · Decentralized Index · Agent-ready.

Website | Docs | Package Index | Forum

中文 | English

Used by: MCPP · upcoming Luban Linux

Why xlings?

One tool to install any version of anything, run it rootless, and isolate it OS-like — across Linux, macOS, and Windows.

"Supported" is three separate questions, so here are three columns. A platform xlings runs on is not automatically a platform every package has an artifact for, and neither of those says anything about how much isolation --sandbox can actually give you.

Platform xlings release Package coverage subos --sandbox isolates
Linux x86_64 ✅ published full the filesystem (bwrap / proot)
Linux aarch64 ✅ published partial — many recipes only publish an x86_64 artifact the filesystem, once a backend is available for the arch
macOS 14+ arm64 ✅ published partial — some recipes ship x86_64 only only $HOME
Windows x86_64 ✅ published partial only %USERPROFILE%

Package coverage is a property of the recipe, not of xlings: xlings install refuses a target only when the recipe enumerates its architectures and yours is not among them. When a recipe ships a single artifact it is installed and you are told the recipe could not confirm your architecture.

macOS and Windows --sandbox is not a security boundary. It redirects the home directory so tools write their dotfiles somewhere isolated. It does not contain the filesystem, the network or processes. Use an OS sandbox or a VM to run code you do not trust.

→ How xlings compares to apt / nix / docker

Core capabilities

  1. Universal package infrastructure — binary / script / config / subos / tutorial, all as xpkg
  2. Multi-version coexistence — N versions side-by-side; version-view + ref-counting (N envs ≈ 1× storage)
  3. 3-level SubOS isolation — shell (env switch) / FS (bwrap/proot, rootless) / image (ext4, root)
  4. Decentralized package index — official + 3rd-party + self-hosted; resource servers for binary mirrors
  5. JSON event interface — xlings interface (NDJSON) for AI agents, CI, and 3rd-party tooling
  6. Self-diagnosing — xlings self doctor --fix checks the four state layers and repairs them in one run

Quick Start

Install — Linux / macOS

curl -fsSL https://raw.githubusercontent.com/openxlings/xlings/main/tools/other/quick_install.sh | bash

Install — Windows (PowerShell)

irm https://raw.githubusercontent.com/openxlings/xlings/main/tools/other/quick_install.ps1 | iex
xlings install gcc@16 node@24 cmake   # install (version optional)
xlings use gcc@16                      # switch active version
xlings search python                   # search packages
xlings list                            # list installed

Let an AI agent install & explain it

Paste this to any AI agent (Claude, Codex, OpenCode, …):

Read the README of https://github.com/openxlings/xlings and install xlings on my machine.
- Linux/macOS: curl -fsSL https://raw.githubusercontent.com/openxlings/xlings/main/tools/other/quick_install.sh | bash
- Windows: irm https://raw.githubusercontent.com/openxlings/xlings/main/tools/other/quick_install.ps1 | iex
Then run `xlings agent usage` and follow it to show me how to use xlings.

xlings ships a built-in agent guide — once installed, any agent can self-learn the full workflow:

xlings agent           # overview + skill list
xlings agent usage     # complete usage guide written for LLM agents

Usage scenarios

🛠 Multi-version toolchains, one command everywhere

Install any version of anything and keep several side by side — switch instantly, no conflicts, no sudo. The same commands work on Linux, macOS, and Windows.

xlings install gcc@16 gcc@11 node@24 cmake
xlings use gcc@11        # switch back anytime — both stay installed

→ Multi-version guide

📦 Reproducible project environments, consistent across OSes

Commit a .xlings.json that declares per-platform versions. Each project gets its own isolated SubOS, so teammates and CI — on any distro or OS — land in the exact same environment, without touching the host or other projects.

{
  "workspace": {
    "xmake": "3.0.7",
    "gcc":  { "linux":  "16.1.0" },
    "llvm": { "macosx": "20.1.7", "windows": "19.1.0" }
  }
}
cd my-project/           # entering the dir activates the project SubOS
xlings install           # installs the declared versions, project-local

→ Project env guide

🤖 Agents & untrusted code in an isolated SubOS

On Linux, run agents inside a rootless filesystem-isolated SubOS. On macOS and Windows, SubOS redirects the home directory but does not contain untrusted code; use an OS sandbox or VM when that boundary is required.

xlings subos new agent-ws --from subos:dev-env@latest
xlings subos use agent-ws --sandbox                       # enter the isolated world
xlings subos use agent-ws --sandbox --cmd "python run.py" # or one-shot exec

→ SubOS & Agent guide

🩺 Upgrade and repair, without hand-editing state

Upgrade the client, then let xlings check its own four state layers — workspace, version database, shims, payloads — and repair what it finds. One run; the report you read is the state after the repairs, and every command it prints is one you can paste.

xlings self update                     # upgrade xlings itself
xlings self doctor                     # read-only check (exit 0 = healthy)
xlings self doctor --fix --dry-run     # preview the repairs
xlings self doctor --fix               # repair

→ Self-management guide

Documentation

Guides, design notes, and specs live in docs/.

Ecosystem

Project Role
MCPP Modern C++ build toolchain ecosystem — distributed through xlings
Luban Linux Upcoming Linux distribution using xlings as system-level package manager (link when published)
xim-pkgindex Official package index — 60+ packages and growing

Community

Contributing

Contributors

Star History Chart

Frequently asked questions

Is xlings free to use?

xlings is open source under the Apache-2.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does xlings do?

Universal package infrastructure with OS-like SubOS isolation - Multi-version · Rootless · Decentralized Index · Agent-ready.

What is xlings written in?

xlings is primarily written in C++. Its source is publicly available at https://github.com/openxlings/xlings, and it has 614 GitHub stars.