Sandstorm

An honest look at Sandstorm — what it got right, why the company failed, and whether the community-maintained project is still worth running in 2026.

TL;DR

• What it is: A self-hostable web app platform that turns each document, chat room, or file into an isolated security container called a “grain.” Think an app store for self-hosted apps, where each running instance is sandboxed by default [README][5].
• Who it’s for: Privacy-focused individuals and small organizations who want to run open source web apps (Wekan, Etherpad, Rocket.Chat) without managing each one separately — and who value a strong security model over a polished deployment experience [1][website].
• Current status: Community-maintained project under Open Source Collective, not a company. The original startup failed to raise a Series A in 2016. The hosted cloud offering (Sandstorm Oasis) has shut down. The project moved from sandstorm.io to sandstorm.org in January 2024 [5].
• Key strength: The grain-based security model is genuinely clever — Sandstorm claims 95% of security vulnerabilities in apps are automatically mitigated because each document instance runs in its own sandbox [website].
• Key weakness: The project is in a kind of managed decline. No company funds it, the original lead developer handed off maintainership, and the ecosystem of packaged apps hasn’t kept pace with modern alternatives [2][5].

---

What is Sandstorm

Sandstorm is a self-hosting platform that works like an app store for your own server. You install Sandstorm once on a Linux machine, then browse the Sandstorm App Market and install individual apps — document editors, task managers, chat tools, git repos — with a few clicks. Each app installation is straightforward; you’re not juggling Docker Compose files for six different projects.

What makes it different is the security architecture. Every item you create — a document, a chat room, a kanban board — becomes a “grain.” Each grain runs in its own sandboxed container that cannot make outbound network connections without explicit permission [website]. That’s a real architectural choice, not marketing. A bug in the Etherpad app inside Sandstorm cannot be used to exfiltrate your Wekan boards, because they don’t share a process or a network path. The website’s claim that “95% of security vulnerabilities are automatically mitigated” isn’t completely crazy given how many app-level vulnerabilities depend on lateral movement or unintended network access [website][1].

The project was founded around 2014 as a startup, ran a crowdfunding campaign, raised VC money, and aimed for a Series A in 2016. That round never happened. The team shrunk, Sandstorm went into maintenance mode, and the hosted service (Sandstorm Oasis) eventually shut down [5]. In January 2024, original co-founder Kenton Varda formally transferred maintainership to a community group led by Jacob “ocdtrekkie” Weisz, under the Open Source Collective. The project now lives at sandstorm.org [5].

As of this review, the GitHub repository shows 7,014 stars. The rate of active development is modest compared to a company-backed product.

---

Why people choose it

The honest answer is that most people who use Sandstorm chose it several years ago and have stayed because it works well enough and the migration cost is real.

The GIGAZINE review [1] from late 2023 captures what the onboarding looks like: one curl command, a few prompts about your preferred subdomain (the project provides free sandcats.io domains), an email address for Let’s Encrypt, and you’re running. The reviewer was able to self-host WordPress, MediaWiki, GitLab, and chat apps without managing any of them individually. That’s a real value proposition — one install path instead of six.

The EdTech Factotum piece [2] is the most candid retrospective. The author had been using Sandstorm since 2015, deployed it for the OpenETC educational collaborative, and reached for it every week as “a swiss army knife of disposable web apps.” When Oasis shut down and it became clear the project was stalling, the reaction wasn’t “this was bad” — it was genuine disappointment that something useful had failed to find a sustainable model. The author notes: “I am a bit surprised that Sandstorm never caught on… Here was a security focused application that made using other open source web-based apps both easy and secure. It had what looked like a good SaaS business model developing.” [2]

The Quantum Hosting review [4] is the harsh counterpoint: installed on a 1GB RAM VPS, the platform consumed all available memory during install and left the server non-responsive for eight minutes. Post-install, load stayed at 7–8 with no apps running. Their verdict was blunt — it “does not deserve any attention” on low-spec hardware [4]. That’s a legitimate warning. The minimum spec of 1GB RAM (2GB recommended per the README) isn’t conservative enough if you’re on the actual minimum. Budget 2GB and ideally 4GB if you plan to run more than a few active grains.

---

Features

Core platform:

• App Market with installable apps covering documents (Etherpad), spreadsheets, blogs, git repos, task management (Wekan), chat (Rocket.Chat), file storage (Davros), and more [README][website]
• Grain-based sandboxing — each running document/chat/file is an isolated container [website]
• Single sign-on: log in to Sandstorm once, all apps know who you are [website]
• Unified sharing: one interface to share any grain with others, consistent access controls across all apps [website]
• Powerbox: lets apps interact — e.g., a form that feeds into a spreadsheet — through a permission-granting UI [website]
• Free sandcats.io subdomain with automatic SSL via Let’s Encrypt [1]
• LDAP and SAML support (was in “Sandstorm for Work” beta)
• Organization management — restrict to users from a single email domain [1]
• Email-based login (Gmail not supported at last check; standard SMTP providers work) [1]

What the security model actually does:

• Each grain has no outbound network access by default [website]
• Access to grains is private until explicitly shared [website]
• Revocable access — Sandstorm tracks who has access to each grain and lets admins revoke it [website]
• The consequence: a compromised app instance cannot pivot to other data on your server

What’s missing compared to modern alternatives:

• No built-in container orchestration — Sandstorm is its own thing, not Kubernetes-compatible
• x86-64 Linux only — no ARM support [README]
• Apps must be packaged specifically for Sandstorm; you can’t just throw a Docker image at it [5]
• The App Market has a limited and aging catalog — active packaging of new apps is slow under community maintenance

---

Pricing: SaaS vs self-hosted math

Sandstorm has no SaaS tier as of 2024 — Oasis shut down. The only option is self-hosted.

Self-hosted:

• Software: free (open source)
• Minimum viable VPS: 2GB RAM, $5–12/mo on Hetzner or Contabo
• Free sandcats.io subdomain with SSL included — you don’t need to own a domain to get started [1]

What you replace: Sandstorm’s value proposition isn’t replacing one SaaS product — it’s replacing several at once. If you currently pay for separate task management ($10/mo), document editing ($10/mo), and a chat tool ($15/mo) in the SMB tier, you’re spending $35/mo for tools you could run inside Sandstorm on a $10 VPS. The math works, but only if the Sandstorm-packaged versions of those apps are adequate replacements for what you’re currently paying for.

Where the comparison breaks down: The apps available in Sandstorm’s App Market are open source alternatives, not drop-in functional equivalents. Wekan is not Jira. Etherpad is not Google Docs with real-time AI suggestions. If your team is deeply embedded in the UX patterns of modern SaaS tools, the productivity regression is real.

---

Deployment reality check

Installation is a single curl command — curl https://install.sandstorm.io | bash — and the setup wizard handles the rest [1]. Compared to manually configuring Docker Compose stacks for six different apps, this is genuinely easier. For the apps Sandstorm supports, deployment is closer to “install from an app store” than “ops work.”

What you actually need:

• x86-64 Linux server with kernel 3.10 or later [README]
• 2GB RAM minimum (4GB if you plan to run multiple active apps)
• A domain or willingness to use sandcats.io subdomain
• An SMTP server (not Gmail) for email-based login [1]

What can go sideways:

• RAM is not optional. The Quantum Hosting review is a real warning — a 1GB VPS is unusable [4]. If your server is borderline, budget up first.
• App packaging is a bottleneck. You can only install apps that have been packaged for Sandstorm. If you want a specific tool that isn’t in the App Market, you cannot just use it. Packaging apps for Sandstorm is not a quick afternoon project.
• Community maintenance pace. The project is volunteer-run. If a packaged app breaks or has a security issue, the timeline for a fix depends on volunteer availability [5][2]. This is a real operational risk for anything you depend on.
• The auto-update situation changed. When Sandstorm was a company, auto-updates were enabled by default. Under the new community organization, the policy is that users must opt in to auto-updates from sandstorm.org — explicitly because the stakes of a botched update are high for users that include organizations and government agencies [5]. This is responsible, but it means you own your update management.
• Active development is slow. The GitHub repository hasn’t had the velocity of an actively-invested project. If you’re looking for rapid feature development or quick bug fixes, this is not that.

Realistic time estimate for a technical user: 30–60 minutes to a working install. For a non-technical person following a guide with a compatible VPS: 1–3 hours including domain and SMTP setup. The installation is simpler than most self-hosted software stacks, which is one of Sandstorm’s genuine wins.

---

Pros and cons

Pros

• The security model is real. Grain-based sandboxing is not marketing — it’s an architectural decision that meaningfully limits blast radius from app-level vulnerabilities [website][5]. For privacy-conscious users, this matters.
• Unified app management. One install, one access control system, one login for multiple apps. No juggling six separate docker-compose files and six separate admin panels [1][website].
• Genuinely easy initial install. One curl command and a wizard [1]. Simpler than competitors like Cloudron or Yunohost for supported apps.
• Free sandcats.io subdomain + SSL. You can get a working, SSL-enabled server without owning a domain [1].
• Unified sharing model. Sharing a document across Sandstorm apps works the same way every time. Access is revocable. Who has access to what is visible to admins [website].
• 7,014 GitHub stars — not a fringe project. Has real users who have deployed it in production [merged profile].

Cons

• The project is in managed decline. The company is gone, the hosted service is gone, and the maintainer is now a community volunteer group [5][2]. This is the central fact about Sandstorm in 2026.
• RAM requirements bite hard. A 1GB VPS is not viable. The Quantum Hosting review documents a real install failure on minimum specs [4].
• App ecosystem is frozen in amber. The App Market reflects apps packaged years ago. New tools aren’t getting packaged quickly. If you need something specific that isn’t in the market, you’re out of luck unless you package it yourself.
• x86-64 Linux only. No ARM support, which eliminates cheap ARM VPS options and Raspberry Pi deployments [README].
• Email login limitations. Gmail isn’t supported as an SMTP provider — you need a real SMTP service [1]. A minor friction point, but real for first-timers.
• Not Docker-compatible. Sandstorm’s sandboxing model is its own thing. You can’t use existing Docker Compose apps without Sandstorm-specific packaging [5]. This limits the app selection to whatever the community has packaged.
• Update management is now your responsibility. Opt-in auto-updates from the community project mean you need to track releases yourself [5].
• No commercial support. Nothing to call if it breaks. Community forums and the discussion group are your only options [README].

---

Who should use this / who shouldn’t

Use Sandstorm if:

• You want to run multiple open source apps (task management, docs, chat, git) on one server with a unified login and access control system.
• Security hardening is a priority and you trust the grain model more than managing app isolation yourself.
• You have a 2GB+ VPS already running, are comfortable with Linux, and want a simpler alternative to managing several docker-compose stacks.
• You’re running an educational or research environment where data privacy matters and the app catalog covers your needs.

Skip it and look at Cloudron or Yunohost if:

• You want an actively-maintained commercial or community product with a larger app catalog and current development momentum.
• You need to run apps that aren’t in Sandstorm’s App Market and don’t want to package them yourself.

Skip it and use individual Docker deployments if:

• You need specific, modern versions of tools (Nextcloud, Gitea, Vaultwarden) and want to control updates directly.
• You have engineering resources and want composable infrastructure rather than an opinionated platform.

Skip it entirely if:

• You’re on a 1GB RAM server [4].
• You’re betting operational infrastructure on it — the community maintenance model is not the right foundation for a business-critical system without a fallback plan.

---

Alternatives worth considering

• Cloudron — the most direct commercial alternative. Actively maintained, larger app catalog, 30+ day free trial, $15–30/mo after. Explicitly mentioned by EdTechFactotum as the migration target after Sandstorm [2].
• Yunohost — free, community-maintained like Sandstorm but with more active packaging activity and a larger app catalog. Similar philosophy, different architecture.
• Cosmos Cloud — newer entrant in the “one server, many apps” space with a modern UI and active development.
• Individual Docker Compose stacks — more ops work, full control, works with any app. Right answer if your app requirements don’t fit a platform’s catalog.
• Umbrel — focused more on home lab and personal use; simpler but narrower scope.

None of these replicate Sandstorm’s grain-based security model exactly. If that model is the reason you want Sandstorm, you’re not going to find a drop-in replacement — it’s a genuine architectural differentiator that competitors haven’t copied.

---

Bottom line

Sandstorm solved a real problem well: it made running multiple self-hosted apps easier than managing them separately, while adding a security architecture that actually reduced risk rather than just promising to. The grain model is clever and the single-install, single-login approach was genuinely ahead of its time in 2014. The failure was a business model problem, not a technical one — and that’s why a project that EdTech professionals describe as indispensable [2] is now community-maintained with uncertain long-term momentum.

For new deployments in 2026, the calculus is hard. If you want a stable platform bet, Cloudron or Yunohost are safer choices with active development behind them. If you already run Sandstorm and it covers your needs, there’s no pressing reason to migrate — the software works, the security model is sound, and the community is still there. But going in with open eyes about what “community-maintained volunteer project, no company, no revenue” means for your uptime and your update cadence is not optional.

---

Sources

1. GIGAZINE — “I installed the platform application ‘Sandstorm’ that allows you to self-host a wide variety of web applications with a single button” (Dec 30, 2023). https://gigazine.net/gsc_news/en/20231230-sandstorm/
2. EdTech Factotum — “Sandstorm is winding down and some other options to begin exploring for self-hosting web apps”. https://edtechfactotum.com/sandstorm-is-winding-down-and-some-other-options-to-begin-exploring-for-self-hosting-web-apps/
3. Plane Blog — “11 Jira alternatives you can self-host in 2026” (Mar 3, 2026). https://plane.so/blog/11-jira-alternatives-you-can-self-host-in-2026
4. Quantum Hosting Blog — “A review of sandstorm.io”. https://blog.quantumhosting.cloud/a-review-of-sandstorm-io/
5. Sandstorm Blog — “Sandstorm now belongs to Sandstorm.org” by Kenton Varda (Jan 14, 2024). https://sandstorm.io/news/2024-01-14-move-to-sandstorm-org

Primary sources:

• GitHub repository: https://github.com/sandstorm-io/sandstorm (7,014 stars)
• Current project home: https://sandstorm.org
• Historical website: https://sandstorm.io
• Documentation: https://docs.sandstorm.io
• App Market: https://apps.sandstorm.io