Sandboxing and Security

Running the Blueprint Manager in production should prioritize isolation and key safety. The recommendations below assume Tangle (legacy: Tangle Substrate).

Recommended: VM sandbox for native blueprints (Linux)

The native VM sandbox uses cloud-hypervisor to isolate blueprint binaries. For a step-by-step host setup, see Sandbox Provisioning.

Install cloud-hypervisor and make sure it is in PATH.
Grant CAP_NET_ADMIN to the binary that runs the manager:

sudo setcap cap_net_admin+eip /path/to/cargo-tangle

If you run blueprint-manager directly, set the capability on that binary instead.

Run with VM preferences enabled:

cargo tangle blueprint run \
  --protocol tangle-evm \
  --http-rpc-url "$RPC_URL" \
  --ws-rpc-url "$WS_RPC_URL" \
  --keystore-path ./keystore \
  --settings-file ./settings.env \
  --spawn-method vm

The manager handles kernel and disk image downloads automatically.

Containers and Kata

If you deploy container-based blueprints, use a hardened runtime such as Kata Containers and follow Kubernetes best practices for least privilege.

Key and data safety

Store keystores on encrypted storage.
Restrict filesystem permissions to the operator user.
Avoid running the manager as root unless required for sandboxing.

Dry-run safety

For validation or benchmarking, cargo tangle blueprint service spawn --dry-run runs a service runtime without submitting default on-chain transactions (registration, results, heartbeats). Custom job logic can still submit transactions if it does so explicitly. This is not a production substitute for the manager.

Sizing Join as Operator