Sandstorm: A Self-Hosted App Package Manager Built Around Grain Isolation

The Problem Sandstorm Solves: One Server, Many Apps, One Login

Running several small web apps on one machine normally means several installs, several upgrade paths, several sets of credentials, and a shared filesystem where any app can read any other app's data. Sandstorm's answer is to treat web apps the way a phone treats applications. The README says you install apps to create documents, spreadsheets, blogs, git repos, task lists and more, "as easily as you'd install apps on your phone." The audience is the person who already runs a Linux server and wants a personal or small-team productivity stack without standing up a separate virtual host, database and auth layer for each tool. It is not aimed at developers who want to embed a library in their own code. The unit of distribution here is a packaged app, not a package on npm.

Grains, Packages and the Sandbox Model

The project describes itself as a security-hardened web app package manager, and the isolation unit is the grain, which the documentation treats as a single document or workspace instance created by an installed app. The repository topics list seccomp and Cap'n Proto, which points at the two halves of the mechanism: seccomp restricts the system calls a packaged app can make, and Cap'n Proto is the serialization layer the project uses for its internal interfaces. The practical consequence is that apps do not talk to the host filesystem directly. They run inside a sandbox and reach the outside world through the platform's interfaces. This is why the packaging step matters more than it does in a typical self-hosted app: the package declares what the app needs, and the platform enforces it. The README does not spell out the boundary conditions of that sandbox, and the how-it-works page is linked rather than reproduced, so anyone evaluating the security model has to read docs.sandstorm.io and sandstorm.io/how-it-works to see exactly which syscalls are permitted.

Installing: What the Repository Actually Tells You

The README is unusually thin on commands. It states that Sandstorm "can be installed on any x86-64 Linux system" and then defers: "See installation instructions in the Sandstorm documentation." There is no curl pipe, no apt line, no Docker invocation in the repository README itself. That is a deliberate choice by the maintainers, and it means the install surface is the docs site, not the git checkout. The same pattern repeats for usage, packaging and the security model: each section of the README is one sentence plus a link. For an operator this is a real friction point, because the repository alone does not tell you how to get a running server. For a contributor it is less of a problem, since CONTRIBUTING.md is linked directly from the README and the developer hub covers app packaging. Treat the GitHub repository as the source of the platform and the docs site as the source of the procedure.

Packaging Apps Is the Real Adoption Cost

Sandstorm is a package manager, so its value depends on the supply of packages. The README links to the app store at apps.sandstorm.io with individual entries for documents, spreadsheets, blogs, git repos and task lists, which tells you the catalogue exists and is curated by URL rather than by count. What the README does not provide is a packaging tutorial; that lives in the developer hub. If the app you want is already packaged, adoption is mostly an installation exercise. If it is not, you are signing up to learn the Sandstorm packaging format, which is a different skill from writing a Dockerfile or a systemd unit. This is the dividing line between a weekend project and a maintenance commitment, and the README gives no estimate of how long packaging takes.

Where Sandstorm Is the Wrong Tool

The x86-64 constraint is explicit in the README, so ARM hosts, including most single-board computers and many current ARM cloud instances, are out of scope according to the material available. The sandbox is also the point of the project, and a sandbox that restricts system calls will reject apps that need capabilities outside its model: anything requiring raw sockets, custom kernel modules, or direct device access is a poor fit by design. Sandstorm is also the wrong choice when you need one app to read another app's data as a first-class feature. The grain model assumes isolation, so cross-app integration has to go through whatever sharing mechanism the platform provides rather than through a shared directory. Finally, the README offers no release history, and the release list was not retrieved, so there is nothing here to tell you how frequently the platform ships updates.

How It Differs From Running Docker Compose With a Reverse Proxy

The obvious comparison is a Compose file plus a reverse proxy and something like Authelia in front. That stack gives you process isolation through containers and a shared login, but the apps inside it are ordinary web apps with ordinary filesystem access inside their containers, and you configure each one individually. Sandstorm inverts the default: apps are packaged against a platform API, the platform owns identity and sharing, and the sandbox is enforced by the runtime rather than by how carefully you wrote the compose file. The trade-off is flexibility for uniformity. A Compose stack will run almost any container image; Sandstorm will run apps that have been packaged for it. If your priority is running arbitrary upstream images unchanged, Compose is the better fit. If your priority is that installing a new app does not mean a new auth configuration and a new data directory to back up, Sandstorm's model is the one designed for that.

Maintenance, Upgrades and the Licence Question

The repository shows a last push in September 2026 and is not archived, which is the only maintenance signal available in the supplied material; there is no release list to read, so upgrade cadence cannot be judged from this data alone. Upgrade cost concentrates in two places: the platform itself, and the packages installed on it. Packaged apps depend on the platform API, so a platform upgrade can require package updates, and the README does not describe a compatibility policy. On licensing, the repository reports NOASSERTION, which means GitHub could not map the LICENSE file to a recognised identifier. That is not the same as having no licence, and it is not the same as a permissive one. Before you fork, redistribute or bundle Sandstorm, read the LICENSE file in the repository and the terms on sandstorm.org, and if the terms affect a commercial deployment, get your own legal reading rather than relying on a repository metadata field.

Editorial conclusion

Adopt Sandstorm if you want one x86-64 Linux box to host many small web apps under a single account system and you are willing to learn the packaging format; skip it if your workloads need kernel features the seccomp sandbox blocks or if you cannot run a 64-bit Linux host. Verify first that a current package exists for the apps you need, that your host meets the installation prerequisites in the Sandstorm docs, and what the repository's NOASSERTION licence field actually resolves to in the LICENSE file before you redistribute anything.

Official sources

1. Issues
2. Project website
3. README
4. sandstorm-io/sandstorm on GitHub