Skip to main content

Glossary of Terms

Definitions for frequently used terms


wasmCloud is the CNCF-owned open source project that Cosmonic builds on top of. It is a distributed platform for writing portable business logic that can run anywhere from the edge to the cloud. Most of the other terms in this glossary derive from terminology used by wasmCloud. Anything you build that works in plain wasmCloud should work automatically in Cosmonic!


A host is a distributed, resilient, highly performant wasmCloud runtime process that manages actors and capability providers. Hosts coordinate the scheduling of compute, emit events, manage observability and tracing, and participate in a constellation network.


An actor is a small WebAssembly module that can handle messages delivered to them and invoke functions on capability providers. When you write an application with Cosmonic, the code that you write will be low-boilerplate logic that interacts with capability interfaces to create your fully functioning application.

Developing with actors allows you to focus on writing the right code without tightly coupling to architecture, scale, or non-functional requirements.

Capability Provider

A capability is an abstraction or representation of a non-functional requirement; some functionality required by your actor that is not considered part of the core business logic. Capabilities both describe functionality (for example, an HTTP Server receives requests and returns responses via TCP) and are used to verifiably allow actors to access resources. Capabilities are deny-by-default and must be explicitly granted for each actor that wishes to use that functionality. You can read more about capabilities in the wasmCloud capabilities documentation.

A capability provider is an implementation of the abstract representation described by a capability contract. Capability providers and capabilities have a many-to-one relationship; a single capability contract can have multiple implementations, and as such provide the ability for actors to pick and choose implementations based on convenience, requirements, and environment. An actor that declares a wasmcloud:keyvalue capability can, for example, pick the Redis provider for simplicity, a HashiCorp Vault provider for secrets management, or even the Cosmonic Built-in KeyValue provider for a fully hosted key-value store.

A link is a runtime defined connection between an actor and a capability provider. Links inform the host runtime about what capability providers an actor may invoke. Links can be removed and added at any time. An actor that was previously linked to one implementation of a capability can change to another implementation or an updated version of that capability provider without requiring a redeploy or a recompile. Links can also include configuration information, such as database connection strings, port numbers, or API access keys.

Capability providers are launched with a link name that acts as a way to allow different link configurations for the same capability provider. For example, you can launch two NATS capability providers with different link names, frontend and backend, and traffic can be segmented between two sources based on link name. The wasmCloud SDK assumes the default link name, default, and if you launch capability providers on different link names then you'll need to specify that link name with the provider sender in your code.


A constellation is a managed, isolated network space that allows your actors and providers to securely communicate with each other regardless of physical or logical location. You can think of a constellation as a Cosmonic-managed wasmCloud lattice.


A Wormhole is an ingress point into your constellation. It exposes a single actor through a special wormhole-aware web server capability provider on a randomly generated DNS name like Resources are not accessible on the public internet by default and must be explicitly allowed entry.

Wormholes support exposing endpoints with the HTTPS protocol today. Additional protocols like TCP, NATS, gRPC, etc may be added in the future.


Throughout documentation and tutorials, you may see the term auction. When seeking potential candidates for a deployment of a capability provider or an actor, you can perform an auction. An auction will send a request out to the entire constellation for all hosts matching the criteria supplied. The "winners" of this auction are then considered suitable candidates. Managed applications rely heavily on auction functionality.

OCI Reference

The Open Container Initiative (OCI) has defined a standard by which artifacts can be stored, retrieved, and distributed. This standard is called OCI distribution. Many well-known applications support OCI, but the ones you may see most often in Cosmonic and wasmCloud documentation are the Azure Container Registry and GitHub's artifact registry.

OCI references are URLs that point to such artifacts, e.g. is the URL for v0.3.2 of the wasmCloud example echo actor.

Infrastructure View

The infrastructure view is a perspective into your constellation that shows the virtual hosts running in your constellation. Here you can see the hosts, their associated metadata, as well as the contents of each host.

Logic View

The logic view is a perspective into your constellation that shows the logical relationships between components. Here you can see actors, providers, links, and wormholes all without regard to the underlying infrastructure. The logic view can even span multiple disparate infrastructures connected via super constellations.

General and Ecosystem Terms

The following is a list of terms that you might encounter in google searches that are part of the ecosystem of technology used by Cosmonic and wasmCloud


WebAssembly is a standard that defines a compact, stack-based virtual machine. You can think of this as being in the same family as the bytecode machines used by Java or the .NET runtime. However, what makes WebAssembly so powerful (and so amenable to the cloud!) is that it is secure by default, truly portable, and incredibly small--all the things we want in a cloud deployment target.


WASI is an acronym that stands for the WebAssembly System Interface. WASI is a modular system interface originally designed around the ideas of security and portability. It provides some low-level system functionality (like stdio and limited file access) to otherwise isolated WebAssembly modules.

This standard is undergoing a lot of advancement and there are a lot of really amazing things on the horizon that are either part of WASI or tangential to it. Stay up to date on all the developments by following our blog.

Component Model

The WebAssembly Component Model is an evolving standards effort that has the goal of making it easier for multiple WebAssembly modules to interact with each other. As usual, when there are developments in this ecosystem related to our work at Cosmonic, we will be blogging about it.

Key-Value Store

A key-value store is an incredibly popular persistence mechanism. Rather than requiring tables, joins, foreign keys, and SQL queries, a key-value store gives you atomic access to individual values. The data stored within a key can be simple strings, JSON payloads, sets, and more. Cosmonic provides a built-in key value store accessible to all customers.

NATS Leaf Node

A NATS leaf node extends a NATS system of any size, bridging infrastructure together and routing messages between local nodes and an upstream network as needed. We use leaf nodes for our Super Constellations to extend the Cosmonic network anywhere, and one is automatically launched for you when you run cosmo up.