The grain is a useful boundary for application state
A Sandstorm grain is an application instance with persistent state. Treating it as a boundary clarifies sharing, ownership, backup contents, and what a restore must recover.
Think in instances, not just installed applications
An installed application describes software that can create or operate on data. A grain is a particular instance of an application, with state belonging to that instance. That distinction is useful because a server can host multiple independent pieces of work using the same application: one grain may hold a team’s project notes, while another holds a private planning document. The application’s identity does not make those documents the same resource or give them the same access rules. The process can stop and restart without making the grain a different workspace.
Sandstorm’s technical documentation describes a separate sandbox for each object created with an application. Application packages are mounted read-only, while the app can store persistent state in /var. This separates the software shared by many instances from each grain’s own data. [1]
Sharing a grain is a decision about its contents
If a user grants someone access to a grain, the practical question is what that recipient can do with the state in that application instance. The owner and an invited collaborator are different roles: the owner is responsible for the grain, while access determines what another person can reach. Sharing one grain can keep the decision specific to one workspace or document rather than exposing an entire account’s collection of unrelated state. The application’s interface and the host’s sharing model determine the recipient’s actual operations.
This boundary also gives a useful thought experiment. Imagine two grains running the same note-taking application. A colleague is invited to the first grain but not the second. If the boundary is working as intended, the invitation provides a path into the first grain’s state and does not imply access to the second merely because both use the same application. The access grant is about an instance, not a blanket relationship with every instance of that software. [1]
Backups need state and a way to interpret it
Treating the grain as the state boundary helps define what a backup should preserve: the application instance’s data, plus enough information to associate that data with the application and restore it coherently. A data archive without a compatible application runtime or package may contain bytes that cannot be used as the original interactive workspace. Conversely, preserving only the application package does not preserve the user’s documents or configuration.
A restore plan therefore needs to identify which state is being restored, which application can read it, and whether the restored instance should regain the same sharing relationships. Those are separate questions. The grain boundary helps avoid assuming that restoring data also restores access grants, ownership, secrets, or service configuration; the backup format and host system must define those behaviors. Thinking through the boundary before an incident makes it clearer what a successful restore must include and what must be re-established afterward.
Isolation has costs and edges
A per-instance boundary can make sharing and recovery more understandable, but it creates operational responsibilities. Administrators need to account for storage and backups across many grains, and users need a way to distinguish similarly named instances. If a workflow spans two grains, the application or user must decide how data crosses between them; isolation does not itself provide collaboration across boundaries.
The platform can enforce whether a user has access to a grain; read-only and read-write permission levels also depend on the application. That distinction matters when evaluating a sharing boundary. Granting access to one sandbox does not by itself prove that every operation inside it honors the intended role. [2] Treat each grain as a distinct unit, then check the application-level permissions and the recovery behavior separately.