How Is Sandstorm Different From Manually Self-Hosting Web Apps?

Sandstorm is an open source platform for self-hosting web apps, and its main difference from manual self-hosting is that it replaces per-app server setup with an app-market model: you find an app, install it with a few clicks, and get automatic updates, unified access control, and a single place to find everything you create. It fits teams or individuals who want to run open source web apps on their own infrastructure without configuring a server, domain, backup routine, and permission system for each app separately. If you need deep per-app customization or run apps that Sandstorm does not package, manual deployment may still be the better fit.

The core difference: install apps like phone apps

With manual self-hosting, each app is its own project. You provision a server, install dependencies, configure a reverse proxy and TLS, set up a database, create users, and repeat the whole process for the next app.

Sandstorm changes the unit of work. According to the project, installing apps on Sandstorm is as easy as installing apps on your phone: you find any app you want on the App Market and start using it with a few clicks. Every app comes with automatic updates.

That means the comparison is not "same job, fewer commands." It is a different division of labor:

Dimension Manual self-hosting Sandstorm
App installation Per-app server, dependencies, proxy, database setup Find app in App Market, install with a few clicks
Updates You track and apply them per app Automatic updates per app
Access control Configured separately for each app Unified access control covering data from every app
Finding your content Scattered across app-specific URLs and databases Sandstorm keeps a list so you can find everything you create
Privacy default Depends on each app's defaults Everything is private to you by default

What "grain" means for security and sharing

Sandstorm's security model is built around a unit called a "grain." Each document, chat room, mailbox, notebook, blog, or anything else you create is a grain. Sandstorm containerizes each one in its own secure sandbox, and a grain cannot talk to the world without express permission. All grains are private until you share them.

The project states that this design automatically mitigates 95% of security vulnerabilities. It also says Sandstorm manages access control on every document, so it can show who has access and let you revoke that access at any time.

This is the part that is hardest to replicate manually. If you self-host five apps by hand, you have five separate permission systems, five separate sharing models, and five separate answers to "who can see this file?" Sandstorm makes that one question with one answer.

Where your data lives, and why you are not locked in

Sandstorm lets you choose where your data lives: you can run it in the cloud on a variety of hosting services, or install it on your own machines, and you can move between these options at any time. The apps are the same regardless of where Sandstorm runs.

It also avoids vendor lock-in in the app layer. You can mix and match apps from multiple developers, and add apps of your own as needed. Many Sandstorm apps are open source.

For organizations, the project frames this as complete control over where data is stored, and says Sandstorm makes it easy to adhere to security, regulatory, and data privacy requirements.

What Sandstorm actually runs

The homepage lists examples across common categories:

  • Document editing — create, edit, and collaborate on documents with Etherpad
  • File storage — store and share files with Davros
  • Task & project management — organize tasks and ideas with Wekan
  • Chat — sync with colleagues securely using Rocket.Chat

You can try these through the online demo before committing to an install.

When manual self-hosting is still the better choice

Sandstorm is designed for humans and for running open source web applications easily. It is not a general-purpose replacement for every deployment. Manual self-hosting makes more sense when:

  • The app you need is not available on the App Market.
  • You require custom server-level tuning, non-standard networking, or specific database versions.
  • You want to run a single app and do not need unified access control or a shared app list.
  • Your workflow depends on direct filesystem or shell access to the app's internals.

If your goal is to run several open source web apps with consistent permissions and minimal per-app maintenance, Sandstorm's model removes most of the repetitive work. If your goal is fine-grained control over one specific stack, manual deployment gives you that control directly.

Getting started

The site offers two entry points: an online demo to see the app experience, and a "Get Sandstorm" path to install it. The documentation and community links are the places to check for supported hosting options and the current app catalog before you decide.

sandstorm.org
Take control of your web by running your own personal cloud server with Sandstorm.