A full breakdown of what it does, why it exists, and how it works under the hood.
Installing software on a computer is still surprisingly painful. You find a website, figure out which download is the right one for your OS, click through an installer, enter your admin password, and hope nothing was bundled in that you didn't ask for. If you want to do this on ten machines, or automate it, or give a colleague a single command to reproduce your setup — it falls apart.
Snaproot (snprt) is a command-line app manager that reduces this to one command. It handles downloading, verifying, and installing — without touching system directories, without requiring admin rights, and without asking you to trust a random installer wizard.
snprt install owner/app
Every app in the Snaproot registry has a SHA-256 checksum stored alongside it.
When you run snprt install, the CLI downloads the binary and computes its checksum before writing a single byte to your disk.
If the checksum doesn't match what the registry recorded at publish time, the install is aborted immediately.
The registry only accepts download URLs that originate from github.com. Snaproot does not host binaries itself — it points to GitHub Releases, which are versioned, immutable, and tied to a specific git tag. This means there is no Snaproot server that could be compromised to serve you a bad binary. Even if the registry was taken down, the GitHub Release URLs remain valid.
Before downloading anything, Snaproot shows you exactly what an app has declared it needs access to.
These permissions come from the developer's snprt.yml manifest and are stored in the registry at publish time.
You approve or deny before any bytes are downloaded.
| Permission | What it means | Risk |
|---|---|---|
| Network | The app can make HTTP/HTTPS requests to the internet | Low |
| Filesystem | The app can read and write files outside its install directory | Low |
| Environment Variables | The app can read environment variables from your shell | Low |
| Admin Rights | The app requests elevated system privileges | High — shown as a warning |
Apps that declare no special permissions install silently. Apps that declare admin rights show a high-risk warning and require explicit confirmation. Permissions are informational today — enforcement is on the roadmap.
Calls GET /api/v1/apps/owner/app/releases/latest to fetch app metadata — version, download URL, checksum, and permissions.
If the app declared any permissions, they are shown in the terminal before anything is downloaded. You confirm or cancel.
The binary is fetched from the GitHub Release URL stored in the registry. It is held in memory, not written to disk yet.
SHA-256 of the downloaded bytes is computed and compared to the registry record. If they don't match, the install aborts and nothing is written.
~/.snprt/bin/
Only after verification passes is the file written to your user profile directory — no system directories, no admin required.
~/.snprt/bin is added to your user PATH environment variable if it isn't already. No terminal restart needed — use snprt run app immediately.
Most app distribution tools make the developer do a lot of manual work: build the binary, zip it, create a release, upload the asset, compute the checksum, register it somewhere. Snaproot automates all of that through a system called the Ghost Forge — a GitHub Actions workflow injected into your repo.
When you run snprt push 1.0.0 in your project directory:
Writes .github/workflows/snprt-forge.yml into your repo if it doesn't exist, or updates it to the latest version if it's outdated.
Uses the gh CLI to set SNPRT_TOKEN as a GitHub Secret in your repo. The Forge needs this to notify the registry after the build.
Creates a git tag v1.0.0, commits any pending changes, and pushes the tag to GitHub. This is what triggers the Forge.
GitHub Actions picks up the tag and runs three parallel jobs — Windows, Linux, and macOS — each producing a self-contained native binary via dotnet publish -r <rid> /p:PublishAot=true. No .NET runtime required on the end user's machine.
The Forge attaches all three binaries to a versioned GitHub Release. The files are immutable from this point — tied to a specific git tag and commit.
The Forge reads your snprt.yml for the app description and permissions, computes the SHA-256 of each binary, and calls POST /api/v1/registry/notify on the Snaproot registry. The app is immediately discoverable.
Every app published through Snaproot has a snprt.yml file in the root of its repository.
This is the single source of truth for what the app is and what it needs.
Created by snprt init.
name: a-z
description: A sandboxed terminal web browser built with Rust
permissions:
network: true
filesystem: false
environment_variables: false
admin_rights: falseThe Forge reads this file during the build and includes the permissions and description in the registry notification. No YAML parser — the Forge uses regex matching so there is no additional dependency in the build step.
The Snaproot registry is a minimal ASP.NET Core 10 API running on a single server.
It stores app metadata as flat JSON files — no database.
Each app has a latest.json and a versions/ directory containing one JSON file per release.
registry/
namit_a-z/
latest.json ← always points to newest release
versions/
0.1.0.json
0.2.0.json
0.2.1.jsonThe registry never stores binaries. It stores metadata — app name, owner, version, platform (rid), filename, checksum, and the GitHub Release download URL. The binary always lives on GitHub. The registry is just the catalogue.
Most installers write to C:\Program Files or /usr/local/bin — system directories that require elevated privileges.
Snaproot installs everything to ~/.snprt/bin inside your own user profile.
You own that folder. No elevation needed, ever.
This also means every app is installed per user, not system-wide.
Multiple users on the same machine have separate installs.
Uninstalling is just deleting the file from ~/.snprt/bin.
Snaproot is designed to run on nothing:
Read the source on GitHub · Get started · Browse apps