Plugins

Steel plugins are OCI artifacts. Define interfaces with WIT, compile, and distribute through any container registry.

Packaging as OCI Artifacts

Every Steel plugin is an OCI image layout archive. This means plugins travel through the same infrastructure as container images — registries, mirrors, air-gapped environments, and local archives all work out of the box.

A plugin archive contains:

• Plugin config — name, version, description, and per-object annotations.
• Binary layers — content-addressed with SHA-256 digests for integrity verification.
• Custom media types — application/vnd.steel.plugin.layer.v1 for registry tooling.

Registry Support

Pull plugins from any OCI-compliant registry:

• GitHub Container Registry (GHCR)
• Amazon Elastic Container Registry (ECR)
• Docker Hub
• Any private or self-hosted registry
• Local OCI archives for air-gapped environments

Interface Definition with WIT

Plugin interfaces are defined using WIT (WebAssembly Interface Types). WIT gives you a language-neutral way to describe functions, types, and interfaces that work across Rust, Go, C, Python, and any language that can conform to WIT definitions.

// Example WIT interface
package steel:example;

interface example-facet {
    hello-world: func() -> string;
    echo: func(value: u32) -> u32;
    add: func(a: u32, b: u32) -> u32;
}

world example {
    export example-facet;
}

Automatic World Discovery

When a plugin is loaded, Steel automatically extracts the WIT world name from the compiled binary. No separate type registry needed. You can look up objects by world name at runtime:

let obj = plugin.object_by_world("steel:example/example")?;

Content Addressing

Every plugin layer is content-addressed using SHA-256. Identical binaries produce identical digests. Registry deduplication works automatically, and integrity is verified on every load.

Building Plugins

Currently Steel only supports WASM-based components, but there are plans to introduce other types of isolated backends in the future