Reading Tempest as a systems project
Tempest’s repository describes an experimental replacement for Sandstorm, with sandbox setup work and HTTP plumbing already present. Its README is a map of questions to investigate, not evidence for production guarantees.
Start with what the repository says
Tempest is described in its repository as an experimental replacement for Sandstorm. The README says most sandbox setup code is built and that it can spawn Sandstorm apps and plumb HTTP traffic from outside, while noting that some HTTP features remain unimplemented. Those statements establish project scope and stated status; they do not establish a complete compatibility or security story. [1]
A useful systems reading begins by turning each claim into a question. What does “spawn” mean for process lifecycle? Which resources are isolated, and at what boundary? How does incoming HTTP map to an app instance? The repository’s directories and setup steps can guide exploration, but directory names alone cannot answer whether an implementation has a particular runtime property.
Follow the build and storage paths
The README lists Go 1.20 or later, TinyGo, C development tools, bpf_asm, Cap’n Proto tooling, and other dependencies. That list suggests several implementation layers worth tracing: generated interfaces, low-level sandbox setup, and system integration. A researcher can follow a request from the web interface toward the code that launches an app, then locate where configuration and process parameters enter the path. The repository should be treated as the evidence for what is present, and the code itself as the place to verify mechanisms. [1]
Storage is another concrete seam. The documented configure option can point Tempest at an existing Sandstorm local state directory, and the README says Tempest adds a mount directory and SQLite database under that path. Import and export tooling moves some data through a snapshot. Those facts invite questions about migration boundaries, ownership, and failure recovery; they do not by themselves establish safe concurrent use or a lossless migration.
Trace one launch before judging isolation
A useful thought experiment is to follow one grain launch. A user selects a grain in the web interface; the server resolves the grain’s app and stored data; a process is created; HTTP traffic is routed to its interface; the response returns to the browser. At each transition, ask what identifier selects the grain, which process owns the data, and what stops one grain from reaching another’s resources. The README’s claim that sandbox setup is mostly built makes these productive questions, but the README does not specify their answers. [1]
Tempest’s README also states that an app’s UI is shown in an iframe and that offers and Sandstorm-specific APIs do not currently work. This gives a concrete compatibility boundary to inspect: an app can render while interactions that depend on platform APIs fail. Testing one simple page would not imply that its broader app contract is supported.
Keep experiments distinct from recommendations
The repository documents developer-oriented configuration, import commands, and running Tempest under the configured user and group. These instructions help someone reproduce the project’s intended setup, but an experimental repository is not by itself a maintained production deployment guide. The README does not supply a full operational threat model, upgrade policy, or support commitment. [1]
Sandstorm’s security documentation gives useful comparison points: it describes per-resource isolation and distinguishes the platform’s access decision from finer permissions enforced by an app. [2] Those are questions to test against Tempest’s implementation, rather than properties to infer from compatibility with a Sandstorm app. Follow launch, routing, storage and authority boundaries separately, and record what the code establishes at each one.