Soar: a package manager for portable Linux binaries, without root

It installs packages and does not build them

The distinction is stated first and everything else follows from it. Soar installs packages, it does not build or host them. Repositories publish metadata in a standard format, and Soar reads that index to search, install and update packages, right under your home directory. The readme says that split is the whole point, and it explains why the default repository is not a dependency. soarpkgs is the default, but Soar is not tied to it, and you can add a third party repository or run your own, with the configuration page pointed at for how. The practical difference from a distribution package manager is large. A distribution package manager builds a source package against your libraries and installs it system wide, which means the package version tracks your distribution and the installation needs root. Soar takes a prebuilt artefact and puts it under your home directory, which means the version is whatever the repository published, the installation needs no privileges, and the tool follows you onto any machine with the same architecture.

One statically linked binary and no dependencies

The installation is a single binary and a script, and the note about it is worth reading. Soar is a single statically-linked binary, and you can grab it with the install script:

# curl
curl -fsSL "https://raw.githubusercontent.com/pkgforge/soar/main/install.sh" | sh

# wget
wget -qO- "https://raw.githubusercontent.com/pkgforge/soar/main/install.sh" | sh

The documentation's own advice is to read and verify the script before piping it to a shell, which is good practice for any install script and rare enough to mention. The script is also served from the project documentation site, and if you would rather do it yourself the release page has the binary to drop on your PATH, with the installation docs covering a customised install. The runtime picture is the other half of the pitch, since it runs on any Linux distribution with no superuser, no runtime dependencies and no distribution packages touched. What you can install depends on the repository, and soarpkgs publishes packages for x86_64, aarch64 and riscv64, which is a noticeably wider architecture spread than most projects bother with, riscv64 being the one that matters for the new low cost hardware.

The command set is short and reads like a package manager

The usage section is a list of commands, and it is worth reading as the mental model for the tool:

soar sync                  # fetch the repository index
soar search ripgrep        # find a package
soar install ripgrep       # install it
soar run ripgrep           # run it once, without installing
soar list                  # everything available
soar info                  # what you have installed
soar update                # update everything
soar remove ripgrep        # remove it

The sync step is what separates Soar from a downloader, because it fetches the metadata from the repository first and then searches locally, which is what makes the search fast and the update path cheap. The run command is the one that changes behaviour rather than state, executing a package once without installing it, which is useful for a tool you need on a machine you do not want to pollute. The list and info commands split the two directions of the question, what is available versus what you have. A package can also come straight from a URL or a local file, and the installation can be given a direct release link, and one installed from a GitHub or GitLab release keeps tracking that release, which is the mechanism behind the update command for those packages.

Verification, delta updates and the system integration it does attempt

The feature table lists the security and integration properties, and two of them matter most. The first is secure by default, with checksums and signatures verified before anything is installed, and the dependency list shows the machinery behind that, with minisign-verify for signature checking and both blake3 and sha2 for hashing. The second is delta updates, where AppImages advertising a zsync feed are updated by fetching only the parts that changed, so a monthly update of a large application transfers a few megabytes rather than all of it. System integration is the feature that is honest about its limits. Desktop entries, icons, man pages and shell completions land where your system already looks, and the word is land where your system already looks rather than into your system directories, because without superuser Soar cannot write there. That is the real constraint of a rootless package manager: it can put a binary on your PATH and a desktop entry in your home directory, but it cannot register a system service or install into /usr. The feature list also claims fast, with parallel downloads and low-overhead package operations.

Forge rate limits are the operational gotcha

One operational detail is called out because it will otherwise surprise you. Installing or updating from a release uses that forge's API, which is rate limited. GitHub allows 60 requests an hour unauthenticated, which the documentation says is easy to reach, so you should set GITHUB_TOKEN or GH_TOKEN if you track several packages that way. GitLab counts per minute and is rarely a problem, but honours GITLAB_TOKEN and GL_TOKEN all the same. The token naming is a little inconsistent across the two forges, which is worth knowing before you spend an afternoon wondering why your GitLab updates are not rate limited the same way. The environment variable names are also the tool's, not the forges', so they do not collide with anything you already export for git operations. This is the sort of thing that only appears when you actually track a handful of packages from GitHub releases rather than from the default repository.

A Rust workspace with a database, a sandbox and a search index

The Cargo workspace shows how much is going on under the hood, with eleven member crates named for their role, covering the CLI, the configuration, the core, a database layer, downloads, events, operations, packages, the registry and utilities. Three of the dependencies explain the design better than the feature list. Diesel is the ORM, with a bundled SQLite build, and the migrations crate alongside it, so the installed package list is a real database rather than a text file. Landlock is a Linux kernel sandboxing mechanism, which is how a package manager that needs no root can still restrict what an installed program can reach. And nucleo-matcher is a fuzzy matching library, which is what the search command uses, alongside indicatif for progress display and rayon for parallel work. The SQLite choice is the interesting one for a tool that claims to touch no distribution packages, because it means the state is a self-contained database in your home directory that you can delete. The workspace requires Rust 1.93.1 as its minimum supported version, and the readme states that number plainly.

Editorial conclusion

Soar is a good fit for a Linux user who wants a tool available on every machine they log into, who does not want to maintain distribution packages, and who is comfortable with the trust model of a metadata repository. It is the wrong tool if you want distribution packages, because Soar explicitly does not touch them, and it is the wrong tool if you need the system integration that a distribution package gives you for free, since the desktop entries and icons Soar installs are a best-effort approximation. It is also the wrong tool if you need to install from a source tarball, since Soar installs rather than builds. Before adopting it, read the repository configuration docs, because soarpkgs is only the default and you can add a third party one or run your own, and set a forge token if you track several packages from GitHub releases, because the unauthenticated rate limit is easy to reach. The project is MIT licensed, the last push was on 2026-10-20, and the current release is v0.13.4 from 2026-09-05 with nightly builds published nightly.

Frequently asked questions

Official sources

1. License: MIT
2. pkgforge/soar on GitHub
3. Project website
4. README
5. Releases