# Sandstorm: The Web App Package Manager Built Around Per-App Isolation > Sandstorm is an open-source, self-hostable web productivity platform for x86-64 Linux that treats every app as a separately sandboxed package. It gives engineers and privacy-focused teams a way to run documents, spreadsheets, git repos, and task lists on their own server while strictly separating each application from the others. **sandstorm-io/sandstorm** — Sandstorm is a self-hostable web productivity suite. It's implemented as a security-hardened web app package manager. | Actively sponsored by our friends at TestMu AI - Repository: https://github.com/sandstorm-io/sandstorm - Website: https://sandstorm.org - Stars: 7,078 · Forks: 714 - Language: JavaScript - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/sandstorm-io-sandstorm ## A Package Manager Model for Self-Hosted Web Apps Most self-hosted productivity tools ship as a single, tightly coupled application. Sandstorm takes a different approach: it is a platform, and each productivity tool (documents, spreadsheets, a blog engine, a git host, a task manager) is a separately installed package. The README describes this as a security-hardened web app package manager, and the analogy to a phone app store is deliberate. Users browse apps.sandstorm.io, pick what they want, and install it to their Sandstorm instance much as they would install a mobile app. The platform handles isolation; the individual app author does not need to think about it. This design has a concrete consequence for security. If one installed app has a vulnerability, the blast radius is limited to that app's container. The Sandstorm documentation covers its security practices at docs.sandstorm.io/en/latest/using/security-practices/, and the SECURITY.md file in the repository provides the disclosure policy. ## How Sandstorm Isolates Each Installed App The README describes Sandstorm as security-hardened, and the repository structure reflects a system built to enforce that boundary. The src/ directory contains the core platform code, and the shell/ directory holds the Meteor-based web shell that users interact with. The Makefile references the Clang/LLVM toolchain for building native components, as well as Cap'n Proto (a data serialization library focused on efficiency and security), and the Ekam build system. These choices point to a platform that takes low-level system concerns seriously rather than relying entirely on application-level trust. Each Sandstorm grain (the term the platform uses for a running app instance) runs in its own isolated environment. The documentation at sandstorm.io/how-it-works explains the mechanism. From a practical standpoint this means that a note-taking app and a git repository on the same Sandstorm installation cannot directly touch each other's data even if both are compromised. ## Getting Sandstorm Running on an x86-64 Linux Server Sandstorm runs only on x86-64 Linux. The README does not include inline installation commands; it directs users to the documentation at docs.sandstorm.io/en/latest/install/. An install.sh script is present in the repository root for those who prefer to run it directly from source. The repository also contains a Vagrantfile for testing in a virtual machine, and the docs/ directory is built with MkDocs (mkdocs.yml is in the root). The Makefile exposes a set of developer-facing targets, including pulling the required roles and running the linter, but these are for contributors building Sandstorm from source rather than end users installing the binary. The installation documentation covers both the quick path (using the hosted install.sh) and the full source build. For most self-hosters the hosted script path is the intended route. Once installed, the app catalog at apps.sandstorm.io provides one-click installation of packaged apps. The README lists documents, spreadsheets, blogs, git repos, and task lists as examples available through that catalog. ## Apps Available in the Sandstorm Catalog The Sandstorm ecosystem depends on developers packaging their apps in the Sandstorm Package (SPK) format. The Makefile references meteor-spk version 0.6.0 as the tool used to create these packages from Meteor applications. The developer hub documentation at docs.sandstorm.io/en/latest/developing/ covers the packaging process. The catalog at apps.sandstorm.io includes apps for creating documents, spreadsheets (linked directly from the README), blogs, git repositories, and task lists. This is both the appeal and the constraint: the catalog is finite. An engineer who needs a specific tool that has not been packaged for Sandstorm cannot simply drop in an arbitrary Docker container or a standard web app. The packaging step is real work, and apps that have not been updated to work with recent Sandstorm releases may simply not install. The repository has no GitHub releases, which means there is no versioned release channel tracked on GitHub. The last push to the repository was on 2026-09-10, and the CHANGELOG.md in the root records changes. ## Packaging Your Own App for the Platform Sandstorm's developer documentation describes how to wrap an existing web application into a Sandstorm package. The Makefile shows that meteor-spk is used for Meteor-based applications, suggesting that the primary supported packaging workflow was built around Meteor. Applications not written in Meteor may face more packaging complexity. The repository includes a roadmap/ directory for tracking intended future directions. The CONTRIBUTING.md file and the community discussion group (hosted at groups.io/g/sandstorm-dev-group, per the README) are the channels for contributors. For engineers who want to package an app that is not in the catalog, understanding the grain model and the SPK format is the first step. ## Where Sandstorm Falls Short The clearest limitation is platform scope: x86-64 Linux only. There is no ARM support, no macOS or Windows hosting, and no container registry approach that would let you deploy to something like Kubernetes. An organization that has standardized on ARM instances or a non-Linux platform is blocked outright. The app catalog constraint is the second limitation. Sandstorm cannot host arbitrary web apps without packaging. If a team's critical tool has not been packaged and is unlikely to be, Sandstorm is the wrong fit. The repository has no GitHub releases, so tracking stable versions requires watching the repository directly or reading CHANGELOG.md. Sandstorm is also a distinct operational choice: it is not a Kubernetes workload or a Docker Compose service. It installs as a system service on a Linux host. Teams that have invested in container orchestration infrastructure and want every service to fit that mold will find Sandstorm sits outside their model entirely. ## Sandstorm vs. Nextcloud: Different Bets on Self-Hosted Productivity Nextcloud is the most widely known self-hosted productivity platform and takes the opposite architectural bet from Sandstorm. Nextcloud is a monolithic PHP application with a plugin system: all apps run in the same process and share the same database. This makes Nextcloud portable across many web server configurations and gives it a large plugin ecosystem, but it means a vulnerable plugin can affect the entire installation. Sandstorm's per-app isolation means the attack surface of one app does not automatically extend to other apps. The trade-off is that the catalog is smaller and the packaging requirement is strict. Nextcloud runs on PHP-compatible shared hosting or Docker; Sandstorm requires a dedicated x86-64 Linux host and does not fit into a generic LAMP or LEMP stack. The choice between them comes down to whether the team values breadth of available apps (Nextcloud) or strict per-app isolation with a curated catalog (Sandstorm). ## Conclusion Sandstorm suits an engineer or small team that wants a personal cloud on a single Linux machine, values strict per-app isolation over a monolithic shared database, and can accept the x86-64 Linux constraint. Anyone needing ARM support, Windows or macOS hosting, or a polished managed upgrade path should look elsewhere. Before adopting, verify that the apps.sandstorm.io catalog covers your use cases, because the packaging model means you cannot simply deploy an arbitrary web app without wrapping it as a Sandstorm package first. ## FAQ ### Does Sandstorm run on ARM servers or macOS? No. The README states that Sandstorm runs on x86-64 Linux only. ARM servers, macOS, and Windows are not supported. ### Can I install any web app on Sandstorm, or only apps from the catalog? Only apps packaged in the Sandstorm Package (SPK) format can be installed. The developer documentation at docs.sandstorm.io/en/latest/developing/ covers how to package an app. Apps not in the catalog at apps.sandstorm.io require packaging before they can run on the platform. ### What license does Sandstorm use? The Makefile header identifies the Apache License, Version 2.0. The LICENSE file in the repository contains the full text. ## Sources - [Issues](https://github.com/sandstorm-io/sandstorm/issues) - [Project website](https://sandstorm.org) - [README](https://github.com/sandstorm-io/sandstorm/blob/master/README.md) - [sandstorm-io/sandstorm on GitHub](https://github.com/sandstorm-io/sandstorm) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sandstorm-io-sandstorm