Config Service

Planned changes to host configuration

The wasmCloud Q3 2025 Roadmap sets out plans for changes to host configuration in the next major release of wasmCloud. The new approach will discontinue usage of the config service. For more information, see the Roadmap and Issue #4641: “Reduce host responsibility and API surface.”

wasmCloud hosts can be configured at start time with a variety of host config options. However, in some production deploys, it is useful to provide supplemental configuration to a host from an external source.

For example, wasmCloud hosts can be configured to pull artifacts from private OCI registries. The host can be started with credentials to a single registry, but in cases where multiple registries are used to host artifacts, a config service can be used to provide credentials for multiple registries to hosts.

The config service is disabled by default. When enabled, wasmCloud hosts will make a request to wasmbus.cfg.{lattice-id}.req during initialization.

Config Requests and Responses

When making a request for configuration, the host provides its labels as the payload:

json

{
  "labels": {
    "foo": "bar",
    "baz": "qux"
  }
}

In response, the host receives supplemental configuration. At this time, the only configuration returned is a set of credentials for OCI registries:

json

{
  "registryCredentials": {
    "someregistry.io": {
      "username": "user1",
      "password": "hunter2"
    },
    "anotherregistry.io": {
      "username": "myuser",
      "password": "asecurepassword"
    }
  }
}

Hosting a Config Service

Since the config service API is over NATS, it can be implemented by anything that can subscribe and publish responses to wasmbus.cfg.{lattice-id}.req (including a wasmCloud component!).