Registry metadata
July 27, 2026 ยท View on GitHub
Part of wasm-pkg-tools docs.
Metadata via well-known URI (/.well-known)
For well-used or public registries, we recommend creating a
.well-known metadata file
that is used by the tool chain to simplify configuration and indicate to a
client which protocols and mappings to use (although this can be set directly
in config as well).
The wkg tool and libraries expect a registry.json file to be present at a
specific location to indicate to the tooling where the components are stored.
For example, given a registry example.com, then the tooling will attempt to
find a registry.json file at
https://example.com/.well-known/wasm-pkg/registry.json.
Format
{
"preferredProtocol": "oci",
"oci": { "registry": "ghcr.io", "namespacePrefix": "webassembly/" }
}
Deprecated variant
For backwards compatibility with previous tooling and versions of the `wkg` tool, you may also encounter a `registry.json` file that looks different. These files are still supported, but should be considered deprecated. For OCI registries, the JSON looks like this:{
"ociRegistry": "ghcr.io",
"ociNamespacePrefix": "webassembly/"
}
preferredProtocol
- Type: string
- Default: none (inferred if only one protocol block is present)
Which protocol the client should use when contacting the registry. While this
field is present for future compatibility, it is generally fixed to "oci" in
this implementation.
oci.registry
- Type: string (host)
Base URL of the OCI registry that stores the components.
oci.namespacePrefix
- Type: string
- Default:
""
Prefix joined to the package's namespace when composing the OCI reference. For
the example above (which is for wasi.dev), components are available at
ghcr.io/webassembly/$NAMESPACE/$PACKAGE:$VERSION e.g. ghcr.io/webassembly/wasi/http:0.2.1).
Conventions for storing components in OCI
Astute observers will note that OCI requires a specific structure for how those
components are stored. To be clear, this does not apply to deployable artifacts
(such as those used by various runtimes), but only to WIT components or library
components. Based on the information in the registry.json file, the base URL
and namespace prefix will be joined together with the namespace and package
name to form the full URL. So if you have a custom company namespace called
acme, then a package called acme:foo should be stored with the name
acme/foo. If we use the registry.json file from the example above, then the
component will be stored at ghcr.io/webassembly/acme/foo:0.1.0.
The tag MUST be a valid semantic version or the tooling will ignore it when pulling.