BLAST forks and runs sandboxes from a single 7 MB binary

A control plane over sandboxes you already have

BLAST is described as a single binary for local sandbox orchestration given a pool of CPU, memory and disk, and more precisely as something that abstracts over local sandboxes such as SmolVM, Hypeman and Docker to provide a simple API to fork and run sandboxed commands, sync data, and monitor VMs, sessions and runs. The abstraction is the point. Each of those backends has its own interface for creating a machine and running something inside it, and BLAST turns them into one vocabulary of forks, runs, snapshots and sessions. The README also lists what it does around the sandboxes themselves, namely automatically scheduling and placing forks and runs, snapshotting and syncing snapshots to durable storage, migration, and managing resource pressure, which are the parts that turn a set of tools into an orchestrator.

Fork, run, and read the state back over HTTP

The API is exercised in the README's quick start, and the shape is worth reading because it shows the two ways you create a sandbox. You POST to `/v1/fork` with an image, and the response carries a `vm_id`:

The full quick start shows both calls. The first forks from an image:

VM1=$(curl -s -X POST localhost:7240/v1/fork \
  -H "Content-Type: application/json" \
  -d '{"image":"ubuntu:24.04"}' | jq -r .vm_id)

The second forks from the machine you already have, giving it a name:

VM2=$(curl -s -X POST localhost:7240/v1/fork \
  -H "Content-Type: application/json" \
  -d "{\"source_vm_id\":\"$VM1\",\"name\":\"feature-xyz\"}" | jq -r .vm_id)

and the third runs a command inside the fork:

curl -X POST localhost:7240/v1/vms/$VM2/runs \
  -H "Content-Type: application/json" \
  -d '{"command":"echo hello from fork"}'

Forking from a source machine rather than from an image is the capability that makes it feel like a service rather than a wrapper, since a branch of an existing environment is what most build and test pipelines actually need.

Orchestration rather than a toolbox of helpers

The README draws this contrast itself. It says that, unlike other solutions that simply provide utilities for creating sandboxes, BLAST takes a given pool of CPU, memory and disk and optimally serves forking and running sandboxed commands. That is the claim to test when you evaluate it, because most sandbox tooling stops at creating the environment and leaves placement, capacity and lifecycle to you. The responsibilities BLAST takes on are scheduling and placement of forks and runs, snapshots and their synchronisation to durable storage, migration between hosts, and resource pressure management, which is what a queue of thousands of short lived test environments actually needs. It also says it is built to integrate with a control plane for a unified view across bursty cloud compute and user provided compute, so the intended deployment is a local orchestrator that can sit under a broader control plane.

Installing it is a cargo install and a run

The quick start is two commands, and the package on crates.io is named differently from the binary:

cargo install blast_core
blast

That naming shows up in the manifest too, where the package is `blast_core` at version 0.1.4 with the Rust 2021 edition, and there is a separate `[[bin]]` entry that produces a binary named `blast` from `src/main.rs`. So the install step puts the core crate on your path and the `blast` command is the one you run. The service then listens on port 7240, which is the port used throughout the README's examples, and the documentation site at blastproject.org/docs is where the fuller material lives, with the website source in the `website/` directory of the repository.

A small codebase and a permissive licence, on purpose

Two of the feature bullets are about organisational friction rather than function, and they are the reason to look at this project. The first is a single 7 MB binary with no Terraform, no Packer and no extra dependencies, which removes a provisioning toolchain from the picture. The second is the licence and the size of the code, described as the most permissible licence with the code MIT licensed and just 3,586 lines, built to keep enterprise security reviews as simple as possible. That is an unusual thing for a project to advertise, and it tells you the audience. The people evaluating this are security teams who have to approve a new component for running untrusted code, and a small auditable codebase with a permissive licence answers a different objection than a feature list would.

The Rust stack and where to configure it

The dependency list tells you the shape of the service. Axum 0.7 with macros provides the HTTP server, Clap 4 with derive and env features provides the command line and environment based configuration, Tokio with the full feature set is the async runtime, and Reqwest with json and rustls-tls and default features disabled does the outbound HTTP, which is the transport for talking to the VM providers. Serde and serde_json handle the payloads, thiserror and anyhow handle errors, tracing with tracing-subscriber and an env filter do the logging, and tower-http adds trace middleware. The `ulid` and `sha2` and `hex` and `base64` crates are there for identifiers and hashing, and `config` handles the configuration file format. The release profile is tuned, with opt-level 3, link time optimisation enabled and a single codegen unit, which is what a performance sensitive binary wants. Configuration lives in a file, and the repository ships `blast.example.toml` as the starting point, plus an `examples/cloakbrowser.sh` script.

Where BLAST fits, and what it is not

It helps to be precise about the category. BLAST is a local orchestrator, and the pool of CPU, memory and disk it schedules over is yours. It is not a cloud provider, and it is not a hosted sandbox service, since the README's cloud language is about integrating with a control plane so that bursty cloud compute and user provided compute look the same from above. The `examples/` directory and the REST API suggest the intended users are platform and tooling teams who need to run many sandboxes, whether for testing untrusted code, for CI matrices that are too large for a normal runner pool, or for reproducible research environments. The repository is not archived, the last push was on 2026-08-30, and there are no GitHub releases, so the version in the manifest, 0.1.4, is the only version reference you get, and the documentation site is where the current guidance lives.

Editorial conclusion

Adopt BLAST when you need to create and run many short lived sandboxed environments across a mixed fleet of local VM and Docker backends, since it gives you one API for forking, running, snapshotting and migrating, and it is a single binary with an MIT licence that a security review can read. Do not adopt it as a hosted compute platform, because it is a local control plane over sandboxes you already run, not a provider of capacity, and the README describes the cloud integration as a control plane to integrate with rather than a built in cloud. Verify first which sandbox backends you have available, since BLAST abstracts over SmolVM, Hypeman and Docker, and read the example configuration file `blast.example.toml` before you point it at real hardware.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. stanford-mast/blast on GitHub