What is Snaproot?

A full breakdown of what it does, why it exists, and how it works under the hood.

The problem it solves

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.

Without Snaproot

Find the right download page
Pick the right OS / architecture
Run an installer wizard
Enter admin password
Manually add it to PATH
No checksum verification
Repeat on every machine

With Snaproot

snprt install owner/app
OS detected automatically
No wizard, no clicks
No admin ever required
PATH updated automatically
SHA-256 verified before install
Same command on every machine

The security model — The Shield

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.

Why this matters: A checksum mismatch means the file you downloaded is not the same file the developer published. That could mean a compromised download mirror, a corrupted transfer, or something more serious. Snaproot refuses to install it either way.

The registry only accepts download URLs from a fixed allowlist of trusted hosts: github.com, gitlab.com, codeberg.org, gitea.io, and Cloudflare Pages / Vercel / Netlify domains for sovereign mirrors. Snaproot does not host binaries itself — it points to versioned, immutable release assets 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 provider release URLs remain valid.

For apps built through the Sovereign Forge (see below), binaries are served directly from the Snaproot CDN path on Railway. These are still SHA-256 verified at download time by the CLI — the trust model is identical.

The Sovereign Forge — server-side builds

The fastest path from source code to a published app. You provide a public Git URL or upload a source zip on the Publish page — Snaproot's build engine handles the rest.

Source submitted

You paste a GitHub / GitLab / Codeberg URL, or drop a source archive (up to 500 MB). No toolchain required on your machine.

Automatic language detection

The Forge scans the repository for buildable entry points — Go, Rust, .NET, Node.js, C/C++, Python, Zig, Java, Kotlin. Multi-project repos surface a picker so you choose what to build.

SFE Doctor — dependency repair

The build engine recognises missing headers, linker errors, and unknown packages and installs them automatically via apt-get. Most builds succeed without any configuration.

Multi-platform binaries compiled

Linux, Windows, and macOS binaries are produced in a single job. Go and .NET build all three; Rust, C++, Python, and Zig produce a Linux binary by default.

Registered instantly

SHA-256 checksums are recorded and the app appears in the registry immediately. snprt install you/app works as soon as the build finishes.

Interpreted languages: Python projects are frozen into a single self-contained binary using PyInstaller or Nuitka — no Python runtime is required on the end user's machine.

The permission system

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.

How installing works — step by step

CLI contacts the registry

Calls GET /api/v1/apps/owner/app/releases/latest to fetch app metadata — version, download URL, checksum, and permissions.

Permission prompt

If the app declared any permissions, they are shown in the terminal before anything is downloaded. You confirm or cancel.

Binary downloaded into memory

The binary is fetched from the GitHub Release URL stored in the registry. It is held in memory, not written to disk yet.

The Shield — checksum verified

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.

Binary written to ~/.snprt/bin/

Only after verification passes is the file written to your user profile directory — no system directories, no admin required.

PATH updated

~/.snprt/bin is added to your user PATH environment variable if it isn't already. No terminal restart needed — use snprt run app immediately.

The Ghost Forge — CI-injected publishing

For developers who want builds to run inside their own provider CI (GitHub Actions, GitLab CI, Forgejo/Gitea), the Ghost Forge injects a build workflow directly into your repository. This is the alternative to the Sovereign Forge above — same registry outcome, different build runner.

What snprt push does

When you run snprt push 1.0.0 in your project directory:

→

Injects the workflow

Writes forge CI config into your repo: .github/workflows/snprt-forge.yml for GitHub/Forgejo, or .gitlab-ci.yml for GitLab.

→

Syncs your registry token

Sets SNPRT_TOKEN in your provider secrets (GitHub, GitLab, or Forgejo) so CI can notify the registry after build.

→

Tags and pushes

Creates a git tag v1.0.0, commits pending changes, and pushes the tag to your matching remote(s), which triggers CI.

→

Forge builds Native AOT binaries

Your CI picks up the tag and runs parallel jobs for Windows, Linux, and macOS, producing self-contained Native AOT binaries. No .NET runtime required on the end user machine.

→

Release artifacts created

The Forge attaches binaries to a versioned release on your provider. Files are tied to a specific git tag and commit.

→

Registry notified

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.

The manifest — snprt.yml

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: false

The 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 registry

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.json

The registry never stores binaries. It stores metadata — app name, owner, version, platform (rid), filename, checksum, and the provider release download URL. The binary always lives on your forge release assets. The registry is just the catalogue.

Why no admin password

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.

Why $0 infrastructure

Snaproot is designed to run on nothing:

Binaries (Ghost Forge path) — hosted on provider release assets (GitHub, GitLab, Forgejo/Codeberg). Zero storage cost to Snaproot.
Binaries (Sovereign Forge path) — served from the Railway CDN volume. Persistent storage attached to the registry process.
Registry API — a single lightweight ASP.NET Core process. Runs on Railway's hobby tier.
Build engine — the Sovereign Forge runs in-process on the same Railway instance, sequentially, with a 10-minute per-job timeout.
Ghost Forge CI — GitHub Actions, GitLab CI, or Forgejo/Gitea Actions (provider-managed, free minutes).
Website — static HTML on Cloudflare Pages. Free.
No external JS — no tracking, no analytics, no third-party scripts beyond Phosphor Icons and Google Fonts.

The social layer

Snaproot also treats every app as a social topic. The registry supports stars, comments, profile stats, and follows so developers can discuss apps where they are installed.

Stars — quick signal for useful apps and adoption.
Comments — app-specific threads for questions and release feedback.
Follows — subscribe to developers you trust.
Profiles — follower, following, and star totals for each user.

CLI commands for this layer: snprt star, snprt comment, snprt comments, snprt follow, and snprt profile.

What it is not

Not a package manager like npm, pip, or cargo — it installs pre-built binaries, not library dependencies.
Not a sandbox — installed apps run with your full user permissions (though permissions are declared upfront and enforced enforcement is on the roadmap).
Not a store — there is no approval process, no review, no curation team. Anyone with a valid login can publish.
Not for system software — it installs user-space binaries only, never to system directories.

Read the source on GitHub · Get started · Browse feed