Skip to main content
Sandbox configuration is a reusable, sparse definition for one sandbox. Load it with msb run, msb create, or msb install; explicit CLI arguments are applied on top. The file may have any name when passed with --conf.
Sandbox configuration is never auto-discovered. Every root or scoped configuration file must be supplied explicitly with its corresponding flag.

Sparse configuration

Every config file may provide only the fields it owns. Required fields are checked after root config, scoped config, and command-line inputs are merged, so a positional image can complete a network-only file:
If neither the files nor the arguments provide an image, the command fails before pulling an image or creating sandbox state.

Scoped config files

Scoped flags accept the contents of one field or field group without its root wrapper. They are useful for focused policies that should fail on unrelated fields. For example, --net-conf expects this unwrapped document:
Passing network: {...} to --net-conf is an error; use --conf for a root-shaped document. Every root and scoped config flag is repeatable, and different config flag kinds may be interleaved freely.

Precedence and merging

Configuration resolves from lower to higher precedence:
  1. Built-in and global config.json defaults
  2. Every --conf and scoped config occurrence, from left to right on the command line
  3. Explicit non-config CLI flags and positional arguments
Higher-precedence scalars replace lower values. Maps merge by key, including nested init, network.dns, network.tls, and secret definitions. A list supplied by a higher-precedence config file replaces the lower list. Repeating the same config flag works exactly like interleaving different config flags: each file overlays everything to its left. Repeatable non-config CLI flags remain additive, and CLI network rules are evaluated before rules loaded from files.
Relative host paths are resolved against the file that contains them. Paths inside a file listed by patch_files are resolved against that patch file.

Rust SDK patches

The Rust SDK owns the typed sparse representation used after a file has been parsed. SandboxConfigPatch composes root and scoped patches with right-hand-side precedence, and SandboxBuilder::configure applies the result before later fluent builder calls:
Scoped patch types implement Into<SandboxConfigPatch>, so they pass directly to overlay without wrapper constructors. The SDK patch types do not read YAML, resolve relative paths, or expand ${ENV}; those are CLI file-adapter responsibilities. SandboxConfig remains the complete durable configuration, while SandboxConfigPatch represents only construction-time fields that were supplied.

Schema

Image and registry

The common image form is a string. Local paths beginning with ., .., or / are resolved as bind roots or disk images; other strings are OCI references.
Use the object form to select a source explicitly:
Exactly one source is allowed. Project layer references are not valid in single-sandbox configuration; consume a published layer as an OCI reference instead.

Resources and lifecycle

When hard is omitted it equals soft.

Runtime

cmd is the default workload for msb run. msb create stores it without launching it.

Mounts

A string mount is a bind mount with an optional trailing :ro:
Object mounts require exactly one source and a guest target:
All mount kinds accept readonly, noexec, nosuid, and nodev. stat_virtualization and host_permissions apply only to bind and named mounts. Duplicate guest targets are rejected.

Rootfs patches

Patch files run first in listed order, followed by inline patches:
A patch file has one top-level patches list using the same operations. File modes must be quoted four-digit octal strings.

Network

Use a preset string for the common cases:
public, the default, permits public internet access while blocking private, loopback, link-local, and metadata destinations. none denies ingress and egress. open is unrestricted. The object form adds rules and network services:
A non-empty allow list implies deny-by-default egress. Top-level ports is shorthand for network.ports; when both are present, the lists are combined and duplicate host ports are rejected.

Secrets

Every secret requires a non-empty destination allowlist. When value is omitted, the host environment variable with the same name is used. An exact ${NAME} value records NAME as the host-side source instead of copying its plaintext into durable config.
inject accepts headers, basic_auth, and query_params; it defaults to headers. Declaring a secret enables TLS interception and DNS-rebind protection.

Scripts

Scripts are named shell snippets installed as executables in /.msb/scripts, which is on PATH. The sandbox configuration’s shell selects their shebang and defaults to /bin/sh.
Run a script like any other guest command:

Strict YAML and environment substitution

Sandbox configuration is data, not a templating language. The loader rejects unknown fields, duplicate keys, multiple YAML documents, anchors, aliases, merge keys, and custom tags. Bare YAML 1.1 booleans such as yes, no, on, and off are rejected. Quote modes, sizes, durations, ports, domains, image references, and other typed strings. Only ${NAME} environment substitution is supported. Substituted variables must exist when the config is loaded; an exact secret value: "${NAME}" is the exception because it records a host-side source that is resolved when the sandbox starts. Shell-style operators such as ${NAME:-fallback}, includes, templates, loops, and expressions are not supported. Project envelope fields such as sandboxes, volumes, and layers, plus per-project fields such as depends_on, are rejected in single-sandbox configuration.