Runtime Requirements for the Blueprint Manager

Blueprints can be executed in multiple ways (see Sources), with each requiring certain dependencies, and possibly hardware.

Native Sources

There are two ways to run blueprints with Native Sources in the blueprint-manager: sandboxed (recommended) or not

In either case, the following dependencies will be needed:

• GitHub CLI (for binary attestations)

Then additionally for the two execution methods:

Not Sandboxed

No extra dependencies, the blueprint will run as a normal host process.

Sandboxed (Linux Only)

• cloud-hypervisor
  • The manager handles downloading kernel and disk images automatically, but the host still needs KVM access and CAP_NET_ADMIN.
• Allow CAP_NET_ADMIN for the binary that runs the manager (for example, cargo-tangle or blueprint-manager).
  • This can be done by running setcap cap_net_admin+eip /path/to/cargo-tangle
  • or simply running the process as root (not recommended)

For secure production deployments, see Sandbox Provisioning and Sandboxing and Security.

Container Sources

The requirements for running blueprints with Container Sources are:

• Kubernetes
• Docker
• The Kata Containers runtime

TEE Sources (WIP, Linux Only)

The requirements for running blueprints with TEE Sources are:

• dstack VMM
• A compatible TEE environment (requirements vary by provider and hardware)
• Container image build pipeline for your blueprint

WASM Sources (WIP)

The requirements for running blueprints with WASM Sources are:

• A WASM runtime compatible with the blueprint source (e.g., Wasmtime)
• Any additional system dependencies required by your blueprint’s host bindings (if applicable)