How Does Sandstorm Keep Self-Hosted Web Apps Secure?

Sandstorm's security comes from wrapping each thing you create — a document, chat room, mailbox, notebook, or blog — in its own isolated container called a "grain." Each grain runs in a secure sandbox that cannot talk to the outside world without explicit permission, and every grain is private until you share it. According to the project, this design automatically mitigates 95% of security vulnerabilities. If you want to self-host web apps and care about limiting the blast radius of any single app, this model is the core reason to consider Sandstorm.

The grain: one unit, one sandbox

Sandstorm does not treat an app as the security boundary. It treats each individual object you create as the boundary.

• A document in Etherpad is a grain.
• A chat room in Rocket.Chat is a grain.
• A mailbox, notebook, or blog is a grain.

Each grain is containerized in its own secure sandbox. The practical consequence: a flaw in one grain does not automatically expose the others, because they do not share a runtime environment by default.

Apps cannot reach the network without permission

The sandbox is not just about separating grains from each other. It also restricts what each grain can do outward.

A grain "cannot talk to the world without express permission." This is the mechanism behind the claimed 95% mitigation figure — most vulnerabilities depend on an app being able to reach out, and Sandstorm denies that by default rather than relying on each app to defend itself.

Why default-deny matters for self-hosting

When you self-host, you are the one responsible for patching and configuring every app. Default-deny shifts that burden: instead of auditing each app's network behavior, you start from a position where nothing communicates unless you allow it.

Private by default, with unified access control

Every grain is private until you share it. Sandstorm manages access control across all apps in one consistent system, which has two useful properties:

• Visibility: you can see who has access to a given document or room.
• Revocation: you can revoke that access at any time.

Because the access control layer is unified, it covers data from every app rather than each app implementing its own permissions. Sandstorm states this makes it easier to adhere to security, regulatory, and data privacy requirements.

Self-hosting puts data location under your control

Sandstorm can run in the cloud on a variety of hosting services, or on your own machines, and you can move between these options at any time. The apps stay the same regardless of where you run it.

For organizations, this means complete control over where data is stored — the part that matters when a requirement specifies data residency or internal handling rather than just "encrypted in transit."

What to check before trusting the model

The security claims above are the project's own. Two things are worth verifying yourself:

1. Read the security model documentation. Sandstorm points to its security model and "security non-events" write-ups. The non-events are the more informative read — they describe vulnerabilities that did not become incidents because of the sandbox.
2. Confirm the trade-off fits your apps. A sandbox that blocks network access by default is a strong default, but some apps legitimately need outbound connections. Check whether the apps you depend on work within that constraint.

If your goal is running open source web apps on hardware you control while keeping each object isolated and private by default, Sandstorm's grain-and-sandbox design is the specific feature to evaluate. If you need apps that freely reach external services, test those first — the same default that provides the security is the one most likely to get in their way.