Blueprint Sources

Blueprints can be built and distributed in multiple formats (visible on the sidebar).

Sources describe how operators fetch and execute your artifact. They do not describe confidentiality policy. If your blueprint should run in a TEE, declare that separately in metadata.execution_profile.confidentiality. See Execution Confidentiality.

A blueprint can define many sources of different types in the manifest of its binary crate:

[package.metadata.blueprint]
sources = [
    { type = "Container", registry = "docker.io", image = "some-user/my-blueprint", tag = "latest" },
    # Fallback container source
    { type = "Container", registry = "ghcr.io", image = "some-user/my-blueprint", tag = "latest" },
    # Native binary source
    { type = "Native", owner = "some-github-user", repo = "some-blueprint", tag = "0.1.0", binaries = [
        { arch = "Amd64", os = "Linux", name = "my-blueprint-bin" },
    ] },
]

The above example has two container sources, which allows an operator to attempt a pull from different sources in the event that one of the registries is unreachable. Additionally, it has a native source which can act as a fallback for operators that either cannot or prefer not to support running containerized blueprints.

Today, only container sources are eligible for TEE placement on the Tangle manager path. That still does not make TEE a new source type; it remains a deployment policy layered on top of container execution.